- Servers are strongly encouraged to implement Web Access Control (WAC), see below. + The Solid Protocol requires Servers to conform to Web Access Control (WAC) or Access Control Policy (ACP), or both, and requires Clients to conform to both. In practice Clients typically conform to one. A Client that 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 each satisfies.
+WAC is the simpler and extensible access-control language, covering the cases used by most current Solid applications. Its policies are RDF with monotonic semantics — adding or removing triples preserves the truth of existing grants. Optional acl:origin matching is not intended as client identification [WAC § Security and Privacy Review]. WAC does not express deny rules, application-aware matching beyond Origin, or conditional grants.
ACP is the more expressive alternative, suited to requirements that go beyond what WAC can directly express. Policies can carry allow and deny rules in the same document with non-monotonic semantics, so a deny rule can override a prior allow. Subjects can additionally be identified by the application making the request via the acp:client matcher, and rules compose via acp:allOf, acp:anyOf, and acp:noneOf, supporting context-aware policies.
The March 2026 implementation survey yields the following results (archived):
-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.
+The March 2026 implementation survey (data, archived):
+Most surveyed Clients implement one access control language, not both.
- 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 feedback to the community. - If WAC is not able to satisfy the requirements, implementers might consider ACP or other suitable mechanisms 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. -
@@ -443,7 +440,14 @@
Web Access Control (CG-DRAFT, v1.0.0, 2024-05-12) is included.
-Access Control Policy (v0.9.0, 2022-05-18) is included.
+solid:oidcIssuer 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.Client matcher has limited practical coverage (demonstration). CG work on conditional grants is in progress.acp:client, though practical coverage varies across implementations (demonstration). CG work on extending WAC with conditional grants is in progress.acl:Control on such a resource can read that data; consent to include someone in an ACL is transitive to every Control holder [WAC § Security and Privacy Review].- The Solid Protocol requires Servers to conform to Web Access Control (WAC) or Access Control Policy (ACP), or both, and requires Clients to conform to both. In practice Clients typically conform to one. A Client that 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 each satisfies. + The Solid Protocol requires Servers to conform to Web Access Control (WAC), Access Control Policy (ACP), 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.
WAC is the simpler and extensible access-control language, covering the cases used by most current Solid applications. Its policies are RDF with monotonic semantics — adding or removing triples preserves the truth of existing grants. Optional acl:origin matching is not intended as client identification [WAC § Security and Privacy Review]. WAC does not express deny rules, application-aware matching beyond Origin, or conditional grants.
ACP is the more expressive alternative, suited to requirements that go beyond what WAC can directly express. Policies can carry allow and deny rules in the same document with non-monotonic semantics, so a deny rule can override a prior allow. Subjects can additionally be identified by the application making the request via the acp:client matcher, and rules compose via acp:allOf, acp:anyOf, and acp:noneOf, supporting context-aware policies.
ACP is the more expressive alternative, suited to requirements that go beyond what WAC can directly express. Policies can carry allow and deny rules in the same document with non-monotonic semantics, so a deny rule can override a prior allow. Subjects can additionally be identified by the application making the request via the acp:client matcher, and rules composed via acp:allOf, acp:anyOf, and acp:noneOf, supporting context-aware policies.
The March 2026 implementation survey (data, archived):
From 5435add26f45693c90a31ae090c689d60741e91c Mon Sep 17 00:00:00 2001 From: Jesse Wright <63333554+jeswr@users.noreply.github.com> Date: Sat, 25 Apr 2026 23:44:53 +0100 Subject: [PATCH 3/6] =?UTF-8?q?Signpost=20WAC=201.1=20ED=20additions=20in?= =?UTF-8?q?=20=C2=A72.1=20commentary?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Per @elf-pavlik on PR #783: the 'WAC does not express…' sentence was correct for WAC 1.0 (which solid26 pins) but readers should know that two of the three gaps close in the WAC 1.1 ED via acl:condition (application-aware matching and conditional grants). Deny rules remain absent in WAC 1.1, consistent with WAC's monotonic design. No implementations known at time of publication. Co-authored-by: elf PavlikThe Solid Protocol requires Servers to conform to Web Access Control (WAC), Access Control Policy (ACP), 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.
-WAC is the simpler and extensible access-control language, covering the cases used by most current Solid applications. Its policies are RDF with monotonic semantics — adding or removing triples preserves the truth of existing grants. Optional acl:origin matching is not intended as client identification [WAC § Security and Privacy Review]. WAC does not express deny rules, application-aware matching beyond Origin, or conditional grants.
WAC is the simpler and extensible access-control language, covering the cases used by most current Solid applications. Its policies are RDF with monotonic semantics — adding or removing triples preserves the truth of existing grants. Optional acl:origin matching is not intended as client identification [WAC § Security and Privacy Review]. WAC 1.0 (pinned here) does not express deny rules, application-aware matching beyond Origin, or conditional grants. Application-aware matching and conditional grants land as acl:condition in WAC 1.1 ED, with no implementations known at the time of publication.
ACP is the more expressive alternative, suited to requirements that go beyond what WAC can directly express. Policies can carry allow and deny rules in the same document with non-monotonic semantics, so a deny rule can override a prior allow. Subjects can additionally be identified by the application making the request via the acp:client matcher, and rules composed via acp:allOf, acp:anyOf, and acp:noneOf, supporting context-aware policies.
The Solid Protocol requires Servers to conform to Web Access Control (WAC), Access Control Policy (ACP), 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.
-WAC is the simpler and extensible access-control language, covering the cases used by most current Solid applications. Its policies are RDF with monotonic semantics — adding or removing triples preserves the truth of existing grants. Optional acl:origin matching is not intended as client identification [WAC § Security and Privacy Review]. WAC 1.0 (pinned here) does not express deny rules, application-aware matching beyond Origin, or conditional grants. Application-aware matching and conditional grants land as acl:condition in WAC 1.1 ED, with no implementations known at the time of publication.
WAC is the simpler and extensible access-control language, covering the cases used by most current Solid applications. Its policies are RDF with monotonic semantics — adding or removing triples preserves the truth of existing grants. Optional acl:origin matching is not intended as client identification [WAC § Security and Privacy Review]. WAC 1.0 (pinned here) does not express deny rules, application-aware matching beyond Origin, or conditional grants. Application-aware matching and conditional grants land as acl:condition in WAC 1.1 ED, with no implementations known at the time of publication.
ACP is the more expressive alternative, suited to requirements that go beyond what WAC can directly express. Policies can carry allow and deny rules in the same document with non-monotonic semantics, so a deny rule can override a prior allow. Subjects can additionally be identified by the application making the request via the acp:client matcher, and rules composed via acp:allOf, acp:anyOf, and acp:noneOf, supporting context-aware policies.
The Solid Protocol requires Servers to conform to Web Access Control (WAC), Access Control Policy (ACP), 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.
-WAC is the simpler and extensible access-control language, covering the cases used by most current Solid applications. Its policies are RDF with monotonic semantics — adding or removing triples preserves the truth of existing grants. Optional acl:origin matching is not intended as client identification [WAC § Security and Privacy Review]. WAC 1.0 (pinned here) does not express deny rules, application-aware matching beyond Origin, or conditional grants. Application-aware matching and conditional grants land as acl:condition in WAC 1.1 ED, with no implementations known at the time of publication.
ACP is the more expressive alternative, suited to requirements that go beyond what WAC can directly express. Policies can carry allow and deny rules in the same document with non-monotonic semantics, so a deny rule can override a prior allow. Subjects can additionally be identified by the application making the request via the acp:client matcher, and rules composed via acp:allOf, acp:anyOf, and acp:noneOf, supporting context-aware policies.
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 acl:condition in WAC 1.1 ED, with no implementations known at the time of publication.
ACP is expressive. It supports allow and deny rules (deny overrides allow), application-aware (acp:client) and issuer (acp:issuer) matching, verifiable-credential matching (acp:vc), and policy composition via acp:allOf / acp:anyOf / acp:noneOf. ACP does not define its own access modes. The ACP draft has not been revised since 2022 and has no public test suite or Security and Privacy Considerations section.
The March 2026 implementation survey (data, archived):
From 244025911fb6ed5da0b56cd75bc0a7e5cf418c53 Mon Sep 17 00:00:00 2001 From: Jesse Wright <63333554+jeswr@users.noreply.github.com> Date: Sun, 26 Apr 2026 13:11:19 +0100 Subject: [PATCH 6/6] Drop ACP maintenance/no-modes caveat sentence Removes the 'ACP does not define its own access modes. The ACP draft has not been revised since 2022 and has no public test suite or Security and Privacy Considerations section.' sentence from the ACP paragraph, keeping the description focused on capabilities only. --- solid26.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/solid26.html b/solid26.html index bf2b0c22..717b2dec 100644 --- a/solid26.html +++ b/solid26.html @@ -385,7 +385,7 @@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 acl:condition in WAC 1.1 ED, with no implementations known at the time of publication.
ACP is expressive. It supports allow and deny rules (deny overrides allow), application-aware (acp:client) and issuer (acp:issuer) matching, verifiable-credential matching (acp:vc), and policy composition via acp:allOf / acp:anyOf / acp:noneOf. ACP does not define its own access modes. The ACP draft has not been revised since 2022 and has no public test suite or Security and Privacy Considerations section.
ACP is expressive. It supports allow and deny rules (deny overrides allow), application-aware (acp:client) and issuer (acp:issuer) matching, verifiable-credential matching (acp:vc), and policy composition via acp:allOf / acp:anyOf / acp:noneOf.