The Solid Protocol currently requires #Servers to conform to either or both WAC and ACP ( #server-wac-acp ), and Clients to conform to both ( #client-wac , #client-acp ).
The CG acknowledges:
The data shows that there is insufficient or inadequate implementations where Clients are conforming to both WAC and ACP, in addition to isolated amount of Servers implementing both WAC and ACP.
A spec requirement that's widely unmet either needs enforcement or needs to match reality, and given the 19:4 Client ratio, leaning toward WAC is the less disruptive direction for the ecosystem.
The "either or both" framing on the Server side pushes the cost of fragmentation onto every Client. Picking a single baseline would eliminate that class of non-interop. The cost lands on the small number of ACP-only Servers rather than being spread across every Client author who has to decide whether to carry two parsers, two vocabularies, and two evaluation models for a feature many apps don't even exercise.
PROPOSAL: update the requirements for #Servers and #Clients in Solid Protocol to be:
- Servers MUST conform to WAC.
- Clients MUST conform to WAC.
- Servers MAY conform to ACP.
- Clients MAY conform to ACP.
This would better reflect the Solid ecosystem given both that the majority of the ecosystem has already converged on WAC while maintaining the possibility for some vendors to also use ACP features in their own environments.
Servers and Clients with ACP-specific needs would continue to interoperate with each other exactly as they do today.
This change should happen once WAC 1.1 CG-DRAFT is released.
solid/web-access-control-spec#134 was merged on 2026-04-22 as per CG consensus, and WAC is now at editor's draft 1.1.0 ( https://solid.github.io/web-access-control-spec/ ) , introducing condition-based authorization, as well as an extension mechanism for additional condition types.
WAC 1.1 introduces condition-based authorization and an extension mechanism, narrowing the feature gap with ACP, and there are concrete implementation commitments for WAC 1.1.
ACP has features such as deny rules and full Boolean composition via acp:noneOf/anyOf/allOf which aren't currently in WAC however some aspects are being looked into (e.g., solid/web-access-control-spec#137 ) in addition to working with WAC's #extensions, but for the cases where those matter, the "MAY conform to ACP" path is right: deployments that need it implement it, and the rest of the ecosystem isn't taxed for use cases it doesn't have.
If we make this change, capability discovery on the Server side becomes more important so Clients can detect which language(s) a Server speaks before attempting to read or write rules. WAC 1.1 already establishes a Link-header pattern for advertising condition support on the ACL resource, and something along those lines could be used by servers to advertise their support for ACP support.
The Solid Protocol currently requires #Servers to conform to either or both WAC and ACP ( #server-wac-acp ), and Clients to conform to both ( #client-wac , #client-acp ).
The CG acknowledges:
The data shows that there is insufficient or inadequate implementations where Clients are conforming to both WAC and ACP, in addition to isolated amount of Servers implementing both WAC and ACP.
A spec requirement that's widely unmet either needs enforcement or needs to match reality, and given the 19:4 Client ratio, leaning toward WAC is the less disruptive direction for the ecosystem.
The "either or both" framing on the Server side pushes the cost of fragmentation onto every Client. Picking a single baseline would eliminate that class of non-interop. The cost lands on the small number of ACP-only Servers rather than being spread across every Client author who has to decide whether to carry two parsers, two vocabularies, and two evaluation models for a feature many apps don't even exercise.
PROPOSAL: update the requirements for #Servers and #Clients in Solid Protocol to be:
This would better reflect the Solid ecosystem given both that the majority of the ecosystem has already converged on WAC while maintaining the possibility for some vendors to also use ACP features in their own environments.
Servers and Clients with ACP-specific needs would continue to interoperate with each other exactly as they do today.
This change should happen once WAC 1.1 CG-DRAFT is released.
solid/web-access-control-spec#134 was merged on 2026-04-22 as per CG consensus, and WAC is now at editor's draft 1.1.0 ( https://solid.github.io/web-access-control-spec/ ) , introducing condition-based authorization, as well as an extension mechanism for additional condition types.
WAC 1.1 introduces condition-based authorization and an extension mechanism, narrowing the feature gap with ACP, and there are concrete implementation commitments for WAC 1.1.
ACP has features such as deny rules and full Boolean composition via
acp:noneOf/anyOf/allOfwhich aren't currently in WAC however some aspects are being looked into (e.g., solid/web-access-control-spec#137 ) in addition to working with WAC's #extensions, but for the cases where those matter, the "MAY conform to ACP" path is right: deployments that need it implement it, and the rest of the ecosystem isn't taxed for use cases it doesn't have.If we make this change, capability discovery on the Server side becomes more important so Clients can detect which language(s) a Server speaks before attempting to read or write rules. WAC 1.1 already establishes a
Link-headerpattern for advertising condition support on the ACL resource, and something along those lines could be used by servers to advertise their support for ACP support.