Dereferencing a WebID vs resolving a DID: two ways to look someone up
Both answer "who is this identifier, and what keys do they hold." One is an HTTP request.
The WebID side is Solid's work, not ours (we have built nothing for it) and the difference below is a bet we are making, not a result we have proven.
Dereferencing a WebID
You do an HTTP GET on the identifier. That is the entire mechanism. The WebID is a URL, so looking it up is exactly what a browser already does with any address.
$ curl -H 'Accept: text/turtle' https://example.org/profile/card
What secures it is TLS and whoever controls the domain. If the certificate validates and the document says you hold a key, you hold a key.
And this is the half that goes against us, so it goes here rather than at the bottom: it needs no special tooling whatsoever. Any HTTP client, in any language, written before Solid existed, can dereference a WebID. That is a real and durable advantage, and no amount of engineering on our side takes it away.
Resolving a DID
A DID is not an address, so you cannot fetch it. Resolution is a method-specific process: a client reads the method name, applies that method's rules, and produces a document.
For ours, that means asking the chain:
$ curl -s -X POST https://rpc.solidus.network -H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","method":"solidus_didResolve","params":["<did>"],"id":1}'
No credentials, no account. An invented identifier returns null, so a successful
response is a real record rather than a template handed to anyone who asks.
What secures it is chain consensus rather than a domain and a certificate authority.
The differences that actually matter
| WebID | did:solidus | |
|---|---|---|
| Mechanism | an HTTP GET | a method-specific call |
| Tooling needed | none, any HTTP client | a client that speaks this method |
| Root of trust | domain + certificate authority | chain consensus |
| Who can change the record | whoever controls the domain | whoever holds the key, per the chain's rules |
| Detecting a change | you must have kept the old copy | a version identifier and timestamps come with it |
| If the domain lapses | the identifier is gone | unaffected |
| If the network stops | unaffected | resolution stops |
Neither column is the better one. They fail in different places, and which failure you can tolerate is the actual question.
Our honest position on that trade
Our chain is four validators, all operated by us, one node operator. So on "how many independent parties must fail before this breaks", the WebID answer is better than ours today. A domain and a certificate authority are two well-understood parties with decades of operational history; ours is one company.
What we get in exchange is that a domain owner cannot silently rewrite the record, and that a verifier can tell when it last changed without having cached it. We think that trade is worth making. We would rather argue about it than assert it, the longer version.
The practical catch, which has its own page
Generic DID tooling does not resolve our method yet. A client has to speak did:solidus
specifically, and the widely-used generic resolver does not. That is a real portability limitation
and it deserves its own honest page, here.
Dereferencing a WebID has no equivalent problem, because there is nothing to support.
What neither of them settles
Looking someone up tells you which keys are current. It tells you nothing about whether the person is who they claim, or whether any statement about them is true. That is the credential layer, and who is allowed to read what is different again.