Decentralized Identifiers (DIDs)

What is a DID?

A Decentralized Identifier (DID) is a globally unique identifier, specifically a URI, that an entity controls without needing a central authority to issue, register, or maintain it. DIDs are a W3C standard. Their format is did:method:identifier (for example, did:web:example.com or did:key:z6Mk...). Each DID resolves to a DID Document, which is a structured record containing the public keys, authentication methods, and service endpoints needed to interact with that identity.

The critical property here is that the entity controlling the DID holds the private key. No identity provider, registrar, or platform can revoke, reassign, or surveil that identifier without the controller's participation.

Quick Summary

The two parts of a DID: identifier and document

A DID isn't just a string. It has two inseparable components that together create a verifiable identity.

The DID (the URI) The identifier itself follows the pattern did:method:method-specific-id. The method specifies which system governs resolution, whether that's a blockchain, a distributed ledger, a web server, or a cryptographic derivation. The method-specific ID is the unique address within that system.

• did:web:identity.example.com
• did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK
• did:ion:EiClkZMDxPKqC9c-umQfTkR8vvZ9jphl_xLDI9Nfk38w5w

The DID Document When a DID is resolved through a DID resolver, it returns a DID Document, which is a JSON-LD file containing:

• Verification methods: the public keys associated with this identity
• Authentication: which keys can prove control of the DID
• Assertion methods: which keys can sign verifiable credentials
• Service endpoints: URLs for interacting with the identity (messaging, credential exchange)

The DID Document is public. The private key that corresponds to the public key in the document is held exclusively by the controller. Authentication is a challenge-response: a verifier presents a challenge, the controller signs it with their private key, and the verifier confirms using the public key in the DID Document. No password. No central lookup. No intermediary.

The trust triangle: how DIDs work in practice

DIDs rarely operate alone. In most deployments, they're the identity layer beneath Verifiable Credentials (VCs), which are the W3C standard for tamper-evident digital claims.

The ecosystem has three roles:

• Issuer: creates and signs a credential about a subject. A university issues a degree. A government issues a digital driver's license. An employer issues an employment attestation. The issuer signs the credential with their DID's private key.
• Holder: the individual or entity that receives and stores the credential, typically in a digital identity wallet. The holder presents credentials to verifiers and controls what is shared, with whom, and when.
• Verifier: receives a credential presentation and cryptographically verifies it. Was it signed by the claimed issuer? Has it been tampered with? Is it still valid? Verification requires no contact with the issuer, since it uses the issuer's public key from their DID Document.

This model enables selective disclosure. A holder can prove they're over 18 without revealing their date of birth, prove they hold a professional certification without revealing which employer issued it, or prove citizenship without revealing a passport number. The cryptographic mechanism (zero-knowledge proofs in some implementations) makes the disclosure both verifiable and minimal.

DID methods: not all DIDs are created equal

The DID specification is method-agnostic. The choice of method determines how a DID is registered, resolved, and governed, and it dramatically affects enterprise practicality.

For enterprise IAM teams evaluating DIDs, did:web is the most accessible entry point. It requires no blockchain infrastructure, resolves over standard HTTPS, and can be deployed alongside existing identity systems. did:key is well-suited for non-human identities like short-lived workload certificates, device attestation, and AI agent identities, where an ephemeral, self-contained identifier is preferable to a registered one.

Where DIDs genuinely work today

DIDs aren't a replacement for enterprise IAM in most organizations. They're a complementary layer that solves specific problems where centralized identity creates friction or risk.

Regulated document exchange. Universities, governments, and professional bodies issuing digital credentials like diplomas, licenses, and certifications that travel across institutional boundaries. The receiver needs to verify authenticity without contacting the issuer directly. DIDs plus Verifiable Credentials solve this cleanly.

Cross-border identity verification. KYC credentials issued by a verified identity provider in one jurisdiction, portable and verifiable in another, without requiring the second jurisdiction to trust the first's systems directly. The EU's EBSI (European Blockchain Services Infrastructure) and several national digital identity programs are building on this model.

Non-human and workload identity. did:key and similar self-contained methods are well-suited for short-lived device or container identities that need a cryptographic identifier without central registration. A container can generate a DID at startup, use it to authenticate to services during its lifecycle, and discard it on shutdown.

Privacy-preserving authentication. Web3 and decentralized applications where users want to authenticate without revealing their identity to the service, or where cross-platform tracking is a concern.

DIDs vs. federated identity: the question enterprise architects actually ask

The relevant comparison for an enterprise IAM audience isn't DIDs vs. passwords. It's DIDs vs. the federated identity systems already in place.

DIDs and federated identity (SAML, OIDC, Entra ID, Okta) solve related but different problems. Understanding the distinction prevents both overhype and dismissal.

The honest summary: federated identity is more mature, more widely deployed, and better integrated with enterprise tooling today. DIDs offer stronger privacy, portability, and resilience against central-provider failure, but they impose real key management burden and have limited enterprise tooling maturity. Most organizations will run both for the foreseeable future, with DIDs handling credential portability and regulated document exchange while federated identity handles workforce authentication.

The governance reality: DIDs require lifecycle management too

DIDs are sometimes presented as a governance-free model, where no central authority means no administration overhead. That's misleading in enterprise practice.

DIDs still require governance. The key questions an identity governance platform has to answer are:

• Which DIDs has our organization issued or accepted? An untracked DID issued to a former employee or a decommissioned device represents the same residual risk as an unrevoked account.
• Are the verification methods in DID Documents still current? Public keys rotate. Service endpoints change. An outdated DID Document is a stale identity claim.
• Who issued the credentials a DID is presenting? The cryptographic verification confirms the credential hasn't been tampered with, but it doesn't establish whether the issuer is trustworthy. Trust registries and governance frameworks (like those in EBSI or the EU Digital Identity Wallet) address this, but they require active maintenance.
• How are organizational DIDs revoked when a relationship ends? DID revocation is method-specific and not universally straightforward. Governance processes need to account for it.

Industry use cases

Higher education. A university consortium adopts DIDs and Verifiable Credentials for academic transcripts. Each institution is an issuer with its own did:web identifier. Graduates hold their credentials in a digital wallet and present them to employers or graduate programs. The verifier confirms the credential cryptographically, with no phone call to the registrar, no third-party verification service, and no central database to query or breach.

Healthcare credentialing. A hospital network issues DID-based credentials for clinical staff, including licenses, board certifications, and training records. The credentials travel with the clinician across affiliated institutions and are verified independently by each one. The hospital's identity governance platform manages the issuance workflow, revocation on departure, and audit trail for regulatory compliance.

Supply chain identity. A manufacturer issues DIDs to supplier organizations and uses Verifiable Credentials to attest compliance certifications, audit results, and material provenance. Each node in the supply chain can verify upstream claims without contacting the original certifier, which reduces friction and eliminates the central registry that currently holds all supplier compliance data.

Frequently Asked Questions

What does "DID" stand for, and what is its full form?

DID stands for Decentralized Identifier. It's a W3C standard URI scheme for self-sovereign digital identity, meaning an identifier that an entity controls without depending on a central authority.

What is the difference between a DID and a Verifiable Credential?

A DID is an identifier, the "who." A Verifiable Credential (VC) is a signed claim about that identity, the "what." A university has a DID (its identity). A degree it issues to a student is a Verifiable Credential (a signed claim that the student earned a specific qualification). DIDs are the identity layer, and VCs are the attestation layer built on top of it.

Do DIDs require a blockchain?

No. Some DID methods use blockchains for persistence and tamper-evidence (for example, did:ion and did:ethr). Others use standard web infrastructure (did:web) or require no registry at all (did:key). Blockchain is one resolution mechanism; it isn't required by the W3C DID specification.

Are DIDs ready for enterprise IAM today?

Partially. DIDs are production-ready for specific use cases like credential portability, regulated document exchange, cross-border identity verification, and non-human workload identity. They aren't yet a practical replacement for enterprise federated identity (Entra ID, Okta, SAML/OIDC) for workforce authentication. Most enterprise DID adoption today runs alongside existing IAM infrastructure rather than replacing it.

What happens if a DID controller loses their private key?

Recovery depends on the DID method and any recovery mechanisms configured at enrollment. Some methods support recovery keys or multi-signature controllers. Others have no recovery path, meaning loss of the private key means loss of the DID. This is the most significant UX and operational challenge for broad DID adoption, particularly for non-technical users. Enterprise deployments typically use hardware-backed key storage and organizational recovery policies to mitigate this risk.

Related Terms

• Verified Credentials

• Self-Sovereign Identity (SSI)

• Cryptographic Identity Binding

• Digital Identity Wallet

• Non-Human Identity (NHI)

• Zero Trust Architecture

• Cross-Border Identity Compliance

• Federated Identity