solid26: draft WAC/ACP wording for CG discussion#783
Conversation
Action item from the 2026-04-22 CG call. Details in the PR body.
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.
|
|
Thanks @uvdsl — fair point. Dropping the Wednesday deadline; happy to follow the usual CG process (mailing list / comments here / agenda item on a CG call when the discussion is ready for resolution). Since the wording won't be at consensus by the wider Solid26 launch, I propose that we launch with a clear warning banner at the top of the document ("some parts of this document are in the final stages of consensus building") and placeholder text in place of this draft — i.e. only the access-control-language recommendation is held back. The placeholder PR is #785. Take whatever time you need with the detailed review. |
Apply the two suggestion comments on PR #783: - Three-item list 'WAC, ACP, or both'; comma after 'In practice'; scope the interop sentence explicitly to single-language Clients; 'requirements satisfied by each'. - Parallelise the ACP composition clause: 'rules composed via …'. Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
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 Pavlik <elf-pavlik@hackers4peace.net>
Use https://web.archive.org/web/20260425225256/... as a permanent reference for the WAC 1.1 ED while https://solidproject.org/TR/2026/ wac-20260420 is being created in #784. Once that snapshot PR is merged, this link should be swapped to the immutable TR URL.
| 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. | ||
| </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 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 <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> |
There was a problem hiding this comment.
Do not commit this suggestion until #784 is merged. Once the snapshot PR lands, the https://solidproject.org/TR/2026/wac-20260420 URL will resolve to the immutable TR snapshot and we can drop the Wayback link.
| <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 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 <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>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 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 <code>acl:condition</code> in <a href="https://solidproject.org/TR/2026/wac-20260420">WAC 1.1</a>, with no implementations known at the time of publication.</p> |
WAC paragraph: - One-line opener: 'WAC is pragmatic, user-friendly, and extensible.' - Drop the monotonic-semantics explanation (item 5: not useful to implementers). - Reframe limitations as 'WAC 1.0 does not support deny or non-additive policy composition, application-aware matching beyond Origin, or issuer matching' (item 15: deliberate-design framing implicit; items 16/17: drop 'more expressive' / 'beyond WAC' rhetoric). - Keep WAC 1.1 ED signpost via the Wayback URL (will swap to TR snapshot once #784 merges). ACP paragraph: - One-line opener: 'ACP is expressive.' - Drop 'more expressive alternative' / 'suited to requirements beyond WAC' rhetoric; replace with concrete capabilities grounded in the ACP spec (acp:client, acp:issuer, acp:vc, acp:allOf/anyOf/noneOf). - Note ACP does not define its own access modes (per spec). - Add maintenance/test/no-S&P-section caveats (items 10/18).
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.
|
Thanks @csarven for the detailed review. Walking through it. Process and the action this PR is carrying outTo clarify what this PR is: at the 2026-04-22 CG call the action I took was to propose neutral text for the WAC/ACP framing in solid26. That's what's drafted here, for discussion. To be clear, the action was not to write up finalised or agreed-upon text; there was not a finalised or agreed-upon statement from the call. My own statements on the recommendation question have evolved, and I want to be transparent about that:
I want to acknowledge: I was the one who initially pushed for a stronger recommendation, hoping for consensus on one language. That was naive in retrospect, and the resulting need to walk it back has consumed considerable CG meeting time over multiple calls. I apologise for that. We clearly do not have consensus right now, and that is why this PR aims to be as neutral as possible — identifying the capabilities of each language and presenting the data, rather than reaching a conclusion from the data. I'm suggesting we pause the push for an exclusive recommendation, and if we revisit it at all, it should be when we have more implementations, more implementor engagement, and more robust data. The placeholder approach for the wider Solid26 launch — keeping the access-control-language wording out of the launch until consensus is reached — is in #785. The wider implementor engagement is already in flight: the persona-groups operating model presented by @Roberto-Breitman at 2026-04-08 is the mechanism by which we expect more implementations and more structured feedback to land in the CG over the coming months. Solid26 is set up to feed into that process. The implementors guide is not where the normative call should be made; that belongs in the protocol-level specifications, on the back of better data. Two underlying discussionsTwo questions are getting mixed up here that it's worth separating: (1) What use cases is Solid aiming to support? This is too broad for the implementors guide. The CG has a UC&R document at solid.github.io/authorization-panel/authorization-ucr which already records requirements such as capability access (§3.2.1), credential access (§3.2.2), and time-bound access (§3.6.1) — none of which WAC supports today without server-side extensions. On your Cloud Storage reference: Solid's scope is broader than the social-web framing. Even many of the WAC proponents have industry use cases. There are also regulated use cases that are not commercial, such as regulated health data, for which there is a whole session at the Solid Symposium. The implementors guide is not the place to redraw the scope of Solid. (2) Whether WAC provides sufficient coverage of Solid's use cases. There is genuine disagreement here, but there is also visible agreement that extensions to WAC are needed to satisfy some use cases — the conditional-grants work that lands as Even though WAC 1.1 is not recommended in the implementors guide, mentioning it as an aside does not stop implementors engaging with Solid26 from discovering it and choosing to use or test it — especially those on the more research-oriented end of the adoption spectrum, who are well-placed to give the CG feedback on whether WAC + 1.1 extensions cover their requirements. Other languages have also been raised in the meetings — ODRL among them, including by you at 2026-04-22 ("we might want to go back and consider other authorization mechanisms, like ODRL"). As such, having the debate over strongly recommending a language — when we do not have CG consensus, and when we may end up discarding both WAC and ACP for something else — is not desirable; nor is continuing the discussion a good use of time at present. Solid26's broader purposeSolid26 is explicitly aimed at increasing implementor feedback to the CG, including from WAC implementors. The persona-groups model presented by Roberto at 2026-04-08 is the structured channel for that. The hope is that the data gathered through this exercise lets us make better-grounded decisions than we can today. The lack of substantive ACP-side implementor feedback is a real issue — but so is the broader lack of implementor feedback the CG has had to work with on access-control choices generally. Solid26 is set up to address that. Tone / wording fixes from the reviewSeveral of the wording critiques have been applied in
Items left as-is
Happy to act on anything else with specific direction. |
Once again, it wasn't a CG action. We can stop here. But I'll entertain the extensively structured comment you shared. I didn't find the proposal neutral. On the contrary, as I've pointed out, it had obvious bias, diminishing WAC, and elevating ACP. I find it trivial to read between the lines.
If you are literally taking the quoted text from the minutes as the only input for evaluation, yes, I can see why you would arrive at that proposal. The fact of the matter is the essence of what was concluded in that meeting. If you believe that the minutes are incomplete or at least don't fully capture that, I can agree with you on that. I have expressed elsewhere that minutes should be updated to fill in the blanks. If you would like to raise an objection on the point that WAC was to be recommended and ACP not based on your recollection of the meeting, we can evaluate that in a CG meeting, and get to the bottom of it.
That was not at all a "decision". That was something you spoke. Nothing more. It is important not to conflate the idea that voicing oneself equates CG consensus / action / decision etc., in any way.
You're making my point for me. The 2026-04-01 call was the "decision". There was no objection to that decision nor any significant information provided for consideration to re-consider the decision.
Then let's back all the way up. Stop the presses. But wait, before we do that, could you explain why a "formal vote" is necessary? Or let me ask another question, do you think a vote is the best way to resolve this issue? I suggested several times now that if there is a dispute, then propose a criteria to better analyse the data, we (CG) can then find a way to agree on that criteria before going further.
"Re-opening the framing" wasn't called for by the CG. An alternative framing was suggested, but that was never agreed. In fact, there were objections to that framing. I don't see the proposed text reflecting the views of the objections on re-framing.
None of those statements rise up to a change. It is not even new or relevant information to the subject matter. If anything, those statements are already captured in the data. Data > statements.
We are already past consensus. What you may be thinking is that we don't have unanimous consensus. No, it is not required to move forward.
But it isn't. And it does not follow the original intention of solid26. What's happening right now is known as moving the goal posts. Many of the things being said or "reframed" rests on that logical fallacy, among others. We can walk through each statement if you like.
I need those quantifiable. See also what I said re criteria. You are welcome to propose one. The CG can evaluate it.
Once again, that conflicts with prior CG decision.
Why do you feel/think this is acceptable CG input as is? Or do you/ODI think that CG needs to operate around that? If so, why? What you cite is literally "ODI Persona Groups Operating Model" - great, that about sums it up.
The CG literally did not ask for this to begin with, so it is unclear what this is responding to or is it just a statement?
It is incorrect to think that any mechanism needs to support all of the use cases nor they are desired. If the ecosystem has already converged on WAC based on the data collected, that speaks for itself.
This is once gain red herring. I consistently used the phrase "open web" both in the call and in writing. And I even corrected you when what I said ("open web") was thrown back as "social web". The point wasn't that Solid can't or shouldn't address "fixing the web" for all possible use cases one can imagine in society. The point was about focus and the actual problems that people have on the web / in their lives towards "fixing the web" and what the CG can genuinely solve without reinventing wheels. Coming up with solutions to problems that people (in masses) didn't ask for is not something the CG has to fix. The CG charter has a scope: https://www.w3.org/community/solid/charter/#scope and that already gives plenty of room.
What's written there is so convoluted and I think it lacks a deep understanding of standards development. WAC, or any CG work item for that matter, does not answer to solid26 or ODI or whatever. WAC is evolving at its own (s)pace based on the wider discussions/implementations. Yes, we understand implementation experience, and don't need to be told about this. In the 2026-04-22 meeting, Christoph and myself already gave a status update about current state and next steps, which includes gathering implementations and listening to feedback before publishing TR/wac .
I personally don't care if WAC 1.1 is mentioned in solid26 or not. WAC 1.1 ED could be mentioned, if the CG agrees, for what it is, and we're working towards publishing WAC 1.1 CG-DRAFT. There is not much more to this story.
Yes, have been since 2019 (e.g., solid/authorization-panel#55 ). It is not strictly about ODRL either. I only called for work / research / study to find ways to bridge the work between Solid stuff and ODRL. Some of which I've proposed (to Solid/ODRL and implemented myself). Again, if Solid wants to "fix the web" and go beyond mechanisms that are quite literally in the same category, it needs to dive into solid/authorization-panel#121 .
Na, that's not what this is about. One recommends, as originally agreed, based on what we have. Not based on hypotheticals or architecture astronomy. We are talking about solid26, not final be all "solid-final-1oneoneeleven-last-rubberstamped.html" that wraps everything up as the ultimate guide on how fixing the web should be done with Solid. I thought this was obvious, but here we are.
Disagree. And there is no CG consensus on that whatsoever. It is not CG material. Just the act of getting some airtime in a CG meeting does not mean that's CG consensus. CG participants with ODI affiliation are welcome to share their findings with the CG. That does not entail that the CG just says "okay".
This is still seriously problematic. The fact that this is describing WAC around ACP's features is an obvious red flag. It is aiming to draw attention to something that the Solid ecosystem for the most part does not even use based on the data. It is an asymmetric rhetorical structure, not neutral presentation. But, that said, WAC has an issue on "deny" at solid/web-access-control-spec#137 and we'll investigate that. The mention around Origin is trying to draw attention on something that's not even particularly widely implemented in WAC, and could very well be deprecated in WAC one day (e.g., solid/web-access-control-spec#130 ). Saying something like "application-aware matching beyond Origin" is not only misleading but shows a misunderstanding of "web origin authorization", which has nothing to do with "application-aware matching". Regarding the language "with no implementations known at the time of publication" in 5435add , why would you even feel the need to say that for an WAC 1.1 ED? Is that actually helping anyone that has no understanding or care about ED / CG-DRAFT or whatever? I find that whole phrasing not only awkward but diminishing (and I know where it comes from). We just got the ED out and noted commitments to implemented in its PR. Literally no one, not even the CG suggested that ED needs to be interpreted as mature.
Because one cancels the other? If it is useful information, why wouldn't you incorporate it? Or is it that implementation feedback that's negative about ACP shouldn't be disclosed in soldi26?
At this point, I'll wait for @uvdsl's review. |
Solid26 (WAC|ACP)Dear all, there is disagreement on what the intent and content regarding access control language(s) in the Solid26 Implementation Guide should be. I have manually reviewed all CG meeting minutes starting 2026-01-07 and linked documents relevant to that discussion. Please find all the relevant links and highlighted contents at the end of this comment. TL;DR:I thus arrive at the conclusion that
This CG followed the usual process of finding consensus or agreement and to reach a decision on a proposal. If individual CG members are not satisfied with the outcome of the decision or the data collection by means of which the outcome was determined, I would urge them to raise an issue to the group and make their concerns explicit in writing such that it can later be referenced. At the same time, I urge CG members to not obstruct implementation of the CG's decision, even though they might personally disagree. Status Quo
Based on the above, I observe that
I further note that
I thus arrive at the conclusion that
This CG followed the usual process of finding consensus or agreement and to reach a decision on a proposal. If individual CG members are not satisfied with the outcome of the decision or the data collection by means of which the outcome was determined, I would urge them to raise an issue to the group and make their concerns explicit in writing such that it can later be referenced. At the same time, I urge CG members to not obstruct implementation of the CG's decision, even though they might personally disagree. Historyhttps://github.com/solid/specification/blob/main/meetings/2026-01-21.mdWhat is now known as "Soli26" was first pitched to the community as "Solid 1.0".
https://github.com/solid/specification/blob/main/meetings/2026-01-28.md
https://github.com/solid/specification/blob/main/meetings/2026-02-04.mdwhere I cautioned about starting a rather fierce discussion on ACP vs. WAC and advocated for considering active maintanence of the specs as an important criterium
https://github.com/solid/specification/blob/main/meetings/2026-03-18.md
This draft lists ACP as the already chosen access control language, recommended by the initial draft. https://lists.w3.org/Archives/Public/public-solid/2026Mar/0019.htmlFrom: Jesse Wright jesse.wright@theodi.org
where the linked document lists ACP as the recommended access control language: https://web.archive.org/web/20260424082149/https://docs.google.com/document/d/1HxaShh5MVRBcimo9uXrtpWPCW6Xo5S9aOLdFAQX2oJY/edit?tab=t.0#heading=h.68mt47qe53m7 https://github.com/solid/specification/blob/main/meetings/2026-03-25.mdhttps://github.com/solid/solid26/blob/d3065b970cf477ed4a19a1e1a2916a4357582f53/content.md mentions again "one of" WAC or ACP. I observe a pattern where "one of (WAC|ACP)" is communicated on W3C records while ACP remains the one already chosen in the shared draft documents.
https://github.com/solid/specification/blob/main/meetings/2026-04-01.md
Gathered data archived: https://github.com/w3c-cg/solid/blob/main/implementations/wac-acp.2026-04-01.csv https://github.com/solid/specification/blob/main/meetings/2026-04-08.md
I notice that the wording is still in-line with recommending WAC to implementers. I also notice that this is the first time that it is no longer "one of (WAC|ACP)", which had been communicated and agreed to earlier. https://github.com/solid/specification/blob/main/meetings/2026-04-15.md
IMPORTANT
Extracting Responses that I found most relevant:
https://github.com/solid/specification/blob/main/meetings/2026-04-22.md
Directly contradicts how Solid26 was pitched to the CG in the 2026-01-21 meeting, where OB said "having a clear line in the sand" and JW said "Promote a single Access Controll spec"
Reviewed; did not find content relevant to the WAC/ACP debate:
|
uvdsl
left a comment
uvdsl
left a comment
There was a problem hiding this comment.
I disagree with @elf-pavlik. This is wording seems controversial to me.
The original suggested wording painted WAC as simple and points out what it is NOT good for (without elaborating on what the used terms, e.g., conditional grants or context-aware policies, mean). The suggested wording does not at all do WAC justice with regards to what it can do. In fact, the suggested wording compresses the acknowledgement of this to a side-note. Instead, the suggested wording paints ACP as the alternative to go beyond "simple" requirements, which implies that WAC is simple because it can only satisfy simple requirements. This is misleading. WAC is simple and it can satisfy quite complex requirements. In addition, citing the security considerations of WAC to point out a specific missing feature (in TR, not ED) to implementers, while not even acknowledging that ACP does not even have any security considerations or privacy considerations sections is applying double standards.
The currently proposed wording is also problematic in that it again points out which of ACP's features WAC does not seem to support. This is problematic because you can use WAC extensions and agent classes to model complex authorization rules including client restrictions and issuer restrictions. While the wording acknowledges that WAC is actively being maintained and moved forward to include features desired by the community in a convenient way, this is immediately played down that there were no implementations. Implementations are in progress, e.g., my own, and a previous attempt for CSS can be found here and thus be quickly updated from what I see.
The "action" that was listed in the minutes: As far as I can determine, there was a suggestion to explain use cases and requirements re WAC/ACP at the very end of the minutes, by the point of which we were already more than 30min over time. The minutes does not detail whose suggestion this was. That @jeswr took this as an action does not imply consensus or agreement from the group. The meeting minutes' "actions" section has been a rough TODO list (at best) to keep track of in the group, given that we rarely had technical discussions and let alone decisions in the last 2 years. That said, I appreciate the effort.
The issue remains that the suggested changes include ACP as a recommended access control language. As far as I understand from the meeting minutes, there was no agreement to add ACP as a recommended access control language to Solid26. Please amend the proposal accordingly, e.g., by accepting my suggested changes, and remove ACP as a recommended specification.
| <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. |
There was a problem hiding this comment.
| 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>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> |
There was a problem hiding this comment.
| <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> |
| <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> |
There was a problem hiding this comment.
| </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> |
|
|
||
| <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> |
There was a problem hiding this comment.
| <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> |
| <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> | ||
|
|
There was a problem hiding this comment.
| <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> |
| <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> |
There was a problem hiding this comment.
| <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> |
| <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> |
There was a problem hiding this comment.
| <li class="tocline"><a class="tocxref" href="#access-control-policy"><bdi class="secno">2.4</bdi> <span>Access Control Policy</span></a></li> |
5 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