DID Methods

What are DID Methods?

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

Think of DID methods as specialized protocols that determine:

• How a DID is generated for a specific ecosystem
• How a DID resolves to its corresponding DID document
• How a DID controller can update or change the associated DID document
• How a DID can be deactivated or revoked if necessary

Each DID method implements these operations in ways that leverage the properties of their underlying technology platforms, whether that’s a blockchain, distributed ledger, peer-to-peer network, or web domain.

Why DID Methods Matter

DID methods are crucial for several reasons:

1. Technological diversity - They enable DIDs to work across different technology stacks and decentralized systems without requiring a single, centralized approach
2. Ecosystem alignment - Organizations and individuals can choose methods that align with their existing technology investments and requirements
3. Feature specialization - Different methods can prioritize specific features like security, privacy, cost, throughput, or compliance
4. Progressive innovation - New methods can emerge to address novel use cases without breaking existing implementations

This flexibility is central to the DID architecture’s goal of providing decentralized identity that works across many contexts while remaining under the control of the identity owner.

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, which follows rules defined by each DID method specification. This identifier can take various forms:

• Cryptographic material (like a public key or its hash)
• Blockchain addresses or transaction references
• Domain names or paths
• UUIDs or other unique identifiers

For example, in did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK, the string beginning with z6Mk... is a multibase-encoded public key that serves as the method-specific identifier.

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

The create operation generates a new DID within the specific method’s environment. This typically involves:

• Generating cryptographic keys
• Recording information on an underlying system (for some methods)
• Constructing the initial DID document
• Ensuring the DID is globally unique within its method space

For example, the did:key method creates DIDs by directly encoding a generated public key, while did:ethr might require a transaction on the Ethereum blockchain.

2. Read (Resolve)

The read operation, often called resolution, retrieves the DID document associated with a DID. This process varies significantly between methods:

• did:web resolves by fetching a document from a web server
• did:ethr resolves by reading state from the Ethereum blockchain
• did:key constructs a DID document directly from the encoded key material

Resolution may also include additional steps for verification, dereferencing, or handling method-specific parameters.

3. Update

The update operation allows a DID controller to modify the DID document. Methods define specific mechanisms for proving control and executing updates:

• Cryptographic signatures proving ownership of control keys
• Blockchain transactions with appropriate permissions
• Web authentication for domain-controlled methods

Update mechanisms must maintain security and allow for key rotation, service endpoint changes, and other modifications.

4. Deactivate

The deactivate operation signals that a DID should no longer be used. This might include:

• Setting a special flag in the DID document
• Removing resolution capability
• Cryptographically invalidating the identifier
• Recording a deactivation event on a registry

Types of DID Methods

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

Blockchain-Based Methods

Blockchain-based methods like did:ethr, did:ion, and did:cheqd leverage distributed ledger technology to provide:

• High availability through decentralized networks
• Tamper-evident record keeping
• Time-ordered history of changes
• Censorship resistance

These methods typically offer strong security and persistence at the cost of higher complexity and potentially higher operational expenses.

Non-Blockchain Distributed Methods

Methods like did:peer use other forms of distributed systems such as distributed hash tables or peer-to-peer networks. These offer:

• Reduced resource requirements compared to blockchains
• No cryptocurrency dependency
• Often faster operations
• Different decentralization and security trade-offs

Key-Based Methods

Methods like did:key and did:jwk directly encode cryptographic material in the identifier itself, providing:

• Self-contained verification capability
• No external resolution infrastructure required
• Simplicity and portability
• Limited update or deactivation capabilities

These methods are ideal for lightweight or ephemeral identities and bootstrapping trust relationships.

Domain-Based Methods

Methods like did:web and did:dns leverage existing web infrastructure:

• Familiar technology stack
• Easy integration with existing systems
• Leverages existing trust frameworks
• Usually simpler implementation

Domain-based methods often trade some aspects of decentralization for practicality and immediate usability.

DID Method Selection Criteria

When selecting a DID method, consider these key factors:

Security Requirements

• Key management capabilities
• Cryptographic algorithm flexibility
• Resistance to tampering or censorship
• Verification guarantees

Privacy Considerations

• Information disclosure requirements
• Correlation risks
• Data minimization capabilities
• Selective disclosure support

Technical Requirements

• Performance and scalability needs
• Integration with existing systems
• Complexity of implementation
• Operational costs

Governance and Trust

• Method governance model
• Alignment with regulatory requirements
• Ecosystem support and adoption
• Long-term sustainability

No single method is optimal for all use cases. The best approach is to match method selection to specific application requirements and constraints.

DID Methods in Vidos

Vidos supports multiple DID methods to provide flexibility and interoperability across different identity ecosystems. For a comprehensive list of all supported methods and their specific implementations, see the Supported DID Methods reference documentation. This multi-method approach enables:

Unified Interface with Method Diversity

Vidos abstracts the complexity of different DID methods behind consistent interfaces while preserving the unique capabilities of each method. This allows applications to:

• Work with multiple DID methods through standardized APIs
• Leverage method-specific features when needed
• Migrate between methods as requirements evolve

Resolution Architecture

The Vidos resolver service acts as a unified resolution endpoint that:

1. Parses DIDs to identify their method
2. Routes resolution requests to the appropriate method-specific resolver
3. Returns standardized DID document responses
4. Handles method-specific parameters and options

Method-Specific Configuration

Each DID method in Vidos can be configured through its dedicated management service, allowing for:

• Custom resolution endpoints
• Method-specific verification rules
• Integration with external systems
• Performance optimizations

Common DID Method Use Cases

Different DID methods excel in specific scenarios:

Self-Sovereign Identity

Methods like did:key, did:ion, and did:cheqd support self-sovereign identity use cases where the individual maintains full control without dependence on centralized authorities.

Enterprise Identity

Methods like did:web and domain-based approaches often work well in enterprise contexts where existing infrastructure and organizational governance are important factors.

Cross-Platform Integration

Multi-chain methods like did:pkh facilitate identity that works across different blockchain ecosystems, enabling broader interoperability.

Privacy-Focused Applications

Methods with enhanced privacy features like selective disclosure and minimal correlation support privacy-preserving applications.

Regulatory Compliance

Methods like did:ebsi are designed with specific regulatory frameworks in mind, making them suitable for government and regulated industry applications.

Future of DID Methods

The DID method landscape continues to evolve with:

• New methods emerging to address specific use cases
• Existing methods improving their capabilities
• Greater interoperability between methods
• Standardization of common patterns and practices

Vidos maintains a modular architecture that can adapt to this evolution, allowing new methods to be integrated as they mature and gain adoption.

Conclusion

DID methods transform the 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 application needs.

Vidos provides a flexible framework that supports multiple methods while maintaining consistent interfaces, allowing you to leverage the specific advantages of each method 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.