Decentralized Identifier (DID)

DIDs are created and managed without reliance on a centralized registry, identity provider, or certificate authority. Instead, they are anchored on distributed ledger technology (DLT) or other decentralized networks. This eliminates single points of failure and gives the DID subject (the entity identified) exclusive control over their identifier. No third party can revoke, freeze, or take down a DID without the controller's cryptographic keys.

Every DID resolves to a DID document—a JSON-LD file containing the public keys, authentication protocols, and service endpoints associated with the identifier. This cryptographic binding allows any other agent to verify:

• Ownership: The controller possesses the associated private key.
• Integrity: The DID document hasn't been tampered with.
• Authentication: The subject can prove its identity via digital signatures. This is the mechanism that enables trust without a trusted third party.

DIDs are designed to be persistent—once created, they are permanent records on their underlying network. Crucially, they are also portable across service providers. An agent's DID does not change if it migrates from one platform to another. This contrasts sharply with platform-bound identifiers like email addresses or OAuth-based logins, which are tied to a specific provider's domain and can be revoked at any time.

The DID subject—whether a human, organization, or autonomous agent—holds the cryptographic keys that control the identifier. This principle of self-sovereign identity (SSI) means:

• The subject decides what information to share.
• The subject can rotate keys to maintain security.
• The subject can update service endpoints without permission. For autonomous agents, this enables persistent, self-owned identity across their entire operational lifecycle, independent of any deployment platform.

DIDs are governed by the W3C Decentralized Identifiers v1.0 specification, ensuring broad interoperability across different networks, ledgers, and implementations. The standard defines a generic syntax (did:method:method-specific-id) and data model. This allows agents on different platforms—Ethereum, ION, or a private ledger—to resolve and verify each other's identities using a universal resolver, preventing vendor lock-in and enabling cross-ecosystem trust.

A DID is a URI string with three components separated by colons:

• Scheme: Always did.
• Method: Identifies the specific DID method (e.g., ethr, ion, web, key).
• Method-Specific Identifier: A unique string within that method's namespace. Example: did:ethr:0xE6Fe...a3f4 uses the Ethereum network. The method defines how the DID is created, resolved, and managed on a specific underlying system, allowing the ecosystem to support diverse trust models.

A JSON-LD document associated with a DID that contains the cryptographic material, verification methods, and service endpoints necessary for an agent to authenticate and interact securely. This document is stored on a Verifiable Data Registry such as a blockchain or distributed ledger.

• Contains public keys for signature verification
• Lists service endpoints for agent communication
• Supports key rotation without changing the DID
• Enables delegated authority through capability invocation

A specification that defines how a specific type of DID and its associated DID document are created, resolved, updated, and deactivated on a particular Verifiable Data Registry. Examples include did:web for domain-based identities and did:ethr for Ethereum-based DIDs.

• did:key: Self-contained, no registry required
• did:web: Resolves via HTTPS from a web domain
• did:indy: Hyperledger Indy for privacy-preserving credentials
• did:ion: Sidetree-based, anchored to Bitcoin

The process of taking a DID as input and returning the associated DID Document containing the agent's public keys and service endpoints. This is the fundamental operation that enables any party to establish a cryptographically secure communication channel with an agent.

• Performed by a DID Resolver implementation
• Returns DID Resolution Metadata including proof of validity
• Critical for real-time trust establishment between agents
• Must handle deactivated DIDs gracefully

A decentralized identity paradigm where an agent or entity has sole ownership and control over its digital identifiers and credentials without reliance on any centralized authority. DIDs are the foundational building block of SSI architectures.

• Portability: Identity moves across systems without permission
• Persistence: Identity survives organizational changes
• Privacy: Minimal disclosure through selective revelation
• Control: The identity owner decides what to share and when

A public key infrastructure where the root of trust is distributed across a blockchain or distributed ledger rather than centralized certificate authorities. DIDs serve as the identifiers in a DPKI, enabling agents to self-certify their public keys.

• Eliminates single points of failure in traditional PKI
• Enables key rotation and revocation without CA involvement
• Supports cross-domain trust without federation agreements
• Uses Merkle trees for efficient key state verification