Proposal to make WAC the required baseline (MUST) and ACP optional (MAY)

Solid Protocol の #Servers および #Clients に関する現在の要件を読み、WAC 1.1 の Editor’s Draft および引用されている WAC/ACP の実装データと比較してください。WAC を必須、ACP をオプションとするために必要な要件変更に到達して文書化し、WAC 1.1 のリリース後に必要となる capability-discovery の期待事項にも対処できれば完了です。

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:

• Most #Clients only implement one mechanism, and majority of the #Servers and #Clients implement WAC ( https://raw.githubusercontent.com/w3c-cg/solid/refs/heads/main/implementations/wac-acp.2026-04-01.csv ).
• As part of solid26 implementers guide, the CG's conclusion was to also recommend WAC ( https://lists.w3.org/Archives/Public/public-solid/2026Apr/0023.html ).

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., https://github.com/solid/web-access-control-spec/issues/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.