What is Solid-OIDC? The Login Layer We Did Not Build
Solid-OIDC is how a Solid server that has never met you becomes convinced you control a particular identifier.
The problem it solves
A pod belongs to a person, not to the company hosting it. So the server needs to answer a question no password alone answers: is this request coming from whoever controls this identifier, where the identifier is a WebID, an HTTPS URL that points at a profile document.
The move that makes Solid different from an ordinary login: the server does not have to be the one that knows you. Any identity provider you trust can vouch, and the pod server accepts the vouching because it can check it. Your account and your storage are deliberately separable.
The two properties worth understanding
1. The token is bound to a key you hold. A Solid-OIDC access token is not a bearer secret that works for whoever steals it: it is presented together with a proof that the sender holds the matching private key. A copied token, on its own, does not authenticate anybody.
2. Authentication and storage are separate parties. You can change where you log in from without moving your data, and change where your data lives without changing who authenticates you. That is the whole design intent, and it is the part that most "decentralised" systems quietly do not have.
What our deployment actually does
It runs the Community Solid Server, the Solid community's reference implementation. The server says so itself:
$ curl -sI https://pod.solidus.network/profile/card | grep -i 'powered-by\|www-authenticate'
x-powered-by: Community Solid Server
www-authenticate: Bearer scope="openid webid"
We did not write that server, and we did not design this protocol. WebID, the access-control model and the login flow are Solid's work. Saying so first is not modesty: it is the accurate credit, and every page here that describes a difference between us and Solid says this before the difference.
One correction to our own material: an internal note describes this as the login path via
auth.solidus.network. The deployed server's account API advertises its own password login,
registration and reset, and does not reference that host at all. Bounded honestly: that API
lists only the server's own login methods, so this does not prove a third-party issuer is
unavailable, it proves the deployment does not advertise one there.
A probing note, because this host does not behave like our others
On this host, a path that does not exist returns 401, not 404. Unknown paths fall through to
the Solid server, which asks you to authenticate before it will say anything.
$ curl -s -o /dev/null -w '%{http_code}' https://pod.solidus.network/nope-xyz-not-real
401
So a 401 here is not evidence that a resource exists, and anyone testing this deployment, us included, has to use a different signal. We publish that because we got it wrong once on a different host and would rather you did not repeat it.
The one place we diverge, stated as a bet
Solid identifies you with a WebID: an HTTPS URL, resolved over TLS, backed by whoever controls that domain. It is simple, it uses infrastructure that already exists, and it works today.
We anchor identifiers on a chain instead, with revocation enforced by consensus rather than by a domain owner.
That is a bet, not a result. The honest trade:
- WebID depends on a domain and a certificate authority. If the domain lapses or is taken, the identifier is gone.
- Ours depends on a chain, which today is four validators, all operated by us. On "how many independent parties must fail before this breaks", WebID's answer is better than ours right now.
We are not claiming ours is better. We think the trade is worth making and we would rather argue about it than assert it, the longer version.
What this does not settle
Solid-OIDC authenticates. It does not decide what you are allowed to see (that is the access control layer, described here) and it says nothing about whether any claim in your pod is true.
And a formal conformance pass has not happened. Compatible, not conformant, yet is the accurate statement, and conformance cannot be self-asserted: third-party interop proof is the actual bar.