How Solidus Pod Works

Solidus Pod runs Community Solid Server 7.1.9, pinned and unmodified. That is real Solid software, built by the Solid community rather than by us. What follows describes only what we put around it. Solid itself is not our work and this page does not describe it.

A request carries a did:solidus-based identity rather than a bearer token tied to one service. A bridge rewrites it into the Solid-OIDC/WebID shape the pod server understands. The server then checks that rewritten request against the Web Access Control rules attached to the resource being asked for. Permitted requests get through. Everything else stops at the gate.

Three components, three jobs, and only the middle one is ours.

What CSS is, and isn't ours

Community Solid Server is the independently maintained reference implementation of the Solid Protocol, the specification Tim Berners-Lee's project designed for personal data pods, storage and Linked Data Platform read/write semantics.

Solid solved this problem years before Solidus existed: a working, RDF-based way to store personal data outside any single app's database, with institutional deployments reported behind it. We run CSS 7.1.9 as-is. No forked storage layer. No rewritten LDP handling. No access-control engine of ours underneath it. Boot it locally, ask for the root, and the response carries real LDP Link headers, because a real Solid server is answering.

We did not build any of that and do not claim to have. What we added sits in front of CSS as a bridge, not inside it as a replacement.

The request path, step by step

Identity enters as a did:solidus. A caller authenticates the same way they do anywhere else on the network, with a did:solidus identifier registered in the W3C DID Method Registry, rather than a WebID profile URL or a service-specific API key. This is the one architectural choice in the path that is ours, and it is a bet rather than a proven improvement. WebID has years of production deployment behind it.

A bridge translates that identity into the shape CSS expects. CSS speaks Solid-OIDC and WebID, not did:solidus. Nobody has taught it to, and we have not asked it to learn. So the request passes through a translation layer that maps a did:solidus identity into a Solid-OIDC/WebID-shaped credential CSS can evaluate on its own terms. That is real conversion work, one scheme's assertion of who is asking rewritten into another scheme's expected format, not a cosmetic relabel. It is the only genuinely new piece of infrastructure in the diagram. Everything on either side of it is upstream Solid software or a well-understood permission check.

CSS checks the translated request against WAC. Once the request looks like something CSS recognises, Web Access Control runs its normal check against that resource's rules. WAC is the RDF-based vocabulary Solid uses to say who may read, write, append to or control a resource. This enforcement happens inside CSS. We did not write a parallel authorization engine and we do not intercept or override the decision. The bridge's job ends at step two.

The gate opens, or it does not. A permitted request reaches the resource. An unpermitted one reaches nothing, with the same 401 or 403 any Solid pod returns to an unauthorized caller. Both outcomes are the same mechanism running the same rule. There is no friendlier failure path and no silent allow. The diagram draws the stopped branch with the same weight as the successful one on purpose, because a permission system that only shows its happy path is not describing how it works.

What's shipped, what isn't

This page describes the mechanism as architected. Which of the three legs is verified in production, versus proven only in local development, is a separate question with its own answer. See What's Actually Live in Solidus Pod for the itemized verdict on each piece: CSS's confirmed local boot, the bridge's production status, and the Solid Conformance Test Suite gate we have not cleared. Do not read this page's description of the path as a claim that every leg is confirmed live. That is the other page's job.

For the identity-translation leg, and what choosing did:solidus over WebID costs and buys, see WebID vs did:solidus. The permission check has its own WAC/ACL deep-dive here.

What this makes Solidus Pod, and what it doesn't

Unmodified CSS plus a did:solidus bridge makes Solidus Pod Solid-compatible and migration-ready. Data moves in and out without much friction.

It does not make Solidus Pod Solid-conformant, and we do not describe it that way. Passing the Solid Conformance Test Suite against the deployed instance is specific, unfinished engineering, not a formality we are choosing to skip. Until that gate is cleared and independently checkable, the honest word is compatible. In that sentence Solidus is the junior party, not Solid.

Said here, not left for someone else to notice.