The average internet user maintains credentials with 240 online services. Each service holds a fragment of their identity in a proprietary database, subject to that company’s security practices, data retention policies, and business incentives. The W3C Decentralized Identifiers specification, which reached formal Recommendation status in July 2022, proposes a fundamentally different model: identifiers that no organization controls, that no database centrally stores, and that the subject creates and manages without permission from any authority.
DIDs are not a product. They are infrastructure. They sit beneath ENS domains, beneath Sign-In With Ethereum, beneath verifiable credential ecosystems, providing the foundational addressing scheme for decentralized identity. Understanding DIDs is prerequisite to understanding everything being built on top of them.
The DID Syntax
A Decentralized Identifier follows a precise URI format defined in the W3C specification:
did:method:method-specific-identifier
For example:
did:ethr:0x1234567890abcdef1234567890abcdef12345678did:web:stealthcloud.aidid:key:z6MkpTHR8VNs6k1k7eFHvWRX3R2QZm1ZKtkWSWXv1j7Vwdid:ion:EiAnKD8-jfdd0MDcZUjAbRgaThBrMxPTFOxcnfJhI7Ukaw
Three components, always in this order. The scheme (did) identifies this as a decentralized identifier. The method (ethr, web, key, ion) specifies which DID method is used, which determines how the identifier is created, resolved, updated, and deactivated. The method-specific identifier is a unique string within the method’s namespace.
The specification is deliberately minimal. A DID is an address. What lives at that address is defined by the DID Document.
DID Documents
Every DID resolves to a DID Document, a JSON-LD structure that describes the subject’s cryptographic capabilities, service endpoints, and authentication methods. A minimal DID Document looks like this:
{
"@context": "https://www.w3.org/ns/did/v1",
"id": "did:example:123456789abcdefghi",
"authentication": [{
"id": "did:example:123456789abcdefghi#keys-1",
"type": "Ed25519VerificationKey2020",
"controller": "did:example:123456789abcdefghi",
"publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
}],
"service": [{
"id": "did:example:123456789abcdefghi#messaging",
"type": "MessagingService",
"serviceEndpoint": "https://example.com/messages"
}]
}
The DID Document contains no personal data. It contains only cryptographic material (public keys, verification methods) and service endpoints. It answers the question: “How do I interact with the entity identified by this DID?” It does not answer: “Who is this entity?” This distinction is architecturally significant for privacy.
Key Sections of a DID Document
Authentication: Lists the verification methods (public keys) that can be used to prove the DID subject is communicating. When you sign in with Ethereum, you are using the authentication verification method associated with your did:ethr DID.
Assertion Method: Lists keys authorized to issue verifiable credentials or make claims on behalf of the DID subject.
Key Agreement: Lists keys for establishing encrypted communication channels. This enables end-to-end encrypted messaging between DIDs without a centralized key exchange server.
Service Endpoints: URLs or other addresses where services related to the DID can be accessed. A DID Document might list a messaging endpoint, a credential storage endpoint, or a privacy-preserving API gateway.
Controller: Specifies which DID(s) have authority to modify the DID Document. A DID can be self-controlled (the subject controls their own document) or externally controlled (an organization manages it). Self-controlled DIDs are essential for self-sovereign identity.
DID Methods: The Implementation Layer
The DID specification defines the syntax and structure. DID methods define the implementation. Each method specifies how to create, resolve, update, and deactivate DIDs using a particular underlying technology. Over 150 DID methods have been registered in the W3C DID Method Registry. The significant ones fall into four categories.
Blockchain-Anchored Methods
did:ethr resolves Ethereum addresses as DIDs. Every Ethereum address is implicitly a DID. The DID Document is constructed from on-chain state (the address’s associated public key) and an optional ERC-1056 identity registry for additional attributes. Resolution is trustless: anyone can verify a did:ethr DID Document by querying the Ethereum blockchain.
did:ion uses Microsoft’s ION network, a Layer 2 system anchored to Bitcoin. ION stores DID operations in a Sidetree protocol that batches hundreds of DID operations into a single Bitcoin transaction. This amortizes costs and provides Bitcoin-level security guarantees. As of 2025, ION anchors approximately 180,000 active DIDs.
did:sol is the Solana equivalent of did:ethr, leveraging Solana’s high throughput and low fees for DID operations.
Peer and Static Methods
did:key generates a DID directly from a public key. No blockchain, no registration, no network call. A did:key DID is entirely self-contained: the public key is encoded in the identifier itself. Resolution is instantaneous and requires zero infrastructure. The tradeoff is that did:key DIDs cannot be updated or rotated, they are immutable.
did:peer enables two parties to create DIDs for private, pairwise communication. No public registry is involved. The DIDs are exchanged directly between parties and are meaningless to anyone else. This is the closest DID method to zero-knowledge interaction: the identifiers exist only in the context of a specific relationship.
Web-Based Methods
did:web resolves a DID by fetching a DID Document from a well-known URL. did:web:stealthcloud.ai resolves to https://stealthcloud.ai/.well-known/did.json. This is the pragmatist’s DID method: it leverages existing web infrastructure, requires no blockchain, and is easy to implement. The tradeoff is that it reintroduces DNS dependency, which means ICANN and domain registrars are back in the trust chain.
Ledger-Based Methods
did:indy runs on Hyperledger Indy, a purpose-built identity ledger used primarily in enterprise and government identity systems. The Sovrin Network, built on Indy, has been used for government-issued verifiable credentials in several countries.
Verifiable Credentials: The Proof Layer
DIDs are addresses. Verifiable Credentials (VCs) are the claims attached to those addresses. The W3C Verifiable Credentials Data Model, which reached Recommendation status alongside the DID specification, defines a standard format for tamper-evident digital credentials.
A verifiable credential contains three elements:
- Issuer: The DID of the entity making the claim (e.g., a university, employer, or government agency)
- Subject: The DID of the entity the claim is about (e.g., a graduate, employee, or citizen)
- Claim: The assertion being made (e.g., “holds a degree in computer science,” “is over 18,” “passed KYC verification”)
The credential is cryptographically signed by the issuer. Anyone can verify the signature by resolving the issuer’s DID Document and checking the associated public key. The verification requires no contact with the issuer. This is the critical privacy property: a credential issued once can be verified infinitely without the issuer learning when, where, or by whom it was verified.
Zero-Knowledge Credentials
The most powerful application of verifiable credentials for privacy is selective disclosure using zero-knowledge proofs. Instead of presenting a full credential (“I am Alice, born on 1990-01-15, resident of Zurich, holder of Swiss passport number X12345”), the holder can generate a ZK proof that demonstrates a specific property without revealing the underlying data (“I am over 18” without revealing the date of birth or any other field).
This is the technology that makes zero-KYC authentication viable. A user can prove they are a unique person, that they are over a regulatory age threshold, or that they are a resident of a specific jurisdiction, all without revealing their name, address, or government ID number. The proof is mathematically verifiable but information-theoretically reveals nothing beyond the stated claim.
The Decentralized Identity Stack
DIDs and VCs do not operate in isolation. They form layers in a comprehensive identity stack:
Layer 1 - Identifier: The DID itself. A globally unique, cryptographically verifiable address.
Layer 2 - Document: The DID Document. Describes the cryptographic capabilities and service endpoints of the identifier.
Layer 3 - Credentials: Verifiable Credentials issued by third parties, bound to the DID.
Layer 4 - Presentation: Verifiable Presentations, which package selected credentials (or ZK proofs derived from them) for a specific verifier.
Layer 5 - Application: The user-facing application that manages DIDs, stores credentials, and generates presentations. This is the identity wallet layer, exemplified by products like Spruce’s SpruceID, Microsoft’s Entra Verified ID, and conceptually by Stealth Cloud’s GhostPass.
Each layer builds on the one below it. A zero-knowledge credential presentation requires a verifiable credential, which requires a DID, which requires a DID method and underlying infrastructure. The stack is modular: you can swap out any layer without affecting the others. A credential issued to a did:ethr DID can be presented using a did:peer connection, verified against the Ethereum blockchain, and the verifier never learns the subject’s Ethereum address.
Adoption and Ecosystem
The DID ecosystem has grown substantially beyond its initial blockchain-native audience:
- The European Union’s eIDAS 2.0 regulation mandates that all EU member states provide digital identity wallets to citizens by 2026. These wallets are built on verifiable credential infrastructure that is interoperable with W3C DID standards. The EU Digital Identity Architecture Reference Framework explicitly references DIDs and VCs.
- Over 150 registered DID methods exist in the W3C registry, though fewer than 20 see significant production usage.
- Microsoft Entra Verified ID has processed over 100 million credential verifications since launch, primarily in enterprise contexts (employee onboarding, partner verification, supply chain identity).
- The Decentralized Identity Foundation (DIF) has over 300 member organizations working on interoperability, including Spruce, Microsoft, IBM, Consensys, and several Swiss identity startups aligned with the country’s digital identity initiatives.
The enterprise adoption is particularly notable because it validates the standards at scale while simultaneously creating tension with the self-sovereign principles. Enterprise identity wallets are often managed by IT departments, controlled by compliance officers, and tethered to organizational policies. They use the same DID infrastructure as fully sovereign personal wallets, but the governance model is fundamentally different.
DIDs and Privacy: Architectural Analysis
DIDs have both privacy-enhancing and privacy-reducing properties, depending on implementation choices.
Privacy-Enhancing Properties
Pairwise identifiers. A user can generate a unique DID for every relationship. Their DID with their employer is different from their DID with their bank, which is different from their DID with a privacy-focused chat application. Correlation across contexts is impossible without the subject’s cooperation.
Credential verification without issuer contact. Once a credential is issued, it can be verified purely through cryptographic operations. The issuer does not learn when the credential is presented. This breaks the “phone home” pattern of centralized credential verification.
Selective disclosure. Zero-knowledge proof protocols (BBS+ signatures, CL signatures) enable presenting derived proofs from credentials without revealing the full credential content.
Privacy-Reducing Risks
On-chain correlation. Blockchain-anchored DIDs (did:ethr, did:ion) create public records. If a DID is linked to financial transactions, the entire history is visible and permanent. This is why privacy coins and privacy chains are relevant to the DID ecosystem.
Metadata leakage during resolution. Resolving a did:web DID reveals your IP address to the hosting server. Resolving a blockchain-anchored DID reveals your query pattern to the blockchain node. Even did:peer exchanges reveal connection metadata to network observers.
Credential accumulation. A DID with many verifiable credentials becomes increasingly identifiable through the combination of attributes, even if no single credential is uniquely identifying. This is the composition attack: “over 18” + “resident of Zurich” + “holds a computer science degree” + “member of DAO X” can narrow the set to a handful of individuals.
For privacy-focused systems, the optimal DID strategy is: use did:peer or did:key for interactions, minimize on-chain identity operations, leverage zero-knowledge credential presentations, and rotate identifiers frequently. This aligns with Stealth Cloud’s zero-persistence architecture where even the identifier itself is ephemeral.
The Path Forward
The DID specification is stable, but the ecosystem is still maturing. Several developments will shape its trajectory:
DIDComm v2 standardizes encrypted, authenticated messaging between DIDs. This enables a universal messaging layer where any two DIDs can communicate securely without a centralized server, a foundational capability for privacy-preserving communication infrastructure.
Status List 2021 and its successors address credential revocation, the ability for an issuer to declare that a previously issued credential is no longer valid. Privacy-preserving revocation is hard: the naive approach (publishing a list of revoked credential IDs) reveals which credentials are being checked. Accumulator-based approaches and ZK revocation proofs are active research areas.
Trust frameworks are emerging to answer the question: “Why should I trust this issuer?” The DID specification is silent on trust. It provides verifiability (you can confirm who issued a credential) but not trustworthiness (you cannot confirm whether the issuer is legitimate). Government-backed trust frameworks, industry consortia, and reputation systems are all competing approaches.
The Stealth Cloud Perspective
DIDs provide the addressing scheme for decentralized identity, but the address is only as private as the infrastructure it connects to. Stealth Cloud builds the infrastructure layer, the zero-persistence, zero-knowledge backend, so that when a DID points to our services, it points to a system that cannot betray the user’s trust because it never possesses the user’s data.