Decentralized Identifier (DID)

The defining architectural property of a DID is the elimination of a central registration authority. Unlike traditional identifiers (email addresses, domain names) that depend on a single organization like ICANN or a corporate directory, DIDs are generated and controlled by the identity owner.

• No Central Authority: The DID subject retains ultimate control over their identifier without requiring permission from an intermediary.
• Distributed Ledger Anchoring: DIDs are typically recorded on a Verifiable Data Registry (VDR), such as a blockchain or distributed ledger, ensuring censorship-resistant persistence.
• Infrastructure Independence: The identifier is not tied to any specific service provider, preventing vendor lock-in and enabling portability across different systems and networks.

Every DID resolves to a DID Document containing cryptographic public keys and service endpoints. This mechanism allows any party to verify the identity of the DID controller without contacting a centralized authority.

• Public Key Infrastructure: The DID Document lists verification methods, enabling challengers to authenticate digital signatures and establish encrypted communication channels.
• Key Rotation: Controllers can update their cryptographic keys in the DID Document without changing the underlying identifier, maintaining a persistent identity while mitigating key compromise.
• Proof of Control: Possession of the associated private key is the sole requirement to prove ownership, enabling passwordless authentication flows for autonomous agents.

DIDs are designed to be permanent, long-lived identifiers that survive the lifecycle of any single hosting provider, cryptographic key, or network. This durability is critical for agents that must maintain identity across extended operational timeframes.

• Immutable Identifier: Once created, the DID string itself does not change, even if the underlying keys or service endpoints are updated.
• Cross-Network Resolution: A DID can be resolved across different networks or ledgers, allowing an agent to migrate its identity infrastructure without losing its established reputation or trust relationships.
• No Expiration: Unlike X.509 certificates, DIDs do not have an inherent expiration date, making them suitable for long-lived autonomous processes and archived data provenance.

DIDs are the core technical primitive enabling Self-Sovereign Identity (SSI), a model where individuals and organizations hold their own identity credentials. This shifts the power dynamic from centralized issuers to the identity holder.

• Holder-Centric Architecture: The DID subject acts as the root of trust for their own identity, choosing which credentials to disclose and to whom.
• Verifiable Credential Compatibility: DIDs serve as the issuer and subject identifiers within W3C Verifiable Credentials, enabling privacy-preserving data minimization through selective disclosure.
• Pairwise Pseudonymity: Agents can generate unique, unlinkable DIDs for each relationship, preventing correlation across different interaction contexts and enhancing operational privacy.

DIDs are governed by the W3C Decentralized Identifiers specification, ensuring broad interoperability across different vendors, ledgers, and software stacks. This standardization is essential for heterogeneous multi-agent systems.

• Universal Resolver: A standard mechanism exists to resolve any DID across any supported ledger through a unified interface, abstracting away the complexity of individual blockchain protocols.
• DID Methods: The specification defines a pluggable architecture where specific DID methods (e.g., did:web, did:key, did:ethr) define the rules for creation, resolution, and update on a particular VDR.
• Protocol Agnosticism: DIDs are not tied to a single transport protocol, allowing them to be used in HTTP-based APIs, asynchronous messaging systems like DIDComm, and offline peer-to-peer exchanges.

DIDs provide the identity layer for DIDComm, a secure, private communication protocol purpose-built for agent-to-agent messaging. This enables encrypted, authenticated data exchange without relying on centralized message brokers.

• Authenticated Encryption: Messages are encrypted using the public keys published in the recipient's DID Document, ensuring end-to-end confidentiality and sender authentication.
• Transport Independence: DIDComm messages can be routed over any transport (HTTP, Bluetooth, NFC, message queues), with the encryption layer remaining consistent regardless of the underlying channel.
• Forward Secrecy: The protocol supports ephemeral key exchange to ensure that the compromise of a long-term DID key does not decrypt previously intercepted messages, a critical property for sensitive agent negotiations.