The authoritative specification is the W3C Decentralized Identifiers (DIDs) v1.0 specification, which defines:

• DID Syntax (Section 3.1): The universal structure did:method:method-specific-id
• DID Documents (Section 4): Data model for identifier metadata
• DID Methods (Section 8): Extension mechanism for method-specific implementations
• DID Resolution (Section 7.1): Process for retrieving DID documents
• DID URL Dereferencing (Section 7.2): Mechanism for accessing resources

The specification establishes DIDs as URIs (Uniform Resource Identifiers) following RFC 3986, with the did: URI scheme registered with IANA.

Version History and Evolution

The DID specification evolved through several phases:

1. Early Conceptualization (2015-2016): Initial work on self-sovereign identity and self-certifying identifiers
2. W3C Community Group (2017-2019): Development of initial specification drafts
3. W3C Working Group (2019-2022): Formal standardization process
4. W3C Recommendation (2022): Publication of DIDs v1.0 as official standard

The specification explicitly acknowledges that many—but not all—DID methods utilize distributed ledger technology (DLT) or decentralized networks. This qualification is significant because it establishes that DLT or blockchain infrastructure is common but not mandatory, allowing for diverse implementation approaches including ledgerless architectures like KERI.

Protocol Architecture

High-Level Architecture Components

The DID architecture consists of four primary components:

1. DID Syntax

The DID syntax follows a hierarchical structure:

did:method:method-specific-id[:path][?query][#fragment]

Where:

• did: - The URI scheme identifier
• method - The specific DID method name (e.g., keri, webs, web, key)
• method-specific-id - Method-specific identifier string
• Optional components: path, query, and fragment following URI conventions

2. DID Documents

A DID document is a set of data describing the DID subject, containing:

• Verification Methods: Cryptographic public keys for authentication
• Verification Relationships: Purpose-specific key associations (authentication, assertion, key agreement, capability invocation, capability delegation)
• Service Endpoints: Network addresses for interacting with the DID subject
• Metadata: Additional properties like creation timestamps, update timestamps

The DID document serves as the resolved representation of a DID, providing the cryptographic material and metadata necessary for verifying control and establishing secure communications.

3. DID Methods

A DID method is a specification defining how a particular DID scheme operates. Each method must specify:

• Create: How to create a new DID and DID document
• Read/Resolve: How to retrieve the current DID document
• Update: How to modify an existing DID document
• Deactivate: How to mark a DID as no longer active

DID methods provide the implementation-specific mechanisms that enable the abstract DID specification to function across diverse infrastructures. Examples include:

• did:keri - KERI-based method using key event logs
• did:webs - Web-based method with KERI security
• did:web - Simple web-based method using HTTPS
• did:key - Static cryptographic key method

4. DID Resolution

DID resolution is the process of retrieving a DID document given a DID. The resolution process:

1. Input: DID string and resolution options
2. Method Selection: Identify the DID method from the method name
3. Method-Specific Resolution: Execute the method's Read operation
4. Output: DID document in conforming representation plus metadata

Resolution relies on the Read operation of the applicable DID method, making it method-specific in implementation but standardized in interface.

Data Flow and Control Flow

The DID architecture implements a separation of concerns between:

Control Plane:

• DID creation and key management
• DID document updates and key rotations
• Deactivation and recovery operations

Data Plane:

• DID resolution and document retrieval
• Verification method lookup
• Service endpoint discovery

This separation enables controllers to manage identifiers independently while verifiers can resolve and verify identifiers without requiring permission from controllers or intermediaries.

State Management Approach

DID state management varies by method:

Ledger-Based Methods: Store DID documents or state commitments on distributed ledgers, with state transitions recorded as blockchain transactions.

Ledgerless Methods: Maintain state through cryptographically verifiable data structures (like KERI's key event logs) without shared ledger infrastructure.

Web-Based Methods: Store DID documents at well-known web locations, with state managed through standard web infrastructure.

The W3C specification is infrastructure-agnostic, allowing each method to define its own state management approach while maintaining interoperability through the common DID document data model.

Message Formats & Encoding

DID Syntax Specification

The DID syntax is formally defined using ABNF (Augmented Backus-Naur Form):

did                = "did:" method ":" method-specific-id
method             = 1*method-char
method-char        = %x61-7A / DIGIT  ; lowercase letters and digits
method-specific-id = *idchar *( ":" *idchar )
idchar             = ALPHA / DIGIT / "." / "-" / "_"

Key constraints:

• Method names must be lowercase alphanumeric
• Method-specific IDs may contain colons for namespacing
• Total DID length should be kept reasonable for practical use

DID Document Data Model

The DID document data model is defined abstractly, with multiple concrete representations:

Core Properties

Required Properties:

• id - The DID subject identifier

Optional Properties:

• controller - Entity(ies) authorized to make changes
• verificationMethod - Array of verification method objects
• authentication - Verification methods for authentication
• assertionMethod - Verification methods for assertions
• keyAgreement - Verification methods for key agreement
• capabilityInvocation - Verification methods for capability invocation
• capabilityDelegation - Verification methods for capability delegation
• service - Array of service endpoint objects

Verification Method Structure

A verification method object contains:

{
  "id": "did:example:123#key-1",
  "type": "Ed25519VerificationKey2020",
  "controller": "did:example:123",
  "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
}

Where:

• id - Verification method identifier (typically a DID URL with fragment)
• type - Cryptographic suite identifier
• controller - DID of the controlling entity
• Public key material in method-specific encoding

Representation Formats

The W3C specification defines multiple representation formats:

JSON Representation

The primary representation uses JSON with specific requirements:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "did:example:123456789abcdefghi",
  "verificationMethod": [{
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }],
  "authentication": [
    "did:example:123456789abcdefghi#keys-1"
  ]
}

The @context field is a representation-specific entry meaningful only in JSON-LD representation.

JSON-LD Representation

JSON-LD representation adds semantic web capabilities through linked data contexts, enabling semantic interoperability and RDF processing.

Other Representations

The specification allows for additional representations (CBOR, MessagePack, etc.) provided they maintain semantic equivalence with the abstract data model.

Field Definitions and Semantics

DID Subject: The entity identified by the DID, which can be anything (person, organization, thing, data model, abstract entity).

DID Controller: Entity(ies) with the capability to make changes to the DID document. A DID may have multiple controllers, and the controller might be the DID subject itself or a separate entity.

Verification Relationships: Define the purpose for which verification methods may be used:

• authentication - Proving control of the DID
• assertionMethod - Issuing verifiable credentials
• keyAgreement - Establishing secure communication
• capabilityInvocation - Invoking capabilities
• capabilityDelegation - Delegating capabilities

Service Endpoints: Means of communicating with the DID subject, including discovery services, agent services, messaging services, and credential repositories.

Protocol Mechanics

DID Creation Process

DID creation follows a method-specific process:

1. Key Generation: Generate cryptographic key pair(s)
2. Identifier Derivation: Derive DID according to method rules
3. Document Creation: Construct initial DID document
4. Registration: Record DID according to method (ledger transaction, file creation, etc.)
5. Verification: Confirm successful creation

For KERI-based methods like did:keri, creation involves:

• Generating inception event with initial keys
• Computing self-addressing identifier from inception event
• Establishing witness pool for key event receipting
• Publishing key event log

DID Resolution Process

Resolution transforms a DID into a DID document:

1. Parse DID: Extract method name and method-specific identifier
2. Select Resolver: Identify appropriate resolver for the method
3. Execute Resolution: Invoke method-specific Read operation
4. Construct Response: Package DID document with resolution metadata
5. Return Result: Provide conforming representation

Resolution Metadata includes:

• contentType - Media type of the representation
• created - Timestamp of DID creation
• updated - Timestamp of last update
• Method-specific metadata

Document Metadata includes:

• created - When the DID document was created
• updated - When the DID document was last updated
• deactivated - Whether the DID has been deactivated
• versionId - Version identifier for the document

DID Update Process

Updating a DID document follows method-specific procedures:

1. Authenticate Controller: Prove control authority
2. Construct Update: Create updated DID document
3. Submit Update: Execute method-specific Update operation
4. Verify Update: Confirm successful modification

For KERI-based methods, updates occur through:

• Key rotation events in the key event log
• Interaction events for non-key-state changes
• Cryptographic verification through event signatures

DID Deactivation Process

Deactivation marks a DID as no longer active:

1. Authenticate Controller: Prove control authority
2. Submit Deactivation: Execute method-specific Deactivate operation
3. Update State: Mark DID as deactivated
4. Propagate Change: Ensure resolvers recognize deactivation

Deactivated DIDs cannot be reactivated, ensuring finality of the deactivation decision.

State Transitions

DID lifecycle state transitions:

[Non-existent] --create--> [Active] --update--> [Active]
                              |
                              +--deactivate--> [Deactivated]

Once deactivated, a DID cannot transition back to active state, providing immutable deactivation semantics.

Timing and Ordering Requirements

The W3C specification does not mandate specific timing requirements, leaving these to individual DID methods. However, general principles include:

• Eventual Consistency: Resolution should eventually reflect the current state
• Monotonic Updates: Updates should be ordered and non-conflicting
• Deactivation Finality: Deactivation is irreversible

KERI-based methods provide strong ordering guarantees through key event logs with cryptographic chaining.

Security Properties

Threat Model

The DID specification addresses several threat categories:

1. Impersonation Attacks

Threat: Attacker creates a DID claiming to represent a legitimate entity.

Mitigation: DIDs alone do not prevent impersonation; they must be combined with:

• Verifiable credentials from trusted issuers
• Out-of-band verification of DID ownership
• Reputation systems and trust frameworks

2. Man-in-the-Middle Attacks

Threat: Attacker intercepts DID resolution and provides fraudulent DID document.

Mitigation:

• Cryptographic binding between DID and verification methods
• End-to-end verifiable resolution (as in KERI)
• Multiple independent resolution paths

3. Key Compromise

Threat: Attacker obtains private keys controlling a DID.

Mitigation:

• Key rotation capabilities in DID methods
• Multi-signature requirements
• Hardware security modules for key storage
• Pre-rotation mechanisms (KERI-specific)

4. Correlation Attacks

Threat: Attacker correlates DID usage across contexts to track subjects.

Mitigation:

• Pairwise DIDs for different relationships
• Ephemeral DIDs for temporary interactions
• Privacy-preserving credential presentations

Security Guarantees

The DID specification provides:

Cryptographic Verifiability: Control over a DID can be cryptographically proven through signatures with verification methods listed in the DID document.

Decentralized Control: No centralized authority can unilaterally revoke or modify a DID (method-dependent).

Persistent Identifiers: DIDs remain valid over time, enabling long-term verifiable relationships.

Method-Specific Security: Each DID method defines its own security properties, which may include:

• Immutability (ledger-based methods)
• Duplicity detection (KERI-based methods)
• Censorship resistance (blockchain methods)

Attack Resistance

Sybil Attacks: DIDs do not inherently prevent Sybil attacks (creating many identities). Resistance requires:

• Proof-of-work or proof-of-stake (blockchain methods)
• Witness consensus (KERI methods)
• Social verification and reputation

Eclipse Attacks: Relevant for peer-to-peer resolution systems. Mitigation includes:

• Multiple independent resolvers
• Cryptographic verification of resolved documents
• Witness/watcher networks (KERI)

Quantum Computing Threats: Current cryptographic algorithms may be vulnerable to quantum attacks. Mitigation strategies:

• Post-quantum cryptographic algorithms
• Hash-based commitments (KERI pre-rotation)
• Cryptographic agility in DID methods

Interoperability

Relations to KERI/ACDC Protocols

DIDs serve as the identifier layer for KERI-based systems:

KERI Integration

did:keri Method: Implements DIDs using KERI's key event infrastructure:

• DID derived from KERI AID (Autonomic Identifier)
• DID document generated from key event log state
• Resolution requires access to key event receipt log (KERL)
• Updates occur through KERI rotation and interaction events

The did:keri method provides:

• End-verifiable resolution: No trust in resolver infrastructure required
• Duplicity detection: Conflicting key states are cryptographically evident
• Post-quantum security: Through KERI's pre-rotation mechanism

did:webs Method: Combines web-based discovery with KERI security:

• DID hosted at web location (like did:web)
• KERI event stream provides cryptographic verification
• Web infrastructure for discovery, KERI for security
• Enables gradual migration from did:web to full KERI

ACDC Integration

DIDs serve as issuer and subject identifiers in ACDC credentials:

• Issuer AID: Top-level i field contains issuer's DID
• Subject Identification: Attributes may reference subject DIDs
• Verification Method Lookup: DID resolution provides keys for signature verification
• Service Endpoint Discovery: DID documents provide communication endpoints

ACDCs extend DIDs by providing:

• Chained credentials: Directed acyclic graphs of verifiable claims
• Selective disclosure: Privacy-preserving attribute revelation
• Graduated disclosure: Progressive information revelation

Integration Points

Verifiable Credentials: DIDs serve as identifiers for:

• Credential issuers
• Credential subjects
• Credential holders (when different from subject)

The W3C Verifiable Credentials specification explicitly supports DIDs as the primary identifier type.

DIDComm: Secure messaging protocol using DIDs for:

• Sender identification
• Recipient identification
• Service endpoint discovery
• Key agreement for encryption

Verifiable Presentations: DIDs identify:

• Presentation holders
• Presentation verifiers
• Referenced credential issuers

Authentication Protocols: DIDs enable:

• Challenge-response authentication
• Proof of control over identifiers
• Delegation of authentication authority

Dependencies on Other Protocols

URI/URL Standards (RFC 3986): DIDs are URIs and follow URI syntax rules.

Cryptographic Standards: DIDs depend on:

• Digital signature algorithms (Ed25519, ECDSA, RSA)
• Hash functions (SHA-256, SHA-3, Blake2, Blake3)
• Key derivation functions

JSON/JSON-LD: Primary representation formats for DID documents.

HTTPS: Many DID methods use HTTPS for:

• DID document hosting (did:web, did:webs)
• Resolver APIs
• Service endpoints

Distributed Ledgers: Blockchain-based DID methods depend on:

• Specific ledger protocols (Bitcoin, Ethereum, Hyperledger Indy)
• Transaction formats and consensus mechanisms
• Smart contract platforms

Implementation Considerations

Common Challenges

Method Selection

Challenge: Choosing appropriate DID method for use case.

Considerations:

• Security requirements: Level of cryptographic assurance needed
• Performance requirements: Resolution latency and throughput
• Infrastructure dependencies: Ledger requirements, witness networks, web hosting
• Privacy requirements: Correlation resistance, selective disclosure
• Cost considerations: Transaction fees, infrastructure costs

KERI-based methods (did:keri, did:webs) offer strong security without ledger dependencies but require witness/watcher infrastructure.

Resolution Infrastructure

Challenge: Implementing reliable DID resolution.

Considerations:

• Universal Resolver: Use existing resolver infrastructure vs. method-specific resolvers
• Caching strategies: Balance freshness with performance
• Fallback mechanisms: Handle resolver failures gracefully
• Verification: Cryptographically verify resolved documents when possible

KERI-based methods enable end-verifiable resolution, eliminating trust in resolver infrastructure.

Key Management

Challenge: Securely managing private keys controlling DIDs.

Considerations:

• Key storage: Hardware security modules, secure enclaves, software keystores
• Key rotation: Regular rotation schedules, compromise recovery
• Multi-signature: Threshold schemes for enhanced security
• Backup and recovery: Secure backup without compromising security

KERI's pre-rotation mechanism provides post-quantum secure key rotation and compromise recovery.

Privacy Protection

Challenge: Preventing correlation across contexts.

Considerations:

• Pairwise DIDs: Unique DID for each relationship
• DID rotation: Periodic rotation of DIDs
• Minimal disclosure: Reveal only necessary information
• Unlinkable presentations: Use privacy-preserving credential presentations

Performance Considerations

Resolution Latency:

• Ledger-based methods: Depends on ledger query performance
• Web-based methods: Depends on HTTPS latency
• KERI-based methods: Depends on witness/watcher network access

Scalability:

• Ledger-based methods: Limited by ledger throughput
• Web-based methods: Scales with web infrastructure
• KERI-based methods: Scales independently per identifier

Storage Requirements:

• DID documents: Typically small (few KB)
• Key event logs (KERI): Grows with number of events
• Ledger storage: Depends on ledger architecture

Interoperability Testing

Implementers should test:

• Cross-method resolution: Resolving DIDs from different methods
• Representation conversion: Converting between JSON, JSON-LD, CBOR
• Verification method compatibility: Supporting multiple cryptographic suites
• Service endpoint protocols: Interoperating with various endpoint types

Standards Compliance

Implementations should:

• Follow W3C specification: Implement required features correctly
• Support standard representations: At minimum, JSON representation
• Implement security best practices: Key management, signature verification
• Document method-specific behavior: Clearly specify deviations or extensions

Migration Strategies

For transitioning from centralized identifiers:

• Gradual adoption: Support both DID and legacy identifiers
• Identifier mapping: Maintain mappings between old and new identifiers
• Dual authentication: Accept both authentication methods during transition
• Deprecation timeline: Clearly communicate migration schedule

KERI-based did:webs provides a migration path from did:web by adding cryptographic verification to existing web-based DIDs.

Privacy Implementation

• Use pairwise DIDs: Create unique DIDs for each relationship to prevent correlation
• Minimize disclosure: Only include necessary information in DID documents
• Support selective disclosure: Enable privacy-preserving credential presentations
• Rotate DIDs periodically: Change DIDs regularly to limit tracking

Interoperability

• Support standard representations: Implement at minimum JSON representation
• Handle multiple cryptographic suites: Support Ed25519, ECDSA, and other common algorithms
• Test cross-method compatibility: Verify interoperability with other DID methods
• Document extensions: Clearly specify any method-specific extensions or deviations