solid26: draft WAC/ACP wording for CG discussion#783
Conversation
Action item from the 2026-04-22 CG call. Details in the PR body.
| 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>) or 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 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. | ||
| </p> | ||
| <p>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 <code>acl:origin</code> matching is not intended as client identification [<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>]. WAC does not express deny rules, application-aware matching beyond Origin, or conditional grants.</p> |
There was a problem hiding this comment.
Some of those features landed in WAC 1.1 but as of now it has no implementations, unless @uvdsl is speed running one
elf-pavlik
left a comment
elf-pavlik
left a comment
There was a problem hiding this comment.
I don't see anything controversial here, could live with it.
There was a problem hiding this comment.
Once again, this is not an "action" of the CG in the sense that there was no agreement or consensus within the formal meeting about the proposed changes here. Anything expressed herein is informal, if not subjective. It is not carrying out the "actions" of the CG.
That said, there are several issues in the language and tone of what's being expressed here, in addition to logical fallacies. I will update this list as we go towards a public publication.
-
It undermines WAC and upsells ACP while leaving out key nuances.
-
It does not adequately or appropriately reflect on the data: https://github.com/w3c-cg/solid/blob/main/implementations/wac-acp.2026-04-01.csv .
-
It does not capture the CG consensus to recommend WAC: https://github.com/solid/specification/blob/main/meetings/2026-04-01.md#wac--acp . Editors are expected to carry out CG consensus.
-
The whole "monotonic" and "non-monotonic" semantics is largely irrelevant to implementers. Folks into theory, mathematics, or purity of some sort may find the labelling interesting, but the property of monotonicity, or lack thereof, is not an actual property of the specifications (such as conformance or testability), nor does it provide any meaningful or practical use for implementers. This information seems to have been added here because of some broad labelling / buzzwording being thrown around recently.
-
It does not incorporate implementers' feedback, especially from those who are on record stating that ACP is unnecessarily complex, particularly where WAC would be adequate.
-
The UI for most applications facing end users is far more convoluted with ACP than with WAC, without any demonstrable improvement. So, no real grounds for most implementers to bother with ACP.
-
ACP may be favourable for admins because of the complexity. This is not something the Solid project was ever optimising for.
-
See https://www.w3.org/DesignIssues/CloudStorage for example to get some orientation on the kind of open web problems the project was aimed at. The implementers guide should be focusing on the primary objectives, not the edges that are of interest to private orgs.
-
The ACP specification has not been maintained for four years. ACP was abandoned. No tests. It doesn't even have a security and privacy consideration section. No significant dialogue in the community. Surely the very first and only release of the specification was so flawless in 0.x form that it didn't need an update?
-
The WAC specification is actively developed. The conditions feature introduced in https://solid.github.io/web-access-control-spec/ moves WAC forward based on community needs, incorporating implementation experience along the way. There has been open and public dialogue among editors, authors, implementers, and users since the very beginning.
-
No meaningful or significant ACP implementation feedback was brought to the CG. The CG did not benefit in any shape or form. If ACP was adequately implemented and used, the public data doesn't reflect that. If ACP was used in closed / private circles, implementation experience was not shared with the CG; it was withheld.
-
Besides the public data, including verifiable implementations, the CG cannot merely remain "neutral" on the technologies here. The implementers' guide was intended to provide some direction.
-
The PR lists ACP features as if their existence alone justifies adoption, with no evidence those features address real implementer needs.
-
WAC's characteristics are framed purely as absences ("does not express..."), casting a deliberate design choice as a deficit.
-
"Suited to requirements that go beyond WAC" is unsubstantiated. No verified implementer case or production deployment is cited.
-
"More expressive" conflates formal expressiveness with practical utility. The two are not the same.
-
ACP's features are listed without any acknowledgement of the corresponding costs, e.g., complexity, maintenance history, or adoption evidence.
-
The paragraph ordering, WAC as simpler baseline then ACP as more capable, implies a natural upgrade path without making that argument explicitly.
-
The renewed push to preserve ACP's status is coming mainly from people who haven't participated in CG discussions in years, on behalf of a specification that hasn't been revised since its first draft in 2022, and been effectively abandoned ever since. That's worth weighing against the implementation data.
-
The best we can do here is recommend WAC to implementers (as already agreed in the CG) and explain that ACP is optional, as it is still being researched in private circles.
Following the usual process of this CG. By welcoming feedback as comments here or via the mailing list, giving members of the CG sufficient time to review and make their mind up about this, and finally put it on the agenda of a CG meeting where one can make the case that all concerns are addressed or further discussion on the status of the PR might happen. This also means that finding this consensus might need time. And I expect this to take time given past discussion. I am currently in the process of reflecting on that. Therefore, I suggest giving the CG sufficient time here. Setting a deadline for Wednesday feels rushed and I would object to that.
As co-editor, I have not preference on the timeline. I merely aim to implement the consensus of the group, making sure that past agreements are honored, and finding accurate wording to this end.
|
4 participants
A preview link can be found here.
Purpose
Action item from the 2026-04-22 CG call: draft a neutral wording change for the WAC/ACP framing in solid26. It is not a proposal for merge on review — it is text to amend in-place until the CG is ready to take a position.
Raised as a separate PR so the access-control wording can be worked on without blocking the rest of solid26 (#776).
Seeking consensus
@elf-pavlik, @uvdsl, @thhck — as CG chairs, how would you like to proceed with getting group consensus on this text? @uvdsl, you're also a co-editor of solid26 — are you ok with this approach wearing both hats?
My suggestion: a 👍 / 👎 reaction vote on this PR, open until Wednesday 2026-04-29, with line-level edit suggestions welcome in the meantime. Happy to follow a different process if you prefer.
Discussion context