DID: Putting Identity Back in the Individual’s Hands
Passwords and social logins alike, our identities have always been deposited on somebody else’s server. DIDs and Verifiable Credentials rethink that structure from the ground up, aiming for a world where individuals control their own identifiers and certificates.
The “triangle of trust.” The verifier can check a credential using only the issuer’s public key (DID document).
Self-sovereign identity (SSI)
Digital identity has traditionally run on two models: the centralized (siloed) model, where every service issues its own ID and password, and the federated model, “Sign in with Google/Apple”, where one platform account logs you into others. The former produced password fatigue and mass breach incidents; the latter is convenient but concentrates a record of when and where you log in with a handful of platforms, and a single account suspension can wipe out your digital life.
Self-Sovereign Identity (SSI) is the third model. By grounding identifiers and credentials not in a company’s database but in key pairs controlled by the person, plus shared infrastructure such as distributed ledgers where needed, it aims to structurally guarantee that no identity can be suspended, tracked, or correlated without its owner’s consent. Just as P2P networks decentralized where data is stored, SSI is an attempt to decentralize who issues trust and how it is verified.
DID syntax and DID documents
A DID (Decentralized Identifier) is a W3C-standard identifier with a three-part form, did:method:unique-id (for example did:web:example.com or did:key:z6Mk...). Resolving a DID yields a DID document: a JSON file listing the public key used to authenticate the subject (verificationMethod), which key is used for which purpose such as authentication (authentication), and service endpoints for reaching the subject. A DID, in short, is an address for locating public keys that nobody can confiscate.
Comparing the major DID methods
The method name that follows did: determines how an identifier is issued, updated, and revoked. Where trust actually lives (DNS, a ledger, or the key itself) differs sharply between methods, so the right choice depends on the use case.
| Method | Basis of trust | Infrastructure required | Typical use |
|---|---|---|---|
| did:key | The public key itself | None (can be generated offline) | Throwaway identifiers, device-to-device auth, ephemeral keys when issuing a VC |
| did:web | Domain ownership (DNS/HTTPS) | An existing web server | Official identifiers for companies and organizations; low adoption cost |
| did:ethr | A smart contract on Ethereum | An Ethereum node and gas fees | Web3 wallet integration; on-chain key rotation and revocation |
| did:ion | Bitcoin (the Sidetree protocol) | A Bitcoin node plus an ION runtime | Microsoft-led; layer-2-style processing for large volumes of DIDs |
How verifiable credentials work: issuer, holder, verifier
If a DID is an address, a Verifiable Credential (VC) is a digitally signed certificate. The VC ecosystem has three roles: an issuer signs and issues a document attesting to attributes; a holder keeps it in their own wallet; and when needed, presents it to a verifier. The verifier fetches the issuer’s public key from its DID document and checks the signature; no callback to the issuer required.
This separation of issuance from verification is decisive. A graduation VC signed once by a university can be verified even while the university’s servers are down, and the university never learns who presented the credential where or when.
Selective disclosure and zero-knowledge proofs
A VC is usually issued as a single certificate bundling multiple attributes, but a holder need not reveal all of them on every presentation. Formats that support selective disclosure (such as SD-JWT) let you extract and present just “nationality” from a VC that also contains name and date of birth. Go further with a zero-knowledge proof (ZKP) and you can prove a claim like “I am over 20, computed from my date of birth” without ever revealing the underlying value. Signature schemes such as BBS+, which let you disclose a subset of signed attributes while keeping the signature verifiably intact, underpin much of the tooling in this space.
Real-world rollout: the EU Digital Identity Wallet and use cases
Europe is furthest along on the regulatory front. Under the eIDAS 2.0 Regulation, which entered into force in 2024, EU member states are required to offer citizens an EU Digital Identity Wallet (EUDI Wallet), with full-scale rollout targeted for 2026. It is a national-scale SSI deployment aiming to let a driver’s license, a degree certificate, or bank-account identity verification all be handled from a single wallet app on a smartphone.
- Degrees and qualifications: universities issue diplomas as VCs that employers verify instantly during hiring. No mailing of paper certificates, no verification phone calls, and credential fraud becomes far harder.
- Reusable KYC: identity verification completed once at a bank becomes a VC presented to other financial services. Users stop re-submitting documents; businesses cut verification costs.
- Web3 login and dApp integration (see dApps): passwordless authentication by wallet signature, layered with VC-based attribute proofs (membership, DAO contribution history), enables portable reputation and membership systems independent of any platform.
Comparison with centralized identity (OAuth/OpenID Connect)
“Sign in with X” via OAuth and OpenID Connect is already ubiquitous, and DID/VC isn’t simply a better user experience. The real difference lies in the structure of availability and privacy.
| Dimension | OAuth / OpenID Connect | DID / VC |
|---|---|---|
| Who issues the identifier | A platform operator (Google, Apple, etc.) | The individual, generated and controlled by themselves |
| Communication at verification time | Requires a call to the identity provider (IdP) on every verification | No callback to the issuer; verification completes with the signature alone |
| Availability | An IdP outage or account suspension blocks authentication entirely | Already-issued VCs remain verifiable even if the issuer disappears |
| Privacy | The IdP can see when, where, and how often you log in | Selective disclosure lets you present only the minimum required attributes |
A real-world challenge: key loss and recovery
With centralized identity, a “forgot password” flow recovers your account via an email reset link. With self-sovereign identity, losing your private key means, in principle, that no one else can reissue it for you. This asymmetry is an unavoidable cost of a system where only the owner ever holds the key; in the early days of crypto wallets, permanent loss of funds from a lost private key was common.
- Social recovery: if enough of several pre-designated, trusted contacts (family, friends, institutions) approve, the key can be reissued. This applies the same idea as multisig to the identity domain.
- Multi-device key distribution: spreading keys across a phone and a hardware device or other separate devices, so losing or breaking one still leaves enough to recover.
- MPC wallets and guardian schemes: splitting the key itself into multiple shares so that the holder’s own devices and/or a trusted service provider jointly compute with it, avoiding any single point of loss.
Every one of these recovery mechanisms trades away, to some degree, the “eliminate the single point of failure” ideal at the heart of SSI, in exchange for usability. Balancing ease of key management against genuine self-sovereignty remains the biggest design challenge standing between DID/VC and mainstream adoption.