Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 29 additions & 22 deletions solid26.html
Original file line number Diff line number Diff line change
Expand Up @@ -295,8 +295,9 @@ <h2>Table of Contents</h2>
<li class="tocline"><a class="tocxref" href="#solid-protocol"><bdi class="secno">2.1</bdi> <span>Solid Protocol</span></a></li>
<li class="tocline"><a class="tocxref" href="#solid-oidc"><bdi class="secno">2.2</bdi> <span>Solid-OIDC</span></a></li>
<li class="tocline"><a class="tocxref" href="#web-access-control"><bdi class="secno">2.3</bdi> <span>Web Access Control</span></a></li>
<li class="tocline"><a class="tocxref" href="#webid-1"><bdi class="secno">2.4</bdi> <span>WebID 1.0</span></a></li>
<li class="tocline"><a class="tocxref" href="#webid-profile"><bdi class="secno">2.5</bdi> <span>Solid WebID Profile</span></a></li>
<li class="tocline"><a class="tocxref" href="#access-control-policy"><bdi class="secno">2.4</bdi> <span>Access Control Policy</span></a></li>
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<li class="tocline"><a class="tocxref" href="#access-control-policy"><bdi class="secno">2.4</bdi> <span>Access Control Policy</span></a></li>

<li class="tocline"><a class="tocxref" href="#webid-1"><bdi class="secno">2.5</bdi> <span>WebID 1.0</span></a></li>
<li class="tocline"><a class="tocxref" href="#webid-profile"><bdi class="secno">2.6</bdi> <span>Solid WebID Profile</span></a></li>
</ol>
</li>
<li class="tocline">
Expand Down Expand Up @@ -361,6 +362,11 @@ <h2 property="schema:name">Specifications</h2>
<td><a href="https://solidproject.org/TR/2024/wac-20240512">(CG-DRAFT, v1.0.0, 2024-05-12)</a></td>
<td><a href="#web-access-control">Link</a></td>
</tr>
<tr>
<td><a href="https://solidproject.org/TR/2022/acp-20220518">Access Control Policy</a></td>
<td><a href="https://solidproject.org/TR/2022/acp-20220518">(v0.9.0, 2022-05-18)</a></td>
<td><a href="#access-control-policy">Link</a></td>
</tr>
Comment on lines +365 to +369
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<tr>
<td><a href="https://solidproject.org/TR/2022/acp-20220518">Access Control Policy</a></td>
<td><a href="https://solidproject.org/TR/2022/acp-20220518">(v0.9.0, 2022-05-18)</a></td>
<td><a href="#access-control-policy">Link</a></td>
</tr>

</tbody>
</table>

Expand All @@ -376,28 +382,19 @@ <h3>Solid Protocol</h3>
</li>
<li>
<p>
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>.
The Solid Protocol requires Servers to conform to Web Access Control (<a href="#web-access-control">WAC</a>), Access Control Policy (<a href="#access-control-policy">ACP</a>), or both, and requires Clients to conform to both. In practice, Clients typically conform to one. A Client that conforms to only one and needs to read or write access-control rules will not interoperate with a Server that implements only the language the Client does not support; Clients that do not interact with access-control rules are unaffected. Implementers choosing between the two should consider the requirements satisfied by each.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The Solid Protocol requires Servers to conform to Web Access Control (<a href="#web-access-control">WAC</a>), Access Control Policy (<a href="#access-control-policy">ACP</a>), or both, and requires Clients to conform to both. In practice, Clients typically conform to one. A Client that conforms to only one and needs to read or write access-control rules will not interoperate with a Server that implements only the language the Client does not support; Clients that do not interact with access-control rules are unaffected. Implementers choosing between the two should consider the requirements satisfied by each.
The Solid Protocol requires Servers to conform to Web Access Control (<a href="#web-access-control">WAC</a>), Access Control Policy (<a href="#access-control-policy">ACP</a>), or both, and requires Clients to conform to both. In practice, Clients typically conform to one. A Client that conforms to only one and needs to read or write access-control rules will not interoperate with a Server that implements only the language the Client does not support; Clients that do not interact with access-control rules are unaffected.

</p>
<p>WAC is pragmatic, user-friendly, and extensible. WAC 1.0 does not support deny or non-additive policy composition, application-aware matching beyond Origin, or issuer matching; application-aware matching, issuer matching, and other conditional grants land as <code>acl:condition</code> in <a href="https://web.archive.org/web/20260425225256/https://solid.github.io/web-access-control-spec/">WAC 1.1 ED</a>, with no implementations known at the time of publication.</p>
<p>ACP is expressive. It supports allow and deny rules (deny overrides allow), application-aware (<code>acp:client</code>) and issuer (<code>acp:issuer</code>) matching, verifiable-credential matching (<code>acp:vc</code>), and policy composition via <code>acp:allOf</code> / <code>acp:anyOf</code> / <code>acp:noneOf</code>.</p>
Comment on lines +387 to +388
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<p>WAC is pragmatic, user-friendly, and extensible. WAC 1.0 does not support deny or non-additive policy composition, application-aware matching beyond Origin, or issuer matching; application-aware matching, issuer matching, and other conditional grants land as <code>acl:condition</code> in <a href="https://web.archive.org/web/20260425225256/https://solid.github.io/web-access-control-spec/">WAC 1.1 ED</a>, with no implementations known at the time of publication.</p>
<p>ACP is expressive. It supports allow and deny rules (deny overrides allow), application-aware (<code>acp:client</code>) and issuer (<code>acp:issuer</code>) matching, verifiable-credential matching (<code>acp:vc</code>), and policy composition via <code>acp:allOf</code> / <code>acp:anyOf</code> / <code>acp:noneOf</code>.</p>
<p>WAC is considered pragmatic, easy to understand, and extensible. WAC is deny-by-default and authorizations grant access that would otherwise be denied. WAC is being actively maintained and moved forward to include community-desired features in a convenient way. ACP is considered expressive yet complex. ACP allows to flexibly compose policies that grant and deny access. ACP is currently not actively maintained.</p>

<div class="note" id="note-survey">
<h4><span>Note</span></h4>
<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> (<a href="https://web.archive.org/web/20260415092405/https://raw.githubusercontent.com/w3c-cg/solid/64d2c5383976b9e3a51f854576245dbb4bda1ce1/implementations/wac-acp.2026-04-01.csv">archived</a>):</p>
<ul>
<li>
For WAC, the data shows 13 server-side implementations, deployment in 11 services, and 19 client-side implementations.
WAC is considered the pragmatic, user-friendly, and extensible standard that effectively covers nearly all of the use cases from current Solid Apps.
</li>
<li>
For ACP, the data shows 4 server-side implementations, deployment in 1 service, and 4 client-side implementations.
ACP is considered an expressive and complex alternative that might be chosen to satisfy corresponding use-case specific requirements.
</li>
</ul>
<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>
<p>The <a href="https://lists.w3.org/Archives/Public/public-solid/2026Mar/0019.html">March 2026 implementation survey</a> (<a href="https://github.com/w3c-cg/solid/blob/main/implementations/wac-acp.2026-04-01.csv">data</a>, <a href="https://web.archive.org/web/20260415092405/https://raw.githubusercontent.com/w3c-cg/solid/64d2c5383976b9e3a51f854576245dbb4bda1ce1/implementations/wac-acp.2026-04-01.csv">archived</a>):</p>
<ul>
<li>WAC: 13 server-side implementations, deployment in 11 services, 19 client-side implementations.</li>
<li>ACP: 4 server-side implementations, deployment in 1 service, 4 client-side implementations.</li>
</ul>
<p>Most surveyed Clients implement one access control language, not both.</p>
</div>
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
</div>
</div>
<p>
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>.
In case WAC seems not to satisfy implementers' requirements, implementers are strongly encouraged to verify their understanding of the matter in community discussion by providing <a href="https://solidproject.org/TR/wac#document-feedback">feedback</a> to the community.
If WAC is not able to satisfy the requirements, implementers might consider ACP or <a href="https://github.com/solid/authorization-panel/issues/121#issuecomment-4253548683">other suitable mechanisms</a> to achieve their goals.
</p>
<p>Clients are advised to consider that they might not be able to interoperate with every conforming Server they encounter and are thus encouraged to. Clients are encouraged to signal corresponding issues to their users.</p>

<p>
In case WAC seems not to satisfy implementers' requirements, implementers are strongly encouraged to verify their understanding of the matter in community discussion by providing <a href="https://solidproject.org/TR/wac#document-feedback">feedback</a> to the community.
If WAC is not able to satisfy the requirements, implementers might consider ACP or <a href="https://github.com/solid/authorization-panel/issues/121#issuecomment-4253548683">other suitable mechanisms</a> to achieve their goals.
Client implementers are advised to consider that their Client implementation will not be able to interoperate with every conforming Server their Client might encounter.
</p>
</li>
<li>
<p>
Expand Down Expand Up @@ -443,7 +440,14 @@ <h4><span>EDITORS' Note</span></h4>
<h3>Web Access Control</h3>
<div datatype="rdf:HTML" property="schema:description">
<p><a href="https://solidproject.org/TR/2024/wac-20240512">Web Access Control</a> (CG-DRAFT, v1.0.0, 2024-05-12) is included.</p>
</div>
</div>
</section>

<section id="access-control-policy" inlist="" rel="schema:hasPart" resource="#access-control-policy">
<h3>Access Control Policy</h3>
<div datatype="rdf:HTML" property="schema:description">
<p><a href="https://solidproject.org/TR/2022/acp-20220518">Access Control Policy</a> (v0.9.0, 2022-05-18) is included.</p>
</div>
</section>
Comment on lines +445 to 451
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<section id="access-control-policy" inlist="" rel="schema:hasPart" resource="#access-control-policy">
<h3>Access Control Policy</h3>
<div datatype="rdf:HTML" property="schema:description">
<p><a href="https://solidproject.org/TR/2022/acp-20220518">Access Control Policy</a> (v0.9.0, 2022-05-18) is included.</p>
</div>
</section>


<section id="webid-1" inlist="" rel="schema:hasPart" resource="#webid-1">
Expand Down Expand Up @@ -649,7 +653,7 @@ <h4><span>Note</span></h4>

<ul>
<li><strong>WebID integrity.</strong> The meaning of a WebID depends on the integrity of its Profile Document. <cite><a class="bibref" href="#ref-webid-profile">Solid WebID Profile</a></cite> § <a href="https://solid.github.io/webid-profile/#protected-properties">Protected properties</a> requires servers to protect <code>solid:oidcIssuer</code> triples from non-owner modification; not all servers do, and on such a server any agent with write access to the document can change the issuer.</li>
<li><strong>Authorization authorizes agents, not applications.</strong> WAC and ACP both grant access to the agent (WebID) behind a request. Any application acting as that agent inherits its access. WAC has no mechanism to constrain by application; ACP's <code>Client</code> matcher has limited practical coverage (<a href="https://youtu.be/5Q1nUmGdaXE">demonstration</a>). CG work on conditional grants is in progress.</li>
<li><strong>Authorization of applications.</strong> WAC grants access to agents (WebIDs); an application acting as an authorized agent inherits that agent's access. ACP extends matching to applications via <code>acp:client</code>, though practical coverage varies across implementations (<a href="https://youtu.be/5Q1nUmGdaXE">demonstration</a>). CG work on extending WAC with conditional grants is in progress.</li>
<li><strong>Consent transitivity in access control.</strong> Access-control and group resources can themselves carry personal data. Any agent with <code>acl:Control</code> on such a resource can read that data; consent to include someone in an ACL is transitive to every Control holder [<cite><a class="bibref" href="#ref-wac">WAC</a></cite> § <a href="https://solidproject.org/TR/2024/wac-20240512#security-privacy-review">Security and Privacy Review</a>].</li>
<li><strong>Client identity.</strong> Solid-OIDC has no mechanism for strongly-asserted client identity, and browser-based clients cannot hold client secrets. Authorization Servers treat anonymous clients with low-trust policies; confidential-client protections are unavailable in typical SPA deployments [<cite><a class="bibref" href="#ref-solid-oidc">Solid-OIDC</a></cite> § <a href="https://solidproject.org/TR/2022/oidc-20220328#out-of-scope">Out of Scope</a>, § <a href="https://solidproject.org/TR/2022/oidc-20220328#client-secrets">Client Secrets</a>].</li>
</ul>
Expand All @@ -670,6 +674,9 @@ <h2>References</h2>
<dt id="ref-wac">[WAC]</dt>
<dd><cite><a href="https://solidproject.org/TR/2024/wac-20240512">Web Access Control</a></cite>. Sarven Capadisli. W3C Solid Community Group. 12 May 2024. Draft Community Group Report, Version 1.0.0. URL: <a href="https://solidproject.org/TR/2024/wac-20240512">https://solidproject.org/TR/2024/wac-20240512</a></dd>

<dt id="ref-acp">[ACP]</dt>
<dd><cite><a href="https://solidproject.org/TR/2022/acp-20220518">Access Control Policy</a></cite>. Matthieu Bosquet. W3C Solid Community Group. 18 May 2022. Version 0.9.0. URL: <a href="https://solidproject.org/TR/2022/acp-20220518">https://solidproject.org/TR/2022/acp-20220518</a></dd>

Comment on lines +677 to +679
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<dt id="ref-acp">[ACP]</dt>
<dd><cite><a href="https://solidproject.org/TR/2022/acp-20220518">Access Control Policy</a></cite>. Matthieu Bosquet. W3C Solid Community Group. 18 May 2022. Version 0.9.0. URL: <a href="https://solidproject.org/TR/2022/acp-20220518">https://solidproject.org/TR/2022/acp-20220518</a></dd>

<dt id="ref-webid">[WEBID]</dt>
<dd><cite><a href="https://www.w3.org/2005/Incubator/webid/spec/identity/">WebID 1.0</a></cite>. Andrei Sambra; Stéphane Corlosquet. W3C WebID Community Group. 5 March 2014. W3C Editor's Draft. URL: <a href="https://www.w3.org/2005/Incubator/webid/spec/identity/">https://www.w3.org/2005/Incubator/webid/spec/identity/</a></dd>

Expand Down