Solid-OIDC
Also called Solid OpenID Connect
Solid-OIDC is how you log into a Solid Pod. Solid (see Solid Protocol) is Tim Berners-Lee's architecture for personal data storage, your photos, documents, and app data live in a Pod you control, not scattered across whichever company's servers happen to host each app. For that to work, a login has to prove two things at once: who you are (your WebID, a URI that identifies you across every Solid app you use, see that entry) and which Pod is yours, usually the same information, since a WebID profile document typically points straight at its owner's Pod.
Solid-OIDC gets there by taking OpenID Connect (see that entry) and adding
two things standard OIDC doesn't require: a mandatory webid claim in the
ID Token, so any Solid app immediately knows which WebID just logged in;
and DPoP-bound access tokens (see DPoP) as the default, not an optional
extra, because a Pod is a general-purpose read/write store for
potentially sensitive personal data, an ordinary bearer token that any
thief could reuse is a weaker guarantee than Solid wants by default.
Where it comes from
Solid-OIDC is specified by the W3C Solid Community Group, the same standards body behind WebID, Linked Data Platform, and Web Access Control (see those entries), the pieces that, together, make up the Solid Protocol. It is a Community Group Report rather than a full W3C Recommendation, meaning it's real, actively-used specification work, but hasn't gone through W3C's formal Recommendation track the way something like DID Core has. Solidus designed none of it.
Solidus today
auth.solidus.network implements Solid-OIDC as the login mechanism for
pod.solidus.network: a DPoP-bound, ES256-signed access token carrying a
webid claim and aud: 'solid', verified directly by Community Solid
Server against Solidus's published JWKS. Solidus's Pod is honest about
what it is underneath, Community Solid Server plus a did:solidus
identity bridge, JWT+Postgres storage, and WAC-style access rules, not a
fully Solid-Protocol-conformant deployment (see the Pod entry for the
complete statement). This whole stack runs on Solidus's public testnet;
there is no mainnet identity, and none of it has been independently
audited.
See also
Pod is the product this login flow protects. WebID is the identity claim Solid-OIDC carries. DPoP is the sender-constraining mechanism it requires by default. Solid Protocol is the broader architecture this is one piece of.
Where it comes from
Someone else specified this. Solidus assembles it.
Solid-OIDC is a specification of the W3C Solid Community Group, the same body behind WebID, LDP, and WAC/ACL (see those entries), that profiles OpenID Connect and adds RFC 9449 DPoP-bound access tokens plus a mandatory `webid` claim, so a Solid client can authenticate a user and know which Pod to talk to in one step. It is a Community Group Report, not a W3C Recommendation: an important distinction the DID entry makes about did:solidus too: this is real, actively-implemented work from the Solid community, but it has not been through the W3C's formal standards-track process the way DID Core has. Solidus wrote none of the specification; auth.solidus.network implements it.
How to check this
Running in production today.
Visit pod.solidus.network and sign up, the login flow round-trips through auth.solidus.network's live /authorize and /token endpoints, requesting the `webid` scope with a DPoP proof, exactly as this entry describes. curl https://auth.solidus.network/.well-known/openid-configuration and check for the `dpop_signing_alg_values_supported` field as a no-account preview of the same capability.