WebID vs did:solidus: An Honest Architecture Comparison
WebID has real deployments behind it and did:solidus does not yet. That imbalance is the honest starting point for this comparison, and nothing below argues it away. What follows is a description of two different architectural bets about where digital identity should live, written for readers who will check every claim, including the concession you just read.
What WebID does, and why it has worked
A WebID is an identity that lives at a web address. You are https://alice.example/profile#me, and anyone who fetches that URL gets back a machine-readable RDF document, typically written in Turtle, describing you: your name, your Pod's location, the cryptographic keys or certificates that belong to you. Historically the proof of control was a TLS client certificate (WebID-TLS: proving you hold the private key matching the certificate listed in your profile); Solid's current stack pairs the same identifier with OIDC-based sign-in. WebID predates Solid itself, it grew out of W3C Semantic Web and FOAF community work in the early 2010s, and Solid adopted it as the natural identity layer for a system already built on Linked Data.
The reasons it has worked in production are worth stating plainly, because they are exactly the things a newer design has to answer for. A WebID needs nothing but web infrastructure: a URL, a server, a document. It composes with everything HTTP already does. It is self-describing and human-inspectable: you can open a profile in a browser and read it. And it has been operated at institutional scale for years, which is not a detail; it is the strongest form of evidence an architecture can have.
What did:solidus does differently, stated as a bet
did:solidus moves the identifier off the identity owner's web server and onto a chain. Three properties follow, and each is a design intention, not a proven superiority:
- Revocation and rotation are consensus rules, not document edits. Deactivating or rotating a did:solidus identity is a native chain transaction; once finalized, every resolver in the network gives the same answer. WebID handles the same needs through certificate expiry and profile changes, mechanisms that work, but whose consistency depends on caches and on the server saying so.
- Correlation resistance is a first-class concern. Solidus derives pairwise per-verifier DIDs from one seed, so two services that compare notes cannot join their views of the same user by identifier alone. A WebID is, by design, one public URL, globally consistent, and globally correlatable.
The cost of this bet is equally plain: did:solidus requires an entire consensus network to exist where WebID requires a web server. Nothing stronger than that is claimed here.
The real fork in the road
The deepest divergence is not certificates versus chains. It is that Solid never adopted W3C DIDs or Verifiable Credentials at all. Solid's model secures documents: WAC/ACL rules govern who may read and write resources in a Pod, and identity exists to make those rules enforceable. The DID/VC model secures claims: statements about a person, signed by an issuer, presented to a verifier, checkable without calling anyone. These are overlapping but different problems. A Solid Pod answers "who may access this data?" A verifiable credential answers "who says this about me, and can you check it?" Solidus is built DID/VC-native because its founding problem is the second question; Solid's architecture is built document-native because its founding problem was the first. Neither choice is a mistake: they are different bets about which question comes first.
What Solid solved that Solidus has not
Solid solved personal data storage and access control, LDP for read/write, WAC/ACL for authorization, RDF for interoperability, and proved it in institutions that do not tolerate research-grade software. Solidus has not solved that problem and does not claim to. Our own Pod is Solid-compatible (Community Solid Server with a did:solidus bridge) not Solid-conformant, and its own entry says exactly that.
Check both sides yourself
WebID: dereference the profile URL of any public Solid pod, an Inrupt-hosted pod works. You will get back an RDF document, typically Turtle, describing its owner. That round-trip is WebID.