A DID document and a WebID profile document aren't the same shape
Both name a person and list their keys.
The WebID side is Solid's design and Solid's implementation (we did not build any of it) and the difference described below is a bet we are making, not a result we have proven.
A WebID profile, in one paragraph
An RDF document you host at an HTTPS URL. Fetch the URL, get the document, read what it says about the person, typically a name, a public key or two, and, importantly, a pointer to where their storage lives.
Its authority comes from the domain. Whoever controls the domain and the certificate controls what the document says. That is simple, uses infrastructure that already exists, and works today.
And it is extensible in a way ours is not: it is RDF, so you can say anything about yourself in any vocabulary. A profile is an open-ended description.
A DID document, from the live network
Ours is not a document anybody hosts: it is a record the chain produces. Resolve a real identifier and you get, verbatim in shape:
id · controller · verification_method (exactly one)
authentication · assertion_method · key_agreement
capability_invocation · capability_delegation
service: []
active · created_ms · updated_ms · version_id
recovery_nonce · recovery_policy
The same call on an invented identifier returns null, so that is a real record, not
a template handed back to anyone who asks.
What the shapes tell you about the different jobs
The DID document is mostly about key purposes. Five separate relationships say what each key may be used for: proving control, signing assertions, agreeing encryption, invoking and delegating capabilities. A WebID profile has no equivalent vocabulary that a verifier is obliged to respect.
And it carries state a hosted file cannot: a version identifier, created and updated timestamps, an active flag, and a recovery policy. So a verifier can detect that the document changed, and when, without having cached the previous copy.
The WebID profile carries something ours does not: openness. Any statement, any vocabulary, no schema to negotiate. Ours is a fixed set of fields decided by the method specification.
And the part that goes against us
Our service array is empty.
That field is where a DID document says "and here is where to reach me", a storage location, an endpoint, a service. A WebID profile's pointer to your storage is one of the main reasons it exists, and on the live record we resolved, ours points at nothing.
So on the specific job of "find this person's pod", the WebID profile does it and our DID document does not. The field is defined; it is simply not populated for the identifier we checked. We are naming that rather than describing the two as equivalent.
The bet, stated as a bet
A WebID depends on a domain and a certificate authority. If the domain lapses, is transferred, or is seized, the identifier is gone and everything that pointed at it dangles.
A chain-anchored identifier depends on the chain. Revocation and key rotation are enforced by consensus rather than by whoever holds the domain.
The honest trade, with our own numbers: our chain is four validators, all operated by us, one node operator. On "how many independent parties must fail before this breaks", the WebID answer is better than ours today. We think the bet is worth making. We would rather argue about it than assert it, and the longer version is here.
Which to use
- Building on Solid, today, with existing tooling? The WebID profile. It is what the ecosystem expects, it works, and nothing about our identifier is required.
- Need typed key purposes, versioning, or revocation not controlled by a domain owner? That is
what a DID document offers, with the operator caveat above, and with the empty
servicearray as a live limitation. - Both? They are not mutually exclusive. A profile can reference an identifier and an identifier can, in principle, point at a profile, though ours currently points at nothing.