#Supported DID Methods

This reference documents the DID methods supported by the Resolver service. These methods can be used with Verifier configurations to establish trust in verifiable credentials.

Vidos supports multiple Decentralized Identifier (DID) methods that enable identity management across different platforms and technologies. Each method follows W3C DID specifications while offering unique characteristics for specific use cases.

This reference documents each supported DID method, its format, and implementation details. For implementation guidance, see the DID Integration Guide.

#Quick Reference

The following DID methods are available for identity resolution within the Vidos ecosystem:

Method	Foundation	Primary Use Case	Network Support	Resource Linking
did:cheqd	Cosmos	Identity with linked data	Mainnet, Testnet	Yes
did:dht	Distributed Hash Table	Decentralized resolution	N/A	No
did:ebsi	EBSI Blockchain	EU public services	EBSI Network	No
did:ens	Ethereum Name Service	Domain-based identity	Ethereum	No
did:ethr	Ethereum	Blockchain identity	Multiple Networks	No
did:ion	Bitcoin (Sidetree)	High-throughput identity	Mainnet, Testnet	No
did:jwk	JSON Web Key	Cryptographic identity	N/A	No
did:key	Public Key	Self-contained identity	N/A	No
did:oyd	Own Your Data	Self-sovereign identity	N/A	No
did:pkh	Public Key Hash	Multi-chain identity	Multiple Networks	No
did:plc	PLC Protocol	Self-sovereign identity	Centralized Directory	No
did:polygonid	Polygon	Scalable identity	Mainnet, Mumbai	No
did:web	Web Domain	Web-integrated identity	N/A	Yes

#Blockchain-Based Methods

#did:cheqd

The cheqd DID method enables verifiable data exchange on the cheqd network with enhanced privacy features for user-centric identity management.

#Technical Foundation

Built on the Cosmos blockchain, cheqd operates on both mainnet and testnet networks, enabling decentralized identity management without central authorities.

#Key Features

• Linked data resources - Retrieve credential-related resources using DIDs
• Network flexibility - Operates on both mainnet and testnet
• Resource binding - Connects DIDs to linked resources using resourceId

#Use Cases

Use cheqd DIDs when you need decentralized identity with linked resources, especially in sectors requiring enhanced data protection and verifiability.

#Format Specification

Where:

• [network] is optional (mainnet or testnet)
• <identifier> is a UUID format string
• resourceId parameter links to associated resources

#Examples

• With linked resource: did:cheqd:testnet:b5d70adf-31ca-4662-aa10-d3a54cd8f06c?resourceId=5e16a3f9-7c6e-4b6b-8e28-20f56780ee25
• Mainnet: did:cheqd:b5d70adf-31ca-4662-aa10-d3a54cd8f06c
• Explicit network: did:cheqd:mainnet:b5d70adf-31ca-4662-aa10-d3a54cd8f06c
• Testnet: did:cheqd:testnet:b5d70adf-31ca-4662-aa10-d3a54cd8f06c

#Resources

• Specification
• Linked Data Resources Documentation

#did:ebsi

The EBSI DID method provides secure, cross-border identity services across European Union member states through the European Blockchain Services Infrastructure.

#Technical Foundation

Operates on EBSI's public permissioned blockchain network, designed specifically for government and public sector applications within the EU.

#Key Features

• EU-wide interoperability - Works across all member states
• Regulatory compliance - Designed for EU regulations and standards
• Public service integration - Optimized for government services

#Use Cases

Use EBSI DIDs for public sector applications, cross-border EU services, and scenarios requiring compliance with European digital identity frameworks.

#Format Specification

Where:

• <identifier> is a base58-encoded string

#Examples

• Standard format: did:ebsi:zbM8cCuoBMFNLeQyLiVFyxw

#Resources

• EBSI Documentation

#did:ens

The ENS DID method connects decentralized identities with human-readable Ethereum Name Service domains for improved user experience.

#Technical Foundation

Based on the Ethereum Name Service infrastructure running on the Ethereum blockchain, providing name resolution for blockchain addresses.

#Key Features

• Human-readable names - Uses familiar domain-name format
• Ethereum integration - Works with the entire Ethereum ecosystem
• Reverse resolution - Supports reverse lookup from address to name

#Use Cases

Use ENS DIDs when you need human-readable identifiers for blockchain interactions, especially on Ethereum and for public-facing identity applications.

#Format Specification

Where:

• <ens-name> is a registered ENS domain

#Examples

• Standard format: did:ens:mailchain.eth

#Resources

• Specification
• ENS Documentation

#did:ethr

The Ethr DID method uses Ethereum addresses and transactions to enable lightweight, standards-compliant identity management on the Ethereum blockchain.

#Technical Foundation

Built directly on Ethereum's account system, using addresses as identifiers and transactions for identity operations.

#Key Features

• Ethereum compatible - Works with any Ethereum account
• Key rotation - Supports key management operations
• Multiple networks - Functions across various Ethereum-compatible networks

#Use Cases

Use Ethr DIDs for Ethereum-based applications, smart contract interactions, and when simple blockchain identity with broad compatibility is needed.

#Format Specification

Where:

• [network] is optional (defaults to mainnet)
• <identifier> is an Ethereum address or public key

#Examples

• Address-based: did:ethr:0xf3beac30c498d9e26865f34fcaa57dbb935b0d74
• Key-based: did:ethr:0x0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798

#Resources

• Specification
• EIP-1056

#did:ion

The ION DID method provides high-throughput, Layer 2 decentralized identifiers on Bitcoin, enabling scalable identity systems without increasing blockchain costs.

#Technical Foundation

Implements the Sidetree protocol on Bitcoin, using batched transactions to manage many DID operations in a cost-effective manner.

#Key Features

• High throughput - Handles many operations in batched transactions
• Bitcoin security - Inherits security from the Bitcoin blockchain
• Multiple networks - Supports mainnet and testnet
• Sidetree compatibility - Works with other Sidetree implementations

#Use Cases

Use ION DIDs for production identity systems requiring high scalability, strong security, and Bitcoin's decentralization properties.

#Format Specification

Where:

• [network] is optional (mainnet or test)
• <encoded-state> is the encoded DID state

#Examples

• Mainnet: did:ion:EiClkZMDxPKqC9c-umQfTkR8vvZ9JPhl_xLDI9Nfk38w5w
• Testnet: did:ion:test:EiClWZ1MnE8PHjH6y4e4nCKgtKnI1DK1foZiP61I86b6pw

#Resources

• Microsoft ION Documentation
• Sidetree Protocol

#did:polygonid

The PolygonID DID method provides scalable identity infrastructure on the Polygon blockchain with optimized performance and cost.

#Technical Foundation

Built on the Polygon (formerly Matic) blockchain, offering Ethereum compatibility with higher throughput and lower fees.

#Key Features

• High scalability - Handles many identity operations efficiently
• Low fees - Reduces transaction costs compared to Ethereum mainnet
• Multiple networks - Supports Polygon mainnet and Mumbai testnet
• Read-only mode - Offers lightweight verification options

#Use Cases

Use PolygonID DIDs for high-volume identity applications, credential issuance at scale, and when lower transaction costs are important.

#Format Specification

Where:

• [network] is optional (main or mumbai)
• <identifier> is a base58-encoded string

#Examples

• Mainnet: did:polygonid:polygon:main:2pzr1wiBm3Qhtq137NNPPDFvdk5xwRsjDFnMxpnYHm
• Mumbai testnet: did:polygonid:polygon:mumbai:2qL4AhwQThPWJ8QH9mxH41CDgKj9chrHN92azh5wkx
• Read-only: did:polygonid:readonly:2mbH5rt9zKT1mTivFAie88onmfQtBU9RQhjNPLwFZh

#Resources

• Specification
• PolygonID Documentation

#Non-Blockchain Methods

#did:dht

The DHT DID method uses Distributed Hash Table technology for a scalable, peer-to-peer approach to DID resolution without blockchain dependencies.

#Technical Foundation

Built on Distributed Hash Table (DHT) networks, similar to those used in BitTorrent and IPFS, providing decentralized storage without consensus requirements.

#Key Features

• No blockchain required - Functions without cryptocurrency or fees
• Peer-to-peer resolution - Resolves identifiers across distributed networks
• Censorship resistance - Distributed storage prevents central points of failure
• Lightweight - More resource-efficient than blockchain-based methods

#Use Cases

Use DHT DIDs for decentralized applications requiring self-sovereign identity without blockchain dependencies, particularly in resource-constrained environments.

#Format Specification

Where:

• <identifier> is a base32-encoded hash value

#Examples

• Standard format: did:dht:1ati6y645tprnm9nkqgguj718bmtqw5mbjq87ttbrntfokekzeso

#Resources

• Specification
• DHT Overview

#did:jwk

The JWK DID method encodes a JSON Web Key directly into the identifier, enabling immediate cryptographic verification without external resolution.

#Technical Foundation

Based on JSON Web Key (JWK) standard from IETF, using cryptographic keys in a standardized JSON format as the foundation for identifiers.

#Key Features

• Self-contained - Includes verification material directly in the identifier
• No external resolution - Verifiable without network access
• Standard compatibility - Works with existing JWK infrastructure
• Key type flexibility - Supports multiple cryptographic algorithms

#Use Cases

Use JWK DIDs for lightweight verification scenarios, offline environments, and applications requiring minimal infrastructure dependency.

#Format Specification

Where:

• <base64url-encoded-jwk> is a base64url encoding of a JWK

#Examples

• Standard format: did:jwk:eyJjcnYiOiJQLTI1NiIsImt0eSI6IkVDIiwieCI6ImFjYklRaXVNczNpOF91c3pFakoydHBUdFJNNEVVM3l6OTFQSDZDZEgyVjAiLCJ5IjoiX0tjeUxqOXZXTXB0bm1LdG00NkdxRHo4d2Y3NEk1TEtncmwyR3pIM25TRSJ9

#Resources

• Specification
• JSON Web Key (JWK) RFC

#did:key

The Key DID method encodes public keys directly into the identifier, creating portable, self-contained identifiers that work without network access.

#Technical Foundation

Based on multicodec-encoded public keys, supporting various cryptographic algorithms without requiring any external infrastructure.

#Key Features

• Self-contained - Includes verification material in the identifier
• Offline verification - Functions without network connectivity
• Multiple key types - Supports ed25519, secp256k1, and other key types
• Minimal infrastructure - Requires no external systems

#Use Cases

Use Key DIDs for lightweight identity applications, offline verification scenarios, and bootstrapping more complex identity systems.

#Format Specification

Where:

• <multibase-encoded-public-key> is a multibase-encoded multicodec public key

#Examples

• Ed25519 key: did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

#Resources

• Specification
• Multicodec

#did:oyd

The Own Your Data (OYD) DID method enables self-sovereign identity management through a self-sustained environment for managing decentralized identifiers.

#Technical Foundation

Built on a self-hosted architecture that prioritizes data sovereignty, allowing individuals to maintain complete control over their identity data.

#Key Features

• Self-sovereign - Full user control without third-party dependencies
• Cryptographic verification - Standard verification methods
• Minimal infrastructure - Lightweight implementation
• Data sovereignty - Prioritizes user control of personal data

#Use Cases

Use OYD DIDs for private identity management, applications emphasizing data sovereignty, and scenarios requiring minimal external dependencies.

#Format Specification

Where:

• <identifier> is a base58-encoded value

#Examples

• Standard format: did:oyd:zQmNXp9zTLQECaLwWcXy4ctdKctnPLghHWftwdJsfGd8Erz

#Resources

• Specification
• OYD Project

#did:pkh

The PKH DID method creates identifiers from public key hashes across multiple blockchains, offering a unified interface for blockchain addresses as DIDs.

#Technical Foundation

Based on standard public key hash derivation methods used in various blockchains, creating a cross-chain identity layer.

#Key Features

• Multi-blockchain support - Works with Bitcoin, Ethereum, Tezos, Solana, and others
• Familiar addresses - Uses existing blockchain address formats
• Cross-chain compatibility - Same structure across different networks
• No additional infrastructure - Uses existing blockchain systems

#Use Cases

Use PKH DIDs to integrate existing blockchain addresses into DID ecosystems, for cross-chain identity, and when leveraging existing wallet infrastructure.

#Format Specification

Where:

• <network-identifier> specifies the blockchain network (e.g., bip122:000000000019d6689c085ae165831e93 for Bitcoin)
• <address> is the blockchain address in the native format

#Examples

• Bitcoin: did:pkh:bip122:000000000019d6689c085ae165831e93:128Lkh3S7CkDTBZ8W7BbpsN3YYizJMp8p6
• Ethereum: did:pkh:eip155:1:0xb9c5714089478a327f09197987f16f9e5d936e8a
• Tezos: did:pkh:tezos:NetXdQprcVkpaWU:tz1TzrmTBSuiVHV2VfMnGRMYvTEPCP42oSM8

#Resources

• Specification
• Supported Networks

#did:plc

The PLC DID method uses a central directory server to validate operations and maintain a transparent log for each DID, balancing decentralization with auditability.

#Technical Foundation

Based on a protocol that collects and validates operations through a central directory server, maintaining operation logs for auditability.

#Key Features

• Self-sovereign - User control over identifiers
• Transparent logs - Auditable operation history
• Central directory - For validation and discovery
• Secure updates - Cryptographically verifiable changes

#Use Cases

Use PLC DIDs for applications requiring both self-sovereign control and transparent, auditable identity operations.

#Format Specification

Where:

• <identifier> is a base32-encoded string

#Examples

• Standard format: did:plc:7iza6de2dwap2sbkpav7c6c6

#Resources

• Specification

#did:web

The Web DID method integrates decentralized identifiers with standard web infrastructure, using existing domains and HTTPS for resolution.

#Technical Foundation

Uses standard web domains and HTTPS URLs to host DID documents, leveraging existing web infrastructure for identity management.

#Key Features

• Web integration - Uses existing domains and web hosting
• Simple implementation - Standard web servers and DNS
• Path flexibility - Supports sub-paths for multiple identities
• HTTPS security - Uses standard TLS for encryption

#Use Cases

Use Web DIDs to integrate DIDs with existing web infrastructure, for organizational identities, and when simplicity of implementation is prioritized.

#Format Specification

Where:

• <domain> is a standard web domain
• <port> is optional (defaults to standard HTTPS port)
• <path> is optional for sub-identities

#Examples

• Simple domain: did:web:w3c-ccg.github.io
• With path: did:web:w3c-ccg.github.io:user:alice

#Resources

• Specification