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

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., 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.

I think we need to look at a broader picture.

Most clients need neither, so making either MUST on all clients leads to perfectly operational clients being non conformant. Specialized AuthorizationManager class of products could be an appropriate spec:requirementSubject for any MUST on client side.
LWS will only define access requests and access grants. So neither WAC, ACP, you-name-it will become web standards in next year, two, likely more, if ever.

While CSS provides config level choice between WAC and ACP. It doesn't support both at the same time. As far as I can tell there are 0 stable implementations doing it. Luke's paa.hub might be the only existing experiment 🥼🧪

@VirginiaBalseiro

@VirginiaBalseiro, thank you for taking the time and effort to compile this proposal. This looks interesting and I think this idea is worth exploring at the very least. I will provide my perspective on this in the coming days when I have more bandwidth to work with.

@elf-pavlik, might I politely ask you to entertain ideas and proposals made by members of the CG to the CG at broad? Your comment basically discards this proposal from the get-go, which does not create an environment that feels welcoming to new ideas. You might be looking at the bigger picture but this proposal is quite targeted and deserves its own consideration. Writing a particular application role into specification or even looking to adapt existing W3C Recommendations is an entirely separate topic - or if you'd want to: proposals - compared to this particular proposal at hand. Instead of saying that something does not work right now, you could also ask how the proposing member envisions how it will work? 🙂

@jeff-zucker, @Potherca, @angelo-v, do you have thoughts on this proposal by Virginia?

I have been using WAC in practice for years, for me it seems like an obvious choice for a baseline for both clients and servers. I can see that there are needs for more sophisticated authorization patterns, but those can be standardized on top of that, be it ACP or an extension of existing WAC.

I don't agree that most clients would not need either: even if they do not manage access, they need a standard way to discover what access is given. I am doing this currently via the WAC-Allow header.

@VirginiaBalseiro

I think that @VirginiaBalseiro's proposal is the healthiest option for the community as a whole. It supports the most widely used, it allows the most capable. No client has to abandon their current methods. Some servers may need to add support for one or the other control mechanism. This is as it should be - spreading the weight of the decision onto clients is not tenable. We can hope for an eventual point where we can converge on a single mechanism. But until that day, let's adopt this proposal as a way to give clarity to developers of client apps.

@VirginiaBalseiro

I apologise if the first part of my comment came through as discarding this proposal. I agree that bigger picture conversation doesn't belong here and while I see need to have it, it isn't specific to this proposal.

Thank you @VirginiaBalseiro for putting your efforts into this proposal!

Still the second part of my comment may be relevant. Unless I miss some other existing codebases, CSS seems most fit to try implementing this aproach, it already can handle WAC or handle ACP separately. Trying to add combined policy engine would provide opportunity to apply this proposal somewhere.

I missed related conversation during SoSy, if the intent is to slowly incubate this idea and go through some conceptual drills first before attempting to implement it, I think CG is a good venue, we can simply keep track on maturity and capture known implementations, commitment to implement, or even just intent to implement.

Sidenote: https://valueflo.ws had small 1.0 launch party yesterday, it has a nice way to track intent -> commitment -> event/activity We could possibly apply it to proposals but I'm drifting out of topic again....

@elf-pavlik

Thanks @elf-pavlik .

On implementation: I think the proposal is actually well-grounded in what already exists. Most servers implement WAC today so they'd be compliant under this change without modification. The only servers needing to change are ACP-only ones. Same thing on clients: most already implement WAC only.

So we're not waiting for implementations to catch up to a proposed standard but rather the proposal is catching the spec up to the implementations based on feedback and data. CSS adding a combined engine would be interesting but isn't required by the proposal itself or the current spec.

Servers MUST conform to WAC.
Servers MAY conform to ACP.

If due to context specific requirements server MUST implement ACP. How can we evaluate if in addition requiring MUST implement WAC is even feasable to implement?

What's proposed is still an improvement over the current spec. It may not be covering everything, but that's OK. Combined support isn't required by the proposal. I understand your concern, but honestly I think this is always going to be a tradeoff, and keeping things as they are now is a higher burden for the majority.

The current MUST isn't actually delivering interop. ACP-only clients don't talk to WAC servers today, and viceversa. The majority of the ecosystem isn't interoperating, as WAC-only and ACP-only implementations don't interoperate with each other today. So the proposal isn't making anything worse but rather making the requirement more efficient and reflecting reality.

For a server that genuinely can't implement WAC for context-specific reasons, they'd be non-conformant under the proposal, yes. But that's the same shape of situation WAC-only clients and ACP-only servers are already in relative to each other today. The proposal moves the non-conformance from the majority to the minority, which is the point.

The proposal moves the non-conformance from the majority to the minority, which is the point.

Since we are talking about proposals being incubated in the CG (noting ACP possibly unmaintained ATM) not drafts on a REC track. Wouldn't approach that defines WAC profile, ACP profile, XYZ profile provide a better (more inclusive) ground for incubation?

Solid 26 could encourage WAC profile while mentioning ACP profile as another option available when needed (TODO: a detailed features breakdown). Solid would also offer clear advise that interop across AuthZ profiles is limited. This way we wouldn't ostracise other proposals exploring solution space for problems within a common problem space.

Since clean interop between WAC and ACP may not be possible, instead of effectively labeling WAC as Solid and ACP as non-Solid, we can acknowledge the current state of art and provide clear (eg. AuthZ profiles) way that would fit CG's purpose - inclusive incubation space.

@VirginiaBalseiro

To me the main problem addressed by @VirginiaBalseiro'a proposal is, as she says at the top of this thread, that currently the burden of access control decisions is "spread across every Client author". This is harmful to the eco-system and a cause of confusion. A clear, unambiguous MUST for WAC seems, to me, the only policy that has any hope of addressing this problem in the near future. It would not stop either servers or clients from experimenting with other approaches but would lend clarity, especially for new developers less likely to have an immediate need for more complex solutions.

@jeff-zucker

Thanks @jeff-zucker , that captures the core motivation well.

@elf-pavlik , the "profiles" framing is essentially the current "either or both" model with new labels. The whole point of this proposal is that the current model spreads the cost onto every client author, and the data shows that most clients only implement one mechanism. Renaming the options doesn't change that. A clear MUST is what gives client authors, especially new ones, something stable to build against. And as you note, ACP appears to be unmaintained at the moment while WAC is actively being developed (1.1 is at editor's draft with concrete implementation commitments). That's another reason a WAC baseline reflects where the ecosystem actually is.

The proposal doesn't ostracise ACP. ACP remains a MAY, deployments that need it can implement it, and ACP-specific interop continues exactly as it does today. What it does is pick a baseline so the majority of the ecosystem isn't taxed for an option most of it doesn't use.

I think we've covered the substantive ground here and I wouldn't like to turn this into such a long thread that it deters others from catching up. I'd like to hear from others in the CG before we go further. If there are strong objections beyond what's been raised, a meeting seems like the right next step.

@VirginiaBalseiro

Thanks again, @VirginiaBalseiro, for putting this forward. I appreciate the engagement and discussion by the group.

I want to highlight some points of particular importance:

setting a baseline: As @angelo-v put it, more sophisticated authorization can be implemented on top of that baseline. There would be a "floor of interoperability" that all clients can expect to work.
incremental spec improvement: As @VirginiaBalseiro said, the current specification (i.e., the theory) does not encourage interoperability to the point that clients actually follow suit (i.e., the practice). This change is of the kind that does not require a hard cut, which I find quite appealing.
backwards compatible: As @jeff-zucker pointed out, nothing will break with this change. Not more at least, than it is today anyway. But it provides a clear path forward, where I find myself agreeing with Jeff as well.
forward compatible: As @elf-pavlik mentioned, there might also be XYZ authorization mechanism that could be useful to incubate in addition to WAC or ACP. And I agree! But instead of defining side-by-side profiles where interoperability between clients and servers remains in the state we have today, I would add to Virginia's reasoning that the "baseline + extension 1 + extension 2 + ..." actually helps incubation of new proposals into Solid because adopting another extension on-top of what works so-far is less of a disruption than to throw out the old profile and adopt the new (or even deploy a whole new server). And once implementation reality is that virtually all servers support a certain level above the baseline, we could even think of just raising the baseline to that level, in the spirit of @jeff-zucker's desire to converge on a single mechanism.

Two additional points for consideration:

capability discovery: As mentioned in the issue description, discovery of a server's capabilities becomes a critical feature. If/When we find a nice/good/workable solution here, then we are golden.
implementing of multiple authorization mechansims: @elf-pavlik, I can assure you that this is possible. 🙂 For example, my play-around pod implementation (Java) relies on JakartaEE and its Filters, where I have one Filter for WAC and one for enforcing server-configured rules. If any of the Filter finds a matching rule (either in WAC or in the rules configured in the server), access is granted. For an example of server-configured rules, think of the "owner" of a Solid Pod. So, speculating about being able to implement it or not does not pose an argument against this proposal. The discussion around how to implement or what a clients expectations would be remains totally valid.

@uvdsl

Thanks @uvdsl and it's a great news that you have implementation where this proposal could be tested.

To illustrate potential issues let's consider following scenario.

Hypothetical server implements both WAC and ACP.

Alice with ACP client creates some resources and sets ACR, where
- it uses deny feature
- it reuses existing external matchers
- uses acp:vc matcher
Bob arrives with WAC client and wants to make small change to access policy, for example remove access of one agent and add access of another agent
Alice comes back with ACP client to fine tune policies, for example change something in one of those external reusable matchers

Can you describe some rough strategy for a server to support such scenarios?

As for the baseline. Do you imagine WAC aiming for feature parity with ACP? (we still don't have a reference for the diff) I guess this may require WAC to become non-monotonic. Also once WAC reaches such feature parity, how can we tell that then ACP will not be the option that implementers prefer. Currently we may be comparing apples with oranges. I recall that 5 years ago Henry was entertaining idea of WAC+ and there was an attempt to evaluate it side by side with ACP. Having non-interoperable profiles until parity is reached may be a better alternative to potentially in 2-3 years realizing that at that point it's simply better to just use ACP. I don't think we have basis today to make strong predictions either way.

@elf-pavlik

@elf-pavlik, just quickly, as to add not too lengthy of comments such that others in the community (that have less bandwith than you or me) indeed can catch up:

As for the baseline. Do you imagine WAC aiming for feature parity with ACP?

As far as I understand, this is exactly NOT the point of this proposal. Whether or not WAC or ACP respectively evolve is independent of establishing a baseline that all clients can rely on.

Having non-interoperable profiles until parity

I'd prefer advocating for interoperability in the ecosystem that we have today instead of waiting and talking -- possibly at infinitum -- about future development. That future development might still happen regardless of whether or not this proposal is moved forward. And this is, I think, what @jeff-zucker also expressed with his desire to hopefully converge in the future but to get the ball rolling now with this proposal.

(I don't have much capacity right now, going to ESWC this weekend... so apologies for delayed responses)

@Roberto-Breitman

The proposal doesn't ostracise ACP. ACP remains a MAY, deployments that need it can implement it, and ACP-specific interop continues exactly as it does today.

We still haven't established that implementing both WAC and ACP is feasible for servers. This approach may only work in theory.

I'd like to hear from others in the CG before we go further. If there are strong objections beyond what's been raised, a meeting seems like the right next step.

I think most comments so far are from pro-WAC faction. We probably need some feedback from need-ACP minority. @Roberto-Breitman do you know how to bring it up to attention of whoever may need ACP?

I know this is the W3C, but it worth remembering the aphormism we have in IETF, courtesy Dave Clark:

We reject: kings, presidents and voting. We believe in: rough consensus and running code.

ACP spec is an unfinished document that has not been worked on in the CG for as long as I can remember. How can anyone expect rough consensus within the CG on something that has not been actively worked or isn't a completed output of the CG?

The survey showed few ACP implementations vis-a-vis WAC, fewer in the public domain. Is there sufficiently varied examples of running code that community members can review?

I think that this proposal is already too generous in recommending ACP. What is the exact specification that the CG might be recommending -- a document not updated since 2022? The entire process around Solid26 (which the ODI explains as a marketing exercise for Solid) unfortunately creates an impression of ODI governance having a privileged position in the CG, whereas the ODI staff are only ordinary participants. Maybe the proponents of ACP will publicly work on the specification in the CG and make code available to CG participants for inspection. Then the CG participants might be convinced to small "r" recommend ACP in, say, Solid27.

As an aside: Solid26 is not a specification. What's up with the BCP14/RFC2119 language?

Chairs: As a general practice, please mark what hat you are wearing when you are expressing your opinions in the comments!

This issue was discussed in the 2026-06-03 CG meeting: #793

@CxRes

@CxRes FYI:

The survey showed few ACP implementations vis-a-vis WAC, fewer in the public domain. Is there sufficiently varied examples of running code that community members can review?

We (as PDS Interop) have the intention of adding support for ACP to the PHP Solid Server and Solid Nextcloud. Explicitly as there have been requests for non WAC mechanisms from parties interested in our hosted PHP Solid Server service.

What is the exact specification that the CG might be recommending -- a document not updated since 2022?

As an implementor I do not have an issue that a spec I am trying to implement has no recent changes. But maybe I am misunderstanding your point?

Chairs: As a general practice, please mark what hat you are wearing when you are expressing your opinions in the comments!

I am not a chair, but I am currently wearing clothes, but no shoes.

@elf-pavlik

chair hat off, implementer's hat on

Hi all,

here is my implementation experience.
This does not reflect how it "must" or "should" be done, this just shows how it can be done.

This is just one way of thinking about this.
It is the way I think about this and how I implemented checking WAC rules, Solid OWNER status, ...

I drew up a mermaid diagram to visualise how side-by-side support of baseline WAC and other mechanisms such as Solid's OWNER status and ACP might look like.

In a nutshell, each mechanism operates on its own:

WAC is evaluated as usual.
ACP is evaluated as usual.
OWNER rules are evaluated as usual.

But they all pipe not only their individual result but also the reason for their respective result to the (access control) decision point:

If WAC would grant access, it indicates that it found an authorization that grants access.
If WAC does not find a matching authorization, it indicates that no authorization was found that grants access.
If ACP would grant access, it indicates that it found a policy that grants access.
If ACP does not find a matching policy, it indicates that no policy was found that grants access.
If ACP would deny access, it indicates that it found a policy that explicitly denies access.
If the OWNER rules of the implementation are matched, it indicates that such rule grants access.

What the (access control) decision point decides based on the above provided information, is an implementation decision.
Depending on the use case, one might decide that an explicit deny takes priority over everything else.
In other use cases, one might decide that the OWNER rules take priority over everything else, even an explicit deny.
And in yet other use cases, additional information might be provided to the access control decision point such that priority might even be decided dynamically, e.g., based on who defined which authorization/policy/rule.
(Thinking about ODRL here...)

How exactly the final decision is derived, is up to the implementation in my opinion.
I would not dare to assume that there is a one-size-fits all strategy here.
Most importantly, the fact that the evaluation strategy is implementation-specific is not an issue for the Solid Protocol in terms of interoperability: It really does not make a difference to the client HOW EXACTLY the access control decision was derived on the server, only the result counts for the client.

flowchart TD

Request --> AUTHN

subgraph AccessControl["Access Control"]

    subgraph Authentication["Authentication"]
        AUTHN["Solid-OIDC Check"]
    end
    subgraph Authorization["Authorization"]
        WAC["WAC Check"]
        OWNER["Owner Check"]
        ACP["ACP Check"]
    end

    AC["Access Control Decision"]
end

    AUTHN -- WebID --> AC
    AUTHN -- WebID --> WAC
    AUTHN -- WebID --> OWNER
    AUTHN -- WebID --> ACP

    WAC -- "WAC rule
    if match found" --> AC
    OWNER -- "OWNER rule
    if WebID match" --> AC
    ACP -- "ACP rule (Allow)
    if match found" --> AC
    ACP -- "ACP rule (explicit Deny)
    if match found" --> AC

    AC -- "OK, UNAUTHORIZED, or FORBIDDEN" --> RESP["Response"]

But what about the scenario @elf-pavlik raised: Alice with an ACP client, Bob with a WAC client, both editing policies on the same resource?

There is no mapping, translation, or synchronization between WAC ACLs, ACP policies, or other rule languages such as ODRL.
They are and remain simply independent pieces of information -- they can live in the same file (RDF graph) or separate ones, it makes no difference to this architecture.
Each mechanism reads the information it needs based on its own vocabulary, evaluates its own rules, and reports a result with its reason to the decision point.

Concretely:

When Bob's WAC client edits access, it edits only WAC ACLs. ACP policies remain unaltered as the WAC client does not speak ACP.
When Alice returns and fine-tunes an external matcher, her ACP client only modifies ACP policies. Neither client can corrupt the other's policy store because each client only touches the triples in the vocabulary it speaks -- the rest of the resource simply isn't part of its world.

And just to preempt the obvious "but the ACP client might just overwrite/delete the WAC ACLs (and vice versa)" -- that problem is the same when you only have one policy language (or even more general: any information resource): If a client simply overwrites whatever is in a file/document/(information resource) with only the stuff itself produces or understands, then that client is simply destructive. That problem/behaviour is independent of whether there are WAC ACLs and ACP policies in that resource or just one or none.

This architecture also shows why the "baseline + extensions" model supports incubating future mechanisms (ACP today, ODRL or whatever comes next tomorrow) without disrupting the baseline: a new rule language can be added as another check feeding the same decision point, rather than requiring a new profile or a new server. In an already running deployment even (!), no need to spin up yet-another-instance-of-a-slightly-different-implementation.

Happy to do a demo in one of the coming CG meetings.

Christoph

implementer's hat off, chair hat on

Navigation Menu

Repository navigation

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

elf-pavlik commented on May 5, 2026

uvdsl commented on May 5, 2026

angelo-v commented on May 5, 2026

jeff-zucker commented on May 5, 2026

elf-pavlik commented on May 6, 2026

VirginiaBalseiro commented on May 6, 2026

elf-pavlik commented on May 6, 2026

VirginiaBalseiro commented on May 6, 2026

elf-pavlik commented on May 6, 2026

jeff-zucker commented on May 6, 2026

VirginiaBalseiro commented on May 7, 2026

uvdsl commented on May 7, 2026

elf-pavlik commented on May 7, 2026

uvdsl commented on May 7, 2026

elf-pavlik commented on May 7, 2026

CxRes commented on May 7, 2026

CxRes commented on May 7, 2026

uvdsl commented on Jun 3, 2026

Potherca commented on Jun 6, 2026

uvdsl commented on Oct 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions