What Is Web Access Control (WAC)?

Web Access Control (WAC) is a small, RDF-based vocabulary for saying who is allowed to read, write, append to, or control a given resource on the web. Instead of a central permissions database that some platform owns and you have to trust, a WAC rule is itself a piece of Linked Data: it sits next to, or references, the resource it protects, naming which identities or groups get which modes of access. The resource carries its own rule. Nothing else has to.

Three requesters, one gate, checked every time. The image shows an outcome, not a type of requester: the same mechanism runs for all three, and two of them clear it.

Where WAC comes from

WAC grew out of W3C Semantic Web community work on access-control vocabularies, predating any single application of it. The Solid protocol, designed by Tim Berners-Lee's Solid project and specified through the W3C Solid Community Group, carried WAC forward as its default authorization model, pairing it with WebID for identity and LDP for the underlying read/write mechanics. A newer, more expressive alternative called Access Control Policies (ACP) exists alongside WAC in the Solid ecosystem today: it is not a replacement, and WAC has not been deprecated by it. Both are live options a Solid server can support; this page is about WAC specifically, because it is the one Solidus's own Pod product touches.

How a check actually happens

The mechanism is simple enough to state in one pass. A WAC rule names a resource, then names one or more identities or groups, then names which modes of access each one gets: read, write, append, or control. That rule is checked on every single request, not once at login, not cached for a session, but re-evaluated each time something asks to touch the resource. There is no separate "session permission" layer sitting above it; the rule next to the resource is the entire authorization decision.

This is a genuinely different mental model from a central permissions database that a platform owns and every request has to consult. In WAC, the permission travels with the data. Move the resource, and its access rule is data too: it can move with it, or be re-derived, rather than living in a system-of-record somewhere else entirely. For anyone used to reasoning about access control as rows in an RBAC or ABAC table, this is the adjustment: the rule is attached to the thing, not to a role hierarchy sitting above the thing.

The outcome of a check is binary and immediate. A request the rule permits reaches the resource. A request it doesn't gets a 401 (no credentials) or 403 (wrong credentials) and reaches nothing: the same failure mode any WAC-governed server returns, with no softer fallback path. That is exactly what the image above shows: two requesters cleared, one stopped, all three checked by the identical gate.

Solidus's own usage, one example, not the subject

Solidus's Pod product uses WAC-style access control today, as one concrete instance of the mechanism described above, not as something Solidus designed or extended. Under the current architecture, that enforcement runs inside the Community Solid Server component in front of Solidus Pod: real Solid software, built by the Solid community, not code Solidus wrote. The permission check is the third leg of Solidus Pod's own request path, a did:solidus-carrying request gets translated into a shape the server recognizes, and only then does WAC decide whether it clears the resource. The full mechanics of that path, including the identity-translation step ahead of it, are covered on How Solidus Pod Works; this page won't re-explain that leg, because it belongs there.

One phrasing distinction matters and is deliberate: Solidus Pod's authorization is described here as WAC-style, never WAC-conformant. Solidus has not independently run its stack against the full WAC conformance suite, so conformant is not a claim available to make yet, and this page doesn't make it.

The proof, and its limit

WAC is checkable by anyone, on any Solid pod, without needing to trust Solidus at all: request a WAC-protected resource without credentials and confirm a 401 or 403 comes back; request the same resource again with the right credentials and confirm access. That round trip is the entire mechanism, running exactly as described above. The vocabulary itself is documented at github.com/solid/web-access-control-spec, worth reading as a reference, not as proof of anything Solidus has done.

The limit is worth stating plainly rather than skipping around: we don't have a Solidus-specific conformance report to point to. A mostly-generic explainer page doesn't get an exemption from saying so.

Where this leaves the mechanism

WAC is Solid's answer to a question every access-control system eventually has to answer: does the permission live with the data, or with a platform sitting over the data? WAC's answer is the former, checked per request, with no central store of its own. Solid built that answer, proved it against real deployments, and carried it forward as its default. Solidus did not build it, does not extend it, and, where its own Pod product uses it, is one more implementation running the mechanism as specified, not a step ahead of it.