Think about what happens when you "Sign in with Google." A useful convenience, certainly — but it means Google is told, in real time, every place you log in. Your identity is a row in their table; they can disable it, and the relying site trusts you only because Google vouches for you on demand. The same shape repeats almost everywhere: identity is something a central authority grants and can withdraw.
Decentralized identifiers (DIDs) are a World Wide Web Consortium standard — DID Core reached W3C Recommendation status in 2022 — that inverts this. A DID is an identifier you generate and control with a private key, that resolves to public information without any single registration authority sitting in the middle. Paired with verifiable credentials, it sketches a model where you hold your own identity and reveal only what a given interaction actually requires.
Anatomy of a DID
A DID is just a specially formatted URI with three colon-separated parts:
did:example:123456789abcdefghi
The literal scheme did, a method (here example) that says how this identifier is created and resolved, and a method-specific identifier. Resolving a DID yields a DID Document — a small JSON object listing the public keys associated with the identifier and any service endpoints. Crucially, the DID Document contains no names, no email, no personal data: just cryptographic material you can use to verify that whoever controls the matching private key is the legitimate subject.
The "decentralized" part lives in the method. Different methods resolve DIDs against different systems:
- did:key — the identifier is a public key; no external lookup needed, fully self-contained.
- did:web — resolves to a document hosted at a domain you control, anchoring trust in DNS and TLS rather than a blockchain.
- Ledger-based methods — record DID operations on a distributed ledger so no single host can rewrite or censor them.
Verifiable Credentials: The Useful Half
A DID by itself is just a controllable identifier. What makes it powerful is the second W3C standard built on top: verifiable credentials (VCs). A verifiable credential is a tamper-evident, cryptographically signed claim — "this DID belongs to a licensed physician," "this DID is over 18," "this DID holds a degree from this university" — issued by some authority and held by the subject.
Three roles form what's often called the trust triangle:
| Role | What they do |
|---|---|
| Issuer | Signs a credential about a subject — a university, a government, an employer. |
| Holder | Stores credentials in their own wallet and decides when and to whom to present them. |
| Verifier | Checks the issuer's signature and the holder's control of the DID — without contacting the issuer. |
That last column is the privacy breakthrough. In the "Sign in with Google" model, the identity provider learns every verification. With verifiable credentials, the verifier checks the issuer's signature against the issuer's public key and confirms you control the subject DID — entirely offline with respect to the issuer. The university that granted your degree never learns which employer you showed it to.
Centralized identity quietly turns every login into a data point for the provider. Verifiable credentials break that surveillance loop: proof is verified by checking a signature, not by asking the issuer "is this person legit, right now?" The issuer can't build a log of where you go.
Selective Disclosure and Minimal Proof
The model gets sharper with selective disclosure. A credential might assert your full date of birth, but a bar only needs to know you're over 18. Cryptographic techniques — including signature schemes designed for selective disclosure, and in some systems zero-knowledge proofs — let you present a derived proof of "over 18" without revealing the birthdate itself, or anything else on the credential.
This is data minimization made structural. Instead of handing over a document and trusting the recipient not to keep the extra fields, you disclose only the single attribute the interaction requires. It's the same instinct behind privacy-preserving authentication: prove the claim, not the person.
The Honest Caveats
DIDs are promising, not finished, and several hard problems are unresolved enough that you should treat the technology with measured optimism.
Key recovery
If your identity is controlled by a private key and you lose it, you lose the identity — and there's no "forgot password" link by design. Self-sovereignty and self-custody are the same coin: the absence of a recovery authority is exactly what removes the gatekeeper, and exactly what makes loss catastrophic. Practical systems lean on social recovery or secured backups, which reintroduce trade-offs.
Revocation and correlation
Issuers need a way to revoke credentials (a fired employee's badge, a suspended license), and doing that without a phone-home call to the issuer is technically delicate. And reusing one DID everywhere recreates the very correlation problem decentralization was meant to solve — you're meant to use many DIDs, one per relationship, which adds management burden.
Adoption
A credential is only as useful as the set of verifiers who accept it. Standards exist and pilots are real — including government digital-wallet efforts — but ubiquitous, everyday acceptance is still ahead, not behind.
Where Haven Fits
Haven isn't a DID wallet, but it's built on the same principle that animates decentralized identity: your identity should be anchored in a key you control, not an account someone else owns. Haven derives your keys from a passphrase on your own device — the server never sees the secret that defines you — which is the same self-custody trade-off DIDs make, applied to encrypted messaging.
Decentralized identifiers won't replace logins next year. But they point at a future worth wanting: one where proving who you are doesn't require a corporation to watch you do it, and where the identifier in question is, finally, actually yours.