How to pick a DID method

This guide helps you select the right Decentralized Identifier (DID) method for your needs in Vidos. By following a structured decision process, you’ll identify the method that best matches your requirements and use case.

Prerequisites

Before selecting a DID method, ensure you have:

• Basic understanding of DID concepts
• Familiarity with your application’s security and privacy requirements
• Knowledge of any regulatory constraints that apply to your use case
• Access to Vidos resolver and related services

Why DID method selection matters

The DID method you choose directly impacts:

• Security properties of your identifiers
• Privacy characteristics and correlation risks
• Technical integration complexity
• Operational costs and performance
• Cross-platform compatibility
• Regulatory compliance

Making an informed choice aligns your identity infrastructure with your specific needs while avoiding unnecessary complexity or limitations.

Selection framework

Step 1: Define your requirements

Start by clearly documenting your requirements in these key areas:

Security requirements

• Control mechanism: How will identifier control be maintained?
• Key management: What key management capabilities do you need?
• Revocation: How will you handle compromised identifiers?
• Attack resistance: What threats must you defend against?

Privacy considerations

• Correlation risk: How important is preventing correlation across contexts?
• Data minimization: What information should be publicly disclosed?
• Selective disclosure: Do you need to reveal attributes selectively?
• Regulatory compliance: What privacy regulations apply?

Technical requirements

• Infrastructure: What systems must the DID method integrate with?
• Scalability: How many identifiers and operations will you handle?
• Performance: What response time requirements exist?
• Persistence: How long must identifiers remain valid?

Implementation factors

• Development expertise: What technologies is your team familiar with?
• Time constraints: How quickly must you implement the solution?
• Budget: What resources are available for development and operation?
• Maintenance: Who will maintain the system long-term?

Step 2: Evaluate method types against requirements

Before comparing specific methods, understand the general categories of DID methods and their characteristics:

flowchart TD
    subgraph "DID Method Categories"
        A["Cryptographic Methods
(did:key, did:jwk)"] --> A1["Strengths: No network dependency
Self-contained & fast resolution
Ideal for testing"]
        A --> A2["Limitations: Limited functionality
No revocation or update capability"]

        B["Blockchain Methods
(did:ethr, did:ion, etc.)"] --> B1["Strengths: Decentralized trust
Supports key rotation & updates"]
        B --> B2["Limitations: May have slower resolution
Network dependency"]

        C["Web-based Methods
(did:web)"] --> C1["Strengths: Easy to implement
Uses existing web infrastructure"]
        C --> C2["Limitations: Domain owner control
Centralized trust model"]
    end

Use this decision matrix to compare different DID method types against common requirements:

Requirement	Blockchain-based (ethr, ion, cheqd)	Key-based (key, jwk)	Web-based (web)	P2P	Multi-chain (pkh)
Security
Censorship resistance	Strong	Strong	Limited	Moderate	Strong
Key rotation	Strong	Not supported	Moderate	Limited	Limited
Cryptographic agility	Moderate	Limited	Strong	Moderate	Limited
Tamper evidence	Strong	Strong	Limited	Moderate	Strong
Privacy
Correlation resistance	Limited	Strong	Limited	Strong	Limited
Minimal disclosure	Limited	Strong	Moderate	Strong	Limited
Selective disclosure	Moderate	Limited	Strong	Limited	Limited
Technical
No external dependencies	Limited	Strong	Limited	Moderate	Limited
Read performance	Moderate	Strong	Strong	Moderate	Moderate
Write performance	Limited	Not applicable	Strong	Moderate	Limited
Scalability	Moderate	Strong	Strong	Strong	Moderate
Implementation
Simplicity	Moderate	Strong	Strong	Moderate	Moderate
Developer familiarity	Moderate	Strong	Strong	Limited	Moderate
Ecosystem maturity	Strong	Strong	Strong	Limited	Moderate
Standards compliance	Strong	Strong	Strong	Moderate	Strong

Step 3: Match methods to common use cases

Different methods excel in specific scenarios:

Self-sovereign identity

For user-controlled, portable identity with minimal dependencies:

• Recommended: did:key, did:jwk
• Benefits: Self-contained, offline verification, no external infrastructure
• Example: did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

Enterprise identity

For organizational identities with existing infrastructure:

• Recommended: did:web, did:ethr (private networks)
• Benefits: Integrates with existing systems, familiar to IT teams
• Example: did:web:example.com:department:identity

Cross-platform applications

For identities that work across multiple ecosystems:

• Recommended: did:pkh, did:ion
• Benefits: Works with multiple blockchains or platforms
• Example: did:pkh:eip155:1:0xb9c5714089478a327f09197987f16f9e5d936e8a

Privacy-focused applications

For applications where privacy and data minimization are critical:

• Recommended: did:key
• Benefits: Minimal correlation risk, selective disclosure support
• Example: did:key:z2dmzD81cgPx8Vki7JbuuMmFYrWPgYoytykUZ3eyqht1j9Kboj7g9PfXJxbbs4KYegyr7ELnFVnpDMzbJJDDNZjavX6jvtDmALMbXAGW67pdTgFea2FrGGSFs8Ejxi96oFLGHcL4P6bjLDPBJEvRRHSrG4LsPne52fczt2MWjHLLJBvhAC

Regulatory compliance

For applications subject to specific regulatory frameworks:

• Recommended: did:ebsi (EU), did:web (general)
• Benefits: Designed for specific regulatory environments
• Example: did:ebsi:zbM8cCuoBMFNLeQyLiVFyxw

Step 4: Detailed method evaluation

Once you’ve narrowed your options, consider these specific factors for each method:

Blockchain-based methods

Advantages:

• Strong security through decentralized consensus
• Transparent history of operations
• Tamper-evident record keeping

Considerations:

• Higher operational costs (transaction fees)
• Slower operation execution
• Public nature may create privacy concerns

Best for: Applications requiring high security, auditability, and decentralization where performance and cost are less critical.

Key-based methods

Advantages:

• Self-contained verification
• Works offline without network access
• Simple implementation with minimal dependencies

Considerations:

• Limited update capabilities
• No built-in revocation mechanism
• Fixed cryptographic algorithm per identifier

Best for: Lightweight applications, bootstrapping trust, and offline scenarios.

Web-based methods

Advantages:

• Utilizes existing web infrastructure
• Easy integration with organizational systems
• Familiar technology stack for web developers

Considerations:

• Centralized control through domain ownership
• Depends on DNS and web hosting
• Potential single point of failure

Best for: Organizational identity, integration with existing web services, and simpler implementation needs.

Multi-chain methods

Advantages:

• Works across multiple blockchain ecosystems
• Leverages existing blockchain accounts
• Familiar to blockchain users

Considerations:

• Inherits limitations of underlying chains
• Privacy and correlation concerns
• May require multiple implementations

Best for: Applications spanning multiple blockchains or leveraging existing blockchain identities.

Step 5: Testing and validation

Before final implementation:

1. Create test identifiers with your selected method
2. Verify resolution works as expected
3. Test operations (create, update, deactivate) if applicable
4. Evaluate performance under expected load
5. Check compatibility with other systems and services

Implementation in Vidos

Once you’ve selected a DID method, follow these steps to implement it in Vidos:

Configure the resolver service

The Vidos resolver service supports multiple DID methods. To configure your chosen method:

1. Access the resolver management service
2. Add or enable the selected DID method
3. Configure method-specific parameters if needed
4. Test resolution with sample DIDs

Integration with other Vidos services

Ensure your selected DID method works with other required Vidos services:

Authorizer

Configure the authorizer service to use a verifier that has been configured to use a resolver configured with your preferred DID method options.

Verifier

Configure the verifier to use a resolver configured with your preferred DID method options.

Method-specific considerations

did:cheqd

Configuration notes:

• Specify network (mainnet or testnet)
• Consider resource linkage requirements
• Plan for resource publishing if needed

did:ethr

Configuration notes:

• Specify target networks
• Configure registry contract addresses
• Plan for key rotation if needed

did:key

Configuration notes:

• Select appropriate key types
• No additional infrastructure needed
• Consider key management strategy

did:web

Configuration notes:

• Ensure DNS and web hosting are properly configured
• Set up HTTPS for secure resolution
• Plan document hosting structure

Examples and templates

Example requirement profile

Security requirements:
- Self-sovereign control by users
- Support for key rotation
- Protection against tampering

Privacy requirements:
- Minimal correlation risk
- Support for selective disclosure
- Limited public information

Technical requirements:
- Integration with existing Ethereum infrastructure
- Support for mobile and web clients
- Expected volume: 10,000 identifiers per month

Implementation factors:
- Team expertise in Ethereum development
- 3-month implementation timeline
- Budget for moderate transaction costs

Recommended method: did:ethr based on requirements profile

Example requirement profile: Regulatory compliance

Regulatory requirements:
- Compliance with European eIDAS framework
- Auditability of identity operations
- Alignment with EU data sovereignty principles

Security requirements:
- Institutional control and governance
- Transparent validation processes
- Standardized cryptographic approaches

Privacy requirements:
- GDPR compliance for personal data
- Data minimization in public information
- Clear consent mechanisms for data sharing

Technical requirements:
- Integration with government identity systems
- Cross-border interoperability within EU
- Support for qualified electronic signatures

Implementation factors:
- Public sector deployment context
- Need for standards body recognition
- Long-term stability and maintenance

Recommended method: did:ebsi for EU regulatory alignment and cross-border compatibility

Example requirement profile: Proof of Concept

Project context:
- Early-stage exploration of decentralized identity
- Educational demonstration for stakeholders
- Technical feasibility evaluation
- Limited timeline (2-4 weeks)

Technical requirements:
- Minimal infrastructure setup
- Quick implementation time
- No production deployment needs
- Demonstrable on standard developer machines

Implementation factors:
- Small team (1-2 developers)
- Limited prior DID experience
- Need for clear, visible results
- Focus on core concepts rather than scalability

Key demonstration goals:
- Creation and resolution of DIDs
- Basic credential issuance and verification
- Simple integration with a test application
- Educational value for technical and non-technical audiences

Recommended method: did:key or did:web for simplicity, minimal setup, and clear demonstration value

Common challenges and solutions

Challenge: Balancing security and usability

Solution: Consider a hybrid approach where lightweight methods (did:key) are used for ephemeral operations while more robust methods (did:ethr, did:cheqd) are used for long-term identity.

Challenge: Future-proofing method selection

Solution: Select methods with broad adoption and strong standards compliance. Configure Vidos to support multiple methods to allow for future migration.

Challenge: Regulatory uncertainty

Solution: Document compliance considerations for your selected method. Choose methods with flexibility for adaptation to emerging regulations.

Challenge: Navigating complex regulatory requirements

Solution:

• Create a detailed regulatory compliance matrix mapping specific requirements to DID method capabilities
• Consult with legal experts during the method selection process
• Consider methods specifically designed for regulatory environments (like did:ebsi for EU)
• Document compliance decisions and their rationale for audit purposes
• Implement a monitoring system to track regulatory changes affecting your DID method
• Maintain relationships with standards bodies and regulatory working groups

Challenge: Building an effective Proof of Concept

Solution:

• Choose the simplest method that demonstrates the core concepts (did:key or did:web)
• Set clear, achievable goals for the POC with defined success criteria
• Focus on demonstrating the full flow (create, resolve, verify) rather than all features
• Create a narrative that connects technical capabilities to business value
• Prepare visual diagrams explaining the DID resolution process
• Build simple tools that let stakeholders interact with the system
• Document limitations and what would change in a production implementation
• Include a clear roadmap for moving from POC to production

Related resources

• DID Methods Explained
• Supported DID Methods Reference
• DID Resolution in Vidos
• Configuring the Resolver Service

By following this structured approach to DID method selection, you’ll choose a method that aligns with your specific requirements while leveraging the capabilities of the Vidos platform.