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: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
did:webvh	Web + Version Hash	Verifiable web 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

did:cheqd:[network]:<identifier>[?resourceId=<resource-identifier>]

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

`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

did:ebsi:<identifier>

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

did:ens:<ens-name>

Where:

<ens-name> is a registered ENS domain

Examples

Standard format: did:ens:mailchain.eth

Resources

`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

did:ethr:[network]:<identifier>

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

`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

did:ion:[network]:<encoded-state>

Where:

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

Examples

Mainnet: did:ion:EiAnKD8-jfdd0MDcZUjAbRgaThBrMxPTFOxcnfJhI7Ukaw:eyJkZWx0YSI6eyJwYXRjaGVzIjpbeyJhY3Rpb24iOiJyZXBsYWNlIiwiZG9jdW1lbnQiOnsicHVibGljS2V5cyI6W3siaWQiOiJzaWdfNzJiZDE2ZDYiLCJwdWJsaWNLZXlKd2siOnsiY3J2Ijoic2VjcDI1NmsxIiwia3R5IjoiRUMiLCJ4IjoiS2JfMnVOR3Nyd1VOdkh2YUNOckRGdW14VXlQTWZZd3kxNEpZZmphQUhmayIsInkiOiJhSFNDZDVEOFh0RUxvSXBpN1A5eDV1cXBpeEVxNmJDenQ0QldvUVk1UUFRIn0sInB1cnBvc2VzIjpbImF1dGhlbnRpY2F0aW9uIiwiYXNzZXJ0aW9uTWV0aG9kIl0sInR5cGUiOiJFY2RzYVNlY3AyNTZrMVZlcmlmaWNhdGlvbktleTIwMTkifV0sInNlcnZpY2VzIjpbeyJpZCI6ImxpbmtlZGRvbWFpbnMiLCJzZXJ2aWNlRW5kcG9pbnQiOnsib3JpZ2lucyI6WyJodHRwczovL3d3dy52Y3NhdG9zaGkuY29tLyJdfSwidHlwZSI6IkxpbmtlZERvbWFpbnMifV19fV0sInVwZGF0ZUNvbW1pdG1lbnQiOiJFaUR4SWxJak9xQk5NTGZjdzZndWpHNEdFVDM3UjBIRWM2Z20xclNZTjlMOF9RIn0sInN1ZmZpeERhdGEiOnsiZGVsdGFIYXNoIjoiRWlBLXV3TWo3RVFheURmWTRJS3pfSE9LdmJZQ05td19Tb1lhUmhOcWhFSWhudyIsInJlY292ZXJ5Q29tbWl0bWVudCI6IkVpQ0czQ1M5RFJpeU1JRVoxRl9sSjZnRVRMZWVHREwzZnpuQUViMVRGdFZXNEEifX0

Resources

`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

did:polygonid:polygon:[network]:<identifier>

Where:

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

Examples

Mainnet: did:polygonid:polygon:main:2pzr1wiBm3Qhtq137NNPPDFvdk5xwRsjDFnMxpnYHm

Resources

Non-Blockchain Methods

`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

did:jwk:<base64url-encoded-jwk>

Where:

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

Examples

Standard format: did:jwk:eyJjcnYiOiJQLTI1NiIsImt0eSI6IkVDIiwieCI6ImFjYklRaXVNczNpOF91c3pFakoydHBUdFJNNEVVM3l6OTFQSDZDZEgyVjAiLCJ5IjoiX0tjeUxqOXZXTXB0bm1LdG00NkdxRHo4d2Y3NEk1TEtncmwyR3pIM25TRSJ9

Resources

`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

did:key:<multibase-encoded-public-key>

Where:

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

Examples

Ed25519 key: did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

Resources

`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

did:oyd:<identifier>

Where:

<identifier> is a base58-encoded value

Examples

Standard format: did:oyd:zQmNXp9zTLQECaLwWcXy4ctdKctnPLghHWftwdJsfGd8Erz

Resources

`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

did:pkh:<network-identifier>:<address>

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

`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

did:plc:<identifier>

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

did:web:<domain>[:<port>][/<path>]

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

`did:webvh`

The WebVH DID method enhances web-based DIDs with version history and content integrity verification through cryptographic hashes.

Technical Foundation

Builds upon the Web DID method by adding version history tracking and content integrity verification using cryptographic hashes, enabling verifiable web-based identities.

Key Features

Version history - Maintains cryptographic history of DID document changes
Content integrity - Verifies document content through hash validation
Web integration - Compatible with existing web infrastructure
Backward compatibility - Works with standard web DID infrastructure

Use Cases

Use WebVH DIDs when you need web-based identities with verifiable version history, content integrity guarantees, and auditable document changes over time.

Format Specification

did:webvh:<hash>:<domain>[:<port>][/<path>]

Where:

<hash> is a cryptographic hash for version identification
<domain> is a standard web domain
<port> is optional (defaults to standard HTTPS port)
<path> is optional for sub-identities

Examples

With GitHub Gist: did:webvh:QmPEQVM1JPTyrvEgBcDXwjK4TeyLGSX1PxjgyeAisdWM1p:gist.githubusercontent.com:brianorwhatever:9c4633d18eb644f7a47f93a802691626:raw
Standard domain: did:webvh:QmVJ5nUYb9iugnUz4yDfbe8UFbhmnsvS2EAzSpSfPScRAn:opsecid.github.io

Resources

Specification