DID Method

The process of generating a new DID and its associated DID Document on the target ledger. This involves creating a unique identifier string (the DID) and cryptographically anchoring its initial state, which includes the public keys and service endpoints for verification and interaction.

• Example: did:ethr:0xabc123... is created by submitting a transaction to the Ethereum blockchain.

The mechanism for retrieving the current, valid DID Document associated with a given DID. A DID resolver fetches this data from the underlying verifiable data registry and returns it in a standard JSON-LD format. This is essential for any party to discover the controller's public keys and services.

• Relies on: The method's specific resolution algorithm and the integrity of the underlying ledger.

The operation that allows the DID controller to modify their DID Document. Changes can include adding or rotating public keys, updating service endpoints, or modifying verification methods. The method defines the authorization rules, typically requiring a cryptographic proof (e.g., a signature from a current authorized key).

• Critical for: Key rotation, credential recovery, and maintaining an up-to-date identity state.

The process of permanently disabling a DID, rendering it unusable for future authentication or verification. This is a crucial security feature for handling key compromise or identity retirement. The method specifies how this state change is recorded on the ledger, often by setting a flag or removing all active verification methods.

• Ensures: The DID cannot be falsely asserted after deactivation.

Defines the cryptographic algorithms and key formats supported by the method for creating proofs and securing operations. Common suites include Ed25519 signatures, secp256k1 (used by Bitcoin/Ethereum), or BLS signatures. The DID Document expresses these as verification methods.

• Interoperability: A method's supported suites determine its compatibility with other W3C Verifiable Credential ecosystems.

Specifies the verifiable data registry the method uses (e.g., Bitcoin, Ethereum, ION/Sidetree, a private ledger) and the governance model controlling its specification. This includes who can propose changes to the method and how disputes are resolved. The registry provides the immutable, censorship-resistant backbone for DID state.

• Examples: did:ethr uses Ethereum, did:web uses HTTPS, did:key is stateless.

A DID Method is defined by a DID Method Specification, a formal document that outlines the precise operations for a DID's lifecycle. This includes:

• CRUD Operations: The exact mechanisms for Creating, Reading (resolving), Updating, and Deactivating DIDs.
• Syntax: The structure of the DID itself (e.g., did:ethr:0x...).
• Verifiable Data Registry: The specific blockchain or system (like Ethereum, Bitcoin, or a private ledger) that serves as the root of trust for the identifiers.

Hundreds of DID Methods exist, each tailored to a specific network's capabilities. Prominent examples include:

• did:ethr: For Ethereum and EVM-compatible chains, managed via smart contracts.
• did:key: A simple method using a public key directly, without a blockchain.
• did:web: Uses domains and HTTPS for resolution, bridging to traditional web infrastructure.
• did:ion: A Sidetree-based method for high-throughput operations, often implemented on Bitcoin or Ethereum as a layer-2.

The Verifiable Data Registry (VDR) is the decentralized system—typically a blockchain—that the DID Method uses as its anchor. It stores the DID Document in a tamper-evident way. Key functions of the registry include:

• Immutable Anchoring: Publishing the initial hash of the DID Document.
• State Changes: Recording updates (like adding new public keys) as transactions.
• Decentralized Resolution: Allowing any party to independently fetch the current, valid state of the DID Document.

DID Methods enable interoperability through adherence to the W3C DID Core standard. This standard provides the universal data model (the DID Document) and core properties, while the method handles the network-specific mechanics. This separation allows:

• Portable Identifiers: A verifier can understand a did:ethr document using the same logic as a did:btcr document.
• Method-Agnostic Tools: Wallets and verifiers can be built to support multiple methods through shared libraries.

Beyond basic CRUD, methods can implement unique features leveraging their underlying network:

• Recovery Mechanisms: Social recovery schemes using smart contracts (e.g., did:ethr).
• Privacy Techniques: Zero-knowledge proofs for selective disclosure, enabled by the chain's cryptographic primitives.
• Fee Structures: Transaction cost models (gas fees, state rent) that directly impact DID management economics.

Selection depends on the application's requirements. Key decision factors include:

• Security Model: Proof-of-Work vs. Proof-of-Stake finality.
• Throughput & Cost: Transaction speed and fees for DID updates.
• Decentralization: Trust assumptions of the underlying registry.
• Ecosystem Support: Availability of SDKs, wallets, and resolver infrastructure.
• Governance: How the method specification itself is maintained and upgraded.

A Decentralized Identifier (DID) is a globally unique, persistent identifier that does not require a centralized registration authority. It is the core subject of a DID Method. A DID is a URI composed of three parts:

• DID Scheme: did:
• DID Method: e.g., ethr, web, ion
• Method-Specific Identifier: A unique string generated by the method. Example: did:ethr:0xb9c5714089478a327f09197987f16f9e5d936e8a

A Verifiable Data Registry is the underlying system where DIDs and their associated DID Documents are anchored and resolved. The choice of registry defines the DID Method's properties. Common registries include:

• Blockchains (e.g., Ethereum, Bitcoin, Solana) for high immutability.
• Decentralized Storage Networks (e.g., IPFS) for content-addressed data.
• Decentralized Web Nodes (DWNs) for personal data stores. The registry ensures the persistence and availability of the DID's cryptographic proofs.

A DID Document is a JSON-LD document containing the cryptographic material and service endpoints necessary to interact with the DID subject. It is resolved from a DID URI. Key components include:

• Public Keys: For authentication and assertion.
• Authentication & AssertionMethod verification relationships.
• Service Endpoints: To communicate with the subject (e.g., messaging, storage). The DID Document is the machine-readable data structure that makes a DID functional, and its integrity is verifiable via the Verifiable Data Registry.

A Verifiable Credential is a tamper-evident digital credential whose issuer can be cryptographically verified, often using a DID. VCs rely on DID Methods for trust. The flow is:

1. Issuer (with a DID) signs a credential.
2. Holder stores the credential.
3. Verifier checks the credential's signature against the issuer's DID Document resolved from their DID. This creates a trust model based on cryptographic proof and decentralized identifiers rather than centralized databases.

DID Resolution is the process of retrieving a DID Document from a DID URI. A DID Resolver is a software component that:

1. Parses the DID to identify its Method.
2. Uses the method-specific logic to query the corresponding Verifiable Data Registry (e.g., a blockchain).
3. Returns the DID Document in a standard format. Universal Resolver projects aim to provide a single interface for resolving DIDs across many different methods.

Self-Sovereign Identity is a design philosophy and movement for digital identity where individuals or entities have ownership and control over their own identifiers and credentials without relying on central authorities. DID Methods are the primary technical implementation enabling SSI. Core SSI principles facilitated by DIDs include:

• Existence: Users have an independent identity.
• Control: Users control their identity data.
• Access: Users can access and manage their data.
• Portability: Identity is not locked to a single system.