What Is a Decentralized Identifier (DID)?
The unlinkability implementation described here is unaudited.
A Decentralized Identifier (a DID) is an identifier you generate and control yourself, backed by a keypair only you hold. Nobody issues it to you. There's no company, registrar, or platform that hands it out and can later revoke it, the way an email address or a username on someone else's service can be. You create the keypair, and the DID falls out of it.
That's the plain definition. Here's the fact that matters most on this page, stated precisely: did:solidus (the specific DID method Solidus wrote) is registered in the W3C DID Method Registry. Not "a W3C standard." Not "W3C-approved." A registry listing. You can check it yourself, right now, with no account and no API key:
curl -s https://api.github.com/repos/w3c/did-extensions/pulls/713 | jq '{state,merged,merged_at}'
That returns merged: true, dated 2026-07-04, the pull request that registered did:solidus against w3c/did-extensions. It's a narrow, checkable fact: the method, the rules for how a did:solidus identifier is formed, resolved, and updated, is listed in the registry maintained alongside the DID Core specification. That is not the same as every individual DID being "on a standard," and it's not an endorsement of Solidus generally. DID Core itself (the actual W3C Recommendation that makes any of this possible) was written by the W3C DID Working Group; Solidus didn't author it, only implemented against it.
What makes it "decentralized"
Compare a DID to a username. A username lives in someone else's database. The platform assigns it, the platform can suspend it, and if the platform shuts down, the identifier goes with it. A DID inverts that. The identifier is derived from a public key you (or your wallet software) generate locally. Proving you control it means signing a challenge with the matching private key, no company in the loop, no account-recovery flow that routes through a support desk, no central directory that can deny you exist.
"Decentralized" here describes the identifier, not necessarily a blockchain underneath it, DID Core supports many methods, some backed by ledgers, some by peer-to-peer exchange, some by plain web hosting. did:solidus happens to anchor its identifiers on the Solidus chain, but the defining property of any DID is the same regardless of method: control follows the keys, not a registrar.
What did:solidus specifically is
A DID method is the concrete rulebook for one namespace under the did: scheme, how an identifier in that method is minted, how it's resolved back to useful data, and how it's updated.
Every did:solidus identifier resolves today against the live rpc.solidus.network endpoint, a plain read against the chain's state tree, no transaction or fee involved. This page won't walk through the actual resolution call; 006 — Resolve a DID does that with a real, runnable example. What's worth knowing here is the shape of the answer: resolving a DID gets you back a DID Document, the record listing the public keys and capabilities attached to that identifier. 008 — What's in a DID Document covers what's actually inside one.
One DID, though, is rarely what you want to present. A single global identifier shown to every verifier lets those verifiers compare notes and link your activity across contexts: the opposite of what a private credential system should do. Solidus derives a separate, unlinkable identifier per relying party instead; see 001 — Pairwise DIDs for how that works and why it's the identifier you actually present, not the root DID itself. The BBS+ implementation referenced here is unaudited.
What it is not, yet
"You control the keys, nobody can take this identifier from you" is true of the cryptography; it isn't yet a claim about production permanence, because the network it's anchored on isn't production.
Where to go next
For the canonical, spec-level definition (the W3C DID Core data model itself, independent of any one implementation) see the Lexicon's DID entry, along with DID Document, DID Resolution, and did:solidus for the method-specific detail. This page is the concept; those entries are the reference; 006 and 008 are the hands-on follow-through.