DID Methods

What are DID Methods?

Decentralized Identifier (DID) methods define how DIDs are created, resolved, updated, and deactivated within specific environments. While the DID core specification establishes syntax and basic data model, methods provide implementation details for different technological infrastructures.

Each method determines how a DID is generated, resolves to its document, can be updated by its controller, and can be deactivated if necessary. Methods leverage the properties of their underlying platforms—blockchain, distributed ledger, peer-to-peer network, or web domain.

Why DID Methods Matter

DID methods enable:

• Technological diversity (work across different stacks)
• Ecosystem alignment (match existing investments)
• Feature specialization (prioritize security, privacy, cost, or compliance)
• Progressive innovation (new methods without breaking implementations)

DID Method Structure

Method Identifier

Every DID contains a method identifier that follows the did: scheme prefix. This method identifier specifies which protocol handles that particular DID. For example:

• did:web:example.com uses the “web” method
• did:ethr:0x123... uses the “ethr” method
• did:key:z6Mk... uses the “key” method

Method-Specific Identifier

Following the method identifier is the method-specific identifier, following rules defined by each DID method specification. This can be cryptographic material (public key/hash), blockchain addresses, domain names, or UUIDs.

Example: in did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK, the string z6Mk... is a multibase-encoded public key.

Method Parameters

Some DID methods support additional parameters that influence resolution or provide context. These parameters appear after the method-specific identifier and are preceded by a question mark:

did:example:123?service=agent&relativeRef=/credentials

Core Operations of DID Methods

Each DID method must define how the four basic operations are performed:

1. Create

Generates a new DID within the method’s environment by generating cryptographic keys, recording information on underlying systems, constructing the initial document, and ensuring global uniqueness. For example, did:key directly encodes a public key, while did:ethr requires an Ethereum blockchain transaction.

2. Read (Resolve)

Retrieves the DID document associated with a DID. Resolution varies: did:web fetches from a web server, did:ethr reads from Ethereum blockchain, did:key constructs directly from encoded key material.

3. Update

Allows DID controllers to modify the DID document through cryptographic signatures proving ownership, blockchain transactions, or web authentication. Update mechanisms maintain security and allow key rotation and service endpoint changes.

4. Deactivate

Signals that a DID should no longer be used by setting flags, removing resolution capability, cryptographically invalidating the identifier, or recording deactivation events.

Types of DID Methods

DID methods can be categorized based on their underlying technology infrastructure:

Blockchain-Based Methods

Methods like did:ethr, did:ion, and did:cheqd leverage distributed ledger technology providing:

• High availability
• Tamper-evident records
• Time-ordered history
• Censorship resistance

They offer strong security and persistence at higher complexity and cost.

Non-Blockchain Distributed Methods

Methods like did:peer use distributed hash tables or peer-to-peer networks, offering reduced resource requirements, no cryptocurrency dependency, faster operations, and different decentralization trade-offs.

Key-Based Methods

Methods like did:key and did:jwk directly encode cryptographic material in the identifier, providing self-contained verification, no external resolution infrastructure, simplicity, and portability. Limited update/deactivation capabilities make them ideal for lightweight or ephemeral identities.

Domain-Based Methods

Methods like did:web and did:dns leverage existing web infrastructure with familiar technology, easy integration, existing trust frameworks, and simpler implementation. They trade some decentralization for practicality.

DID Method Selection Criteria

When selecting a method, consider:

• Security requirements (key management, cryptographic algorithms, tamper resistance)
• Privacy considerations (information disclosure, correlation risks, data minimization)
• Technical requirements (performance, integration, complexity, costs)
• Governance and trust (governance model, regulatory alignment, ecosystem support, sustainability)

No single method is optimal for all use cases—match method selection to specific application requirements.

DID Methods in Vidos

Vidos supports multiple DID methods for flexibility and interoperability. See Supported DID Methods for the complete list.

Vidos abstracts method complexity behind consistent interfaces while preserving unique capabilities. The resolver service parses DIDs, routes resolution requests to method-specific resolvers, and returns standardized responses. Each method can be configured through management services for custom endpoints, verification rules, and performance optimizations.

Conclusion

DID methods transform abstract concepts of decentralized identity into practical, implementable solutions across diverse technology ecosystems. By understanding the characteristics, operations, and trade-offs of different methods, you can make informed decisions about which approaches best suit your needs.

Vidos provides a flexible framework that supports multiple methods while maintaining consistent interfaces, allowing you to leverage specific advantages within a unified identity management system.

For technical details, implementation specifics, and a full list of the DID methods currently supported in Vidos, refer to the Supported DID Methods reference documentation.