DID vs WebID. Two Ways to Answer "Who Are You" on the Web

Every system that lets a stranger read or write your data has to answer the same question first: who are you, and how do I check it without asking a company to vouch for you? The Solid ecosystem answers with a WebID, an identifier that lives at a web address. Solidus answers with did:solidus, an identifier anchored on a chain. Both are real, working answers to the same question. Neither one is simply better. This page states the difference plainly, credits the side that has actually been proven in production, and leaves open the one question nobody, including Solidus, has answered yet.

① A WebID answers "who is this" by pointing to one document at one HTTP address. ② A DID answers the same question by pointing to a record anchored across a distributed network instead of one server. ③ Both are ways of answering the same identity question, drawn at equal size here on purpose.

WebID: an identity that lives at an address

A WebID is a web address that, when you fetch it, returns a document describing you, your name, your Pod's location, the cryptographic keys or certificates that belong to you. Something like https://alice.example/profile#me. Historically, proving you were the person named in that document meant proving you held the private key matching a TLS client certificate listed inside it, a method called WebID-TLS; Solid's current stack pairs the same identifier with Solid-OIDC sign-in instead.

WebID predates Solid. It came out of W3C Semantic Web and FOAF ("Friend of a Friend") community work in the early 2010s, and Solid adopted it as the natural identity layer for a system already built on Linked Data: it did not invent it. The design is deliberately simple: a WebID needs nothing but ordinary web infrastructure, a URL, a server, a document, and it is self-describing enough that anyone can open it in a browser and read it. That simplicity is not a footnote. It is the reason WebID has been operated at institutional scale for years, in deployments Solidus had no part in: the BBC, the NHS in England, and the Flemish regional government have all run real Solid systems identified this way.

did:solidus: an identity anchored on a chain

A did:solidus identifier is built from a public key, not a server location:

Ed25519 public key (32 bytes)
    → BLAKE3 hash
    → first 20 bytes
    → Base58-encode
    → did:solidus:<result>

The same key always produces the same DID. Creating one submits a transaction to the Solidus chain; the resulting DID Document lives in chain state and is resolvable by anyone who queries the network, rather than by fetching a document from the identity owner's own server. did:solidus is registered in the W3C DID Method Registry, pull request #713 to w3c/did-extensions, merged 2026-07-04. That is a real, checkable fact about a registry listing. It is not a W3C standard, not a W3C endorsement, and it says nothing about whether the method is a good design: the actual standard underneath it, DID Core, is W3C's work, not ours.

Anyone can check the registration directly: curl -s https://api.github.com/repos/w3c/did-extensions/pulls/713 | jq '{state,merged,merged_at}' returns merged: true, 2026-07-04. No account needed.

The tradeoff, stated as a tradeoff

Put side by side, the difference is where the "who are you" record lives and who has to keep it available. A WebID resolves as long as its owner's server is up, and its rules, who may access a given document, are enforced by WAC/ACL rules sitting next to the resource. A did:solidus DID resolves as long as the network behind it does, and revocation or key rotation is a chain transaction rather than a document edit or a certificate expiring, once finalized, every resolver in the network gives the same answer.

Neither of those properties is free, and neither side of this comparison gets to claim it without the cost that comes attached. WebID's cost has already been paid and is well understood: it requires the owner (or their provider) to keep a server running, and its rules depend on that server continuing to enforce them honestly. WebID has years of real institutional deployment behind it. That is the honest scoreboard, and it does not favor us.

The open question, left open

Here is the question this page will not answer, because we genuinely do not know the answer: would a Solid pod resource's WAC/ACL rule accept a did:solidus-issued credential as its subject, in place of a WebID, and what would actually break if it tried? Candidates worth naming without resolving: WebID's dereferencing assumptions (a WAC rule expects to fetch a document at the subject's address; a did:solidus subject has no such address to fetch), ACL inheritance across a Pod's container hierarchy, and whatever a Solid app does when identity resolution requires a network call instead of an HTTP fetch. We have not tried this against a real Solid pod, and a confident-sounding answer invented for this page would be worse than admitting we don't have one. If you run Solid infrastructure and have an informed guess, that disagreement is the useful part of reading this page.

Where this leaves Solidus

Solid solved personal data storage and access control, WebID, LDP, WAC/ACL, RDF, and proved it in institutions that do not tolerate research-grade software. Solidus did not build any part of that, and our own Pod product says so plainly: it is Solid-compatible, not Solid-conformant, Community Solid Server with a did:solidus bridge, not a from-scratch reimplementation. The identity question this page compares is the one place we genuinely diverge from Solid's design rather than merely not-yet-conforming to it, and it's covered at a higher level of scrutiny, what conformance would actually require, what's still unchecked, on Solid Compatibility.

Check both sides yourself

WebID: dereference the profile URL of any public Solid pod, an Inrupt-hosted one works, and you get back an RDF document, typically in Turtle, describing its owner. That's not our proof to give; we don't implement WebID. It's checkable by anyone in under a minute.

did:solidus: run the registry check above, then resolve a live DID against rpc.solidus.network. That is the honest scope of what either side of this page's proof actually demonstrates.

Related concepts: Pairwise DID, a related but separate bet, about correlation resistance rather than availability, for readers who want the fuller identity picture before deciding which tradeoffs matter to them.