Skip to content

Commit cf3d4b9

Browse files
uvdsluvdsl
committed
edit Solid26 based on feedback from CG meeting on 2026-04-15
1 parent 17e6849 commit cf3d4b9

1 file changed

Lines changed: 80 additions & 16 deletions

File tree

‎solid26.html‎

Lines changed: 80 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -239,7 +239,7 @@ <h1 property="schema:name">Solid26: Implementation Guide</h1>
239239
<dl id="document-editors">
240240
<dt>Editors</dt>
241241
<dd id="Jesse-Wright"><span about="" rel="schema:editor schema:author"><span typeof="schema:Person"><a href="mailto:jesse.wright@cs.ox.ac.uk" rel="schema:url"><span property="schema:name"><span property="schema:givenName">Jesse</span> <span property="schema:familyName">Wright</span></span></a> (<span property="schema:affiliation">University of Oxford</span>)</span></span></dd>
242-
<dd data-editor-id="128292" id="Christoph-Braun"><span about="" rel="schema:author"><span about="https://uvdsl.solid.aifb.kit.edu/profile/card#me" typeof="schema:Person"><a href="https://aifb.kit.edu/web/Christoph_Braun/en" rel="schema:url"><span about="https://uvdsl.solid.aifb.kit.edu/profile/card#me" property="schema:name"><span property="schema:givenName">Christoph</span> <span property="schema:familyName">Braun</span></span></a> (<span property="schema:affiliation">Karlsruhe Institute of Technology (KIT)</span>)</span></span></dd>
242+
<dd data-editor-id="128292" id="Christoph-Braun"><span about="" rel="schema:author"><span about="https://uvdsl.solid.aifb.kit.edu/profile/card#me" typeof="schema:Person"><a href="https://aifb.kit.edu/web/Christoph_Braun/en" rel="schema:url"><span about="https://uvdsl.solid.aifb.kit.edu/profile/card#me" property="schema:name"><span property="schema:givenName">Christoph</span> <span property="schema:familyName">Braun</span></span></a> (<span property="schema:affiliation">FZI Forschungszentrum Informatik</span>)</span></span></dd>
243243
</dl>
244244
<dl id="document-published">
245245
<dt>Published</dt>
@@ -311,47 +311,105 @@ <h2>Table of Contents</h2>
311311
<section id="introduction" inlist="" rel="schema:hasPart" resource="#introduction">
312312
<h2 property="schema:name">Introduction</h2>
313313
<div datatype="rdf:HTML" property="schema:description">
314-
<p>The <a href="https://solidproject.org/TR/">Solid Specification</a> defines multiple sub-specification documents with differing levels of maturity. Solid26 collects the most mature and widely implemented specification versions into one coherent reference — a snapshot of the parts of the Solid platform that are most broadly supported by existing implementations.</p>
314+
<p>
315+
The <a href="https://solidproject.org/TR/">Solid Technical Reports</a> comprise multiple specification documents with differing levels of maturity.
316+
The <a href="https://solidproject.org/TR/protocol">Solid Protocol</a> bundles the <a href="https://solidproject.org/TR/protocol#abstract">specifications that, together, provide applications with secure and permissioned access to externally stored data in an interoperable way</a>.
317+
Solid26 points implementers to fixed versions of the <a href="https://solidproject.org/TR/protocol">Solid Protocol</a> and its sub-specifications, a stable snapshot of the specifications to build against today.
318+
Solid26 selects for the most widely implemented specification versions at the time of this documents publication.
319+
</p>
315320
<p>This document does not define new normative requirements, but rather identifies and collects the specifications needed to build interoperable Solid applications and servers.</p>
316321
</div>
317322
</section>
318323

319324
<section id="specifications" inlist="" rel="schema:hasPart" resource="#specifications">
320325
<h2 property="schema:name">Specifications</h2>
321326
<div datatype="rdf:HTML" property="schema:description">
322-
<p>The Solid26 specification documents are as follows. All referenced specifications are W3C Solid Community Group Drafts.</p>
327+
<p>This Solid26 Implementation Guide recommends the following specification snapshots.</p>
323328

324329
<section id="solid-protocol" inlist="" rel="schema:hasPart" resource="#solid-protocol">
325330
<h3>Solid Protocol</h3>
326331
<div datatype="rdf:HTML" property="schema:description">
327332
<p>The <a href="https://solidproject.org/TR/protocol">Solid Protocol</a> (CG-DRAFT/FINAL, v0.11.0) is included with the following comments:</p>
328333
<ul>
329-
<li>Servers are not required to implement <a href="https://solidproject.org/TR/protocol#n3-patch">5.3.1 Modifying Resources Using N3 Patches</a>.</li>
330-
<li>Servers MUST conform to Web Access Control (<a href="https://solidproject.org/TR/protocol#web-access-control">WAC</a>). Clients are not required to conform to Access Control Policy (<a href="https://solidproject.org/TR/protocol#access-control-policy">ACP</a>).</li>
334+
<li>
335+
Clients are strongly encouraged to implement a PATCH fallback mechanism, in case they encounter a Server that does not implement <a href="https://solidproject.org/TR/protocol#n3-patch">5.3.1 Modifying Resources Using N3 Patches</a> despite it being required by the Solid Protocol.
336+
For example, Clients might try to use a combination of HTTP GET and HTTP PUT to work around such limitation of a non-conformant Server.
337+
</li>
338+
<li>
339+
Servers are strongly encouraged to implement Web Access Control (<a href="https://solidproject.org/TR/protocol#web-access-control">WAC</a>), see <a href="#web-access-control">below</a>.
340+
<div class="note" id="note-survey">
341+
<h4><span>Note</span></h4>
342+
<p>The <a href="https://lists.w3.org/Archives/Public/public-solid/2026Mar/0019.html">March 2026 implementation survey</a> yields the following <a href="https://github.com/w3c-cg/solid/blob/main/implementations/wac-acp.2026-04-01.csv">results</a>:</p>
343+
<ul>
344+
<li>
345+
For WAC, the data shows 13 server-side implementations, deployment in 11 services, and 19 client-side implementations.
346+
WAC is considered the pragmatic, user-friendly, and extensible standard that effectively covers nearly all of the use cases from current Solid Apps.
347+
</li>
348+
<li>
349+
For ACP, the data shows 4 server-side implementations, deployment in 1 service, and 4 client-side implementations.
350+
ACP is considered as a highly powerful but complex tool that has not seen wide adoption in the community as the data indicates.
351+
</li>
352+
</ul>
353+
<p>The data shows that most clients implement only one access control language, despite the Solid Protocol requiring Clients to conform to both WAC and ACP.</p>
354+
</div>
355+
</li>
356+
<li>
357+
While the Solid Protocol technically requires any Client to conform to both authorization languages, Client implementers are advised to consider whether their Client implementation should actually attempt to modify access rules at all:
358+
A separation between a client executing application-specific logic and a client executing authorization-related logic might be beneficial in terms of separation of concerns, maintainability, and re-usability of software components [<a href="#ref-authapp">BKY+24</a>].
359+
Such approach might rely on
360+
<ul>
361+
<li>access requests to update access control rules accordingly on a Server</li>
362+
<li>issued by the application-logic client</li>
363+
<li>processed by either a particular Client that is able and trusted to manage access controls (such as an access management or authorization application) or by custom Server functionality</li>
364+
</ul>
365+
<div class="issue">
366+
<a href="https://github.com/solid/specification/issues/775"><h4><span>[New Work Item]: Access Requests and Grants</span></h4></a>
367+
<p>
368+
Access requests and their processing are currently are poposed work item to the CG.
369+
Different approaches exist within the community; no consensus has been reached yet.
370+
Implementers are encouraged to provide their implementation expierence as input to the community's discussion.
371+
</p>
372+
</div>
373+
<div class="note">
374+
<h4><span>Editor's Note (Christoph)</span></h4>
375+
<p>
376+
Not sure if the above item provides sufficient guidance or is simply confusing due to the lack of context in the Solid Protocol for access requests altogether.
377+
I, Christoph, am torn on the above item on access requests. Would like to hear the groups's opinion here.
378+
</p>
379+
</div>
380+
</li>
331381
</ul>
332382
</div>
333383
</section>
334384

335385
<section id="solid-oidc" inlist="" rel="schema:hasPart" resource="#solid-oidc">
336386
<h3>Solid-OIDC</h3>
337387
<div datatype="rdf:HTML" property="schema:description">
338-
<p><a href="https://solidproject.org/TR/oidc">Solid-OIDC</a> (CG-DRAFT/FINAL, v0.1.0) is included in the Solid26 release.</p>
339-
<div class="note">
340-
<h4><span>Note</span></h4>
341-
<p>Solid-OIDC v0.1.0 is not widely implemented. In particular, the recommended flow of User-Managed Access (UMA) is not supported by any open source Solid Server implementation (yet). Current implementations rely on the access token issued by the OpenID Provider of the user to authenticate the user at a Solid Storage. A corresponding Group Note document that accurately reflects current implementations is being drafted by Christoph Braun. This PR is waiting for that document to be available and ready to reference before merging.</p>
388+
<p><a href="https://solidproject.org/TR/oidc">Solid-OIDC</a> (CG-DRAFT/FINAL, v0.1.0) is included with the following comments:</p>
389+
<ul>
390+
<li>
391+
<p>Despite Solid26 including Solid-OIDC v0.1.0, it is not widely implemented. In particular, the Solid-OIDC recommended flow of User-Managed Access (UMA) is not supported by any open source Solid Server implementation. Current implementations rely on the access token issued by the OpenID Provider of the user to authenticate the user at a Solid Storage.</p>
392+
</li>
393+
</ul>
394+
<div class="note">
395+
<h4><span>EDITORS' Note</span></h4>
396+
<p>
397+
A corresponding Group Note document that accurately reflects current implementations is being drafted by Christoph Braun. This PR is waiting for that document to be available and ready to reference before merging.
398+
</p>
342399
</div>
343400
</div>
344401
</section>
345402

346403
<section id="web-access-control" inlist="" rel="schema:hasPart" resource="#web-access-control">
347404
<h3>Web Access Control</h3>
348405
<div datatype="rdf:HTML" property="schema:description">
349-
<p><a href="https://solidproject.org/TR/2024/wac-20240512">Web Access Control</a> (CG-DRAFT/FINAL, 2024-05-12) is included in this release. Solid26 requires servers to implement WAC as their access control mechanism.</p>
350-
<div class="note">
351-
<h4><span>Note</span></h4>
352-
<p>We would like to update the referenced WAC version and snapshot link to include the proposed changes in <a href="https://github.com/solid/web-access-control-spec/pull/134">solid/web-access-control-spec#134</a>, if they are merged in time.</p>
406+
<p><a href="https://solidproject.org/TR/2024/wac-20240512">Web Access Control</a> (CG-DRAFT/FINAL, 2024-05-12) is included with the following comments:</p>
407+
<ul>
408+
<li>
409+
WAC is actively being maintained and developed: To officially extend WAC with functionality desired by the community, a corresponding proposal is seeking implementers' feedback (<a href="https://github.com/solid/web-access-control-spec/pull/134">solid/web-access-control-spec#134</a>).
410+
</li>
411+
</ul>
353412
</div>
354-
</div>
355413
</section>
356414
</div>
357415
</section>
@@ -369,7 +427,6 @@ <h4><span>Note</span></h4>
369427
</div>
370428
</div>
371429
</section>
372-
373430
</div>
374431
</section>
375432

@@ -386,7 +443,14 @@ <h2>References</h2>
386443
<dt id="ref-wac">[WAC]</dt>
387444
<dd><cite><a href="https://solidproject.org/TR/2024/wac-20240512">Web Access Control</a></cite>. W3C Solid Community Group. URL: <a href="https://solidproject.org/TR/2024/wac-20240512">https://solidproject.org/TR/2024/wac-20240512</a></dd>
388445

389-
446+
<dt id="ref-authapp">[BKY+24]</dt>
447+
<dd>
448+
<cite>AuthApp - Portable, Reusable Solid App for GDPR-Compliant Access Granting</cite>.
449+
Andreas Both; Thorsten Kastner; Dustin Yeboah; Christoph Braun; Daniel Schraudner; Sebastian Schmid; Tobias Käfer; Andreas Harth.
450+
ICWE 2024: 199-214.
451+
URL: <a href="https://doi.org/10.1007/978-3-031-62362-2_14">https://doi.org/10.1007/978-3-031-62362-2_14</a> ,
452+
Postprint available at: <a href="https://publikationen.bibliothek.kit.edu/1000172187">https://publikationen.bibliothek.kit.edu/1000172187</a>
453+
</dd>
390454
</dl>
391455
</div>
392456
</section>

0 commit comments

Comments
 (0)