Decentralized Identifier (DID)

DIDs eliminate the need for a centralized registration authority or identity provider. Instead, they are anchored on decentralized networks such as distributed ledgers or peer-to-peer protocols. The DID subject retains ultimate control over their identifier, including the ability to rotate cryptographic keys, update service endpoints, and revoke credentials without permission from an intermediary. This architecture prevents vendor lock-in and single points of failure, ensuring that identity remains portable and censorship-resistant across different trust domains.

Every DID is intrinsically linked to a DID document containing public keys and authentication mechanisms. This enables any party to cryptographically verify:

• Ownership: The controller proves control via a digital signature challenge-response.
• Integrity: The DID document itself is tamper-evident when anchored to an immutable ledger.
• Claims: Verifiable Credentials (VCs) issued to a DID can be validated without contacting the issuer.

Common key types include Ed25519 for signatures and X25519 for key agreement, supporting protocols like DIDComm for secure peer-to-peer communication.

A DID is designed to be a persistent identifier that outlasts the underlying infrastructure. Unlike a URL tied to a specific domain or an email address controlled by a provider, a DID remains stable even if:

• The hosting organization ceases to exist.
• The cryptographic keys are rotated.
• The underlying storage network migrates.

This persistence is critical for long-term audit trails, where AI decision logs must reference a stable actor identifier for regulatory compliance and non-repudiation over decades.

The DID method (the string after the first colon in did:example:123) defines how a DID is created, read, updated, and deactivated on a specific verifiable data registry. Each method specifies its own CRUD operations and resolution protocol.

• did:web: Resolves via HTTPS to a domain-hosted DID document.
• did:key: Self-certifying; the identifier is derived directly from a public key.
• did:indy: Anchored on Hyperledger Indy ledgers for privacy-preserving credentials.

Resolution is the process of dereferencing a DID to its DID document, returning the associated cryptographic material and service endpoints.

DIDs conform to the W3C Decentralized Identifiers v1.0 specification, ensuring broad interoperability across vendors, platforms, and jurisdictions. The standard defines:

• A common data model for DID documents (JSON-LD).
• A universal resolver architecture for cross-method compatibility.
• Standardized DID URL syntax for dereferencing specific resources within a DID document.

This standardization enables an AI auditor to verify the identity of a model operator using a did:key identifier in one jurisdiction and a did:ebsi identifier in another, using the same resolution logic.

DIDs support pairwise-unique identifiers and advanced cryptographic techniques to prevent correlation. A DID subject can generate an unlimited number of distinct DIDs, using a unique one for each relationship to avoid being tracked across contexts. When combined with BBS+ signatures or Zero-Knowledge Proofs (ZKPs), a DID controller can selectively disclose only specific attributes from a Verifiable Credential without revealing the full credential or a persistent identifier. This is essential for privacy-compliant AI audit trails where only the necessary compliance attributes are exposed.