What is a DID method?

A DID method is the specification that defines how a specific type of decentralized identifier is created, resolved, updated, and deactivated. It is named in the identifier itself, for example the web part of did:web or the key part of did:key. W3C DID Core requires every method to specify those four operations.

Which DID method should I use?

For most enterprise issuers, did:web is the pragmatic default: it anchors to a domain you already control over HTTPS, needs no blockchain, and is widely supported. If you need an auditable key history, look at did:webvh. Use did:key or did:jwk for short-lived or holder-side identifiers. Use ledger-anchored methods only when you specifically need decentralization that does not depend on DNS, or when your ecosystem mandates one.

Do DID methods require a blockchain?

No. Ledgerless methods like did:web, did:webvh, did:key, and did:jwk use no blockchain at all. Only ledger-anchored methods such as did:ion, did:ethr, and did:indy rely on a distributed ledger. did:plc uses a directory server operated by Bluesky rather than a blockchain.

Can I support more than one DID method?

Yes, and verifiers often must, because they receive credentials from issuers using different methods. The practical constraint is that your resolver and libraries support every method you need to verify, and that you set a trust policy for each one.

Is did:ion still used?

Its best-known enterprise deployment ended. Microsoft Entra Verified ID supported did:ion only in preview until December 2023 and now uses did:web, and its documentation tells tenants that moving from did:ion to did:web requires reissuing all credentials. Check whether your ecosystem still requires it before choosing it.

What is the status of the DID standard?

DID Core 1.0 has been a W3C Recommendation since 19 July 2022. DID Core 1.1 was published as a W3C Candidate Recommendation Snapshot on 5 March 2026. Individual methods such as did:web and did:key are separate specifications with their own maturity levels.

DID Methods Compared: did:web, did:key, did:ion and More

The method in a decentralized identifier decides how it is created, resolved, rotated, and retired, and that choice has operational consequences for years. The short answer: use did:web for organizational issuers, did:webvh if you need a verifiable key history, did:key or did:jwk for ephemeral and holder-side identifiers, and ledger methods only when an ecosystem requires them. This guide shows why. For the standard, see the DID standard deep dive and the DID method glossary entry.

What a method has to define

DID Core 1.0 became a W3C Recommendation on 19 July 2022, and DID Core 1.1 reached Candidate Recommendation Snapshot on 5 March 2026. Both leave the mechanics to method specifications, which must define four operations: create, resolve, update, and deactivate. Resolution itself is specified separately in W3C DID Resolution, and methods are listed in the W3C DID Extensions registry. When you compare methods, compare those four operations, plus two things the core spec does not force: whether you get a history of past keys, and who can censor or tamper with resolution.

The comparison

Method	Anchored in	Create	Rotate keys	Deactivate	Verifiable history	Spec maturity
`did:web`	Your domain over HTTPS	Host a file	Edit the file	Remove the file	No	W3C CCG proposal
`did:webvh`	Your domain, plus a hash-chained log	Host a log	Append signed entry	Append entry	Yes	DIF v1.0
`did:key`	The identifier itself	Generate a key	Not possible	Not possible	Not applicable	v0.9 draft
`did:jwk`	The identifier itself	Encode a JWK	Not possible	Not possible	Not applicable	Community spec
`did:ion`	Bitcoin via Sidetree	Anchored operation	Yes	Yes	Yes	DIF Sidetree-based
`did:ethr`	Ethereum registry (ERC-1056)	Free, any address	On-chain transaction	On-chain transaction	Yes, via events	DIF community spec
`did:indy`	Hyperledger Indy ledger	Permissioned write	Ledger write	Ledger write	Yes	Hyperledger spec
`did:plc`	Bluesky-operated directory	Signed genesis op	Signed op	Tombstone op	Yes, public log	Bluesky spec

Ledgerless methods

did:web anchors a DID to a domain. Per the did:web specification, did:web:example.com resolves to https://example.com/.well-known/did.json, colons after the domain become path segments (did:web:example.com:issuers:hr resolves to https://example.com/issuers/hr/did.json), and a port is percent-encoded (example.com%3A3000). It reuses the TLS and DNS trust you already operate, which is why it is the most common enterprise choice. The specification is candid about the costs: it defines no mechanism to control who can write the DID document, so it is only as secure as your web hosting; DNS spoofing is a risk without DNSSEC; your web server can see every resolution, which is a privacy leak for verifiers; and there is no history, so a verifier cannot check which key was valid when an old credential was signed. The spec suggests keeping the document in version control as a workaround.

did:webvh ("did:web plus verifiable history") fixes that last gap. The DIF did:webvh v1.0 specification publishes a did.jsonl log at the same location, where every entry carries a version, timestamp, parameters, the document state, and a proof, each chained to its predecessor by hash. A self-certifying identifier (SCID) derived from the first entry is embedded in the DID, so a resolver can detect a rewritten history. Optional pre-rotation publishes hashes of the next keys, and optional witnesses must co-sign updates. It is the strongest option for an issuer that wants web hosting without losing auditability.

did:key encodes a public key directly into the identifier. The did:key v0.9 specification combines a multicodec key-type prefix with the raw key bytes and multibase-encodes them, which is why Ed25519 keys start with did:key:z6Mk and P-256 keys with did:key:zDna. Resolution needs no network at all. The specification states that a did:key cannot be updated or deactivated, recommends against long-term use unless the key is protected in a hardware security module, and treats rotation as issuing a new identifier. Ideal for holders, test environments, and short-lived sessions.

did:jwk does the same with a JSON Web Key: the identifier is did:jwk: plus the base64url-encoded JWK, the single verification method is always #0, and the specification does not support update. It is convenient in JOSE and SD-JWT stacks where keys are already JWKs.

Ledger and registry methods

did:ion anchors batched operations to Bitcoin using the Sidetree protocol, giving decentralization without a per-operation chain fee. Microsoft, once its best-known enterprise backer, moved away: the Microsoft Entra Verified ID FAQ says did:ion was supported only in preview until December 2023, and that moving to did:web "requires reissuance of all credentials." That is the general lesson: changing method later means reissuing. See Microsoft Entra Verified ID.

did:ethr uses the ERC-1056 registry contract. Per its method specification, any Ethereum address or secp256k1 public key is already a valid DID with no transaction fee for creation, but changing the owner, adding delegates, or setting attributes requires an on-chain transaction that costs gas (meta-transactions let a third party pay). It supports Ethereum mainnet, Sepolia, Polygon, Gnosis Chain, and other EVM chains. It fits Web3-adjacent ecosystems.

did:indy is the method for Hyperledger Indy networks, where writes go through a permissioned ledger with governance-defined roles. It is usually paired with AnonCreds and the Hyperledger Indy and Aries stack. Choose it when you join an Indy-based network; it ties you to that network's governance.

did:plc is the method behind Bluesky and the AT Protocol. The did:plc specification describes a directory at plc.directory run by Bluesky Social PBC, controlled by an ordered list of one to five rotation keys, with a public, timestamped log of every operation and a 72-hour window in which a higher-priority key can override recent changes, which gives account recovery. The spec says Bluesky would like to move governance out of its sole control, but that has not happened yet. It shows a practical middle path: a central operator that cannot forge operations, because every operation is signed.

How to choose

Work from constraints, not novelty:

Are you an organization issuing credentials? Start with did:web. Move to did:webvh if auditors or verifiers need to know which key was valid at a past date.
Is the identifier ephemeral or holder-side? did:key or did:jwk.
Are you joining an existing ecosystem (an EU wallet program, an Indy network, a Web3 project, AT Protocol)? Use what the ecosystem specifies; interoperability beats preference.
Do you need resolution that survives losing your domain? Only then consider a ledger method, and price in the operational cost.
As a verifier, support every method your issuers use, gated by what your resolver handles, and keep a policy per method (for example, did:web only from domains on your trust registry).

Common pitfalls

Letting the domain lapse. A did:web issuer whose domain expires can be impersonated by whoever registers it next. Treat the domain like a root key.
Using did:key for a long-lived issuer. You cannot rotate it, so a key compromise means every credential must be reissued under a new DID.
Assuming the method gives revocation. It does not. Credential revocation is a separate layer, typically the W3C Bitstring Status List, a Recommendation since 15 May 2025. See revocation registry.
Forgetting resolution privacy. Every did:web resolution is a request to the issuer's server. Verifiers at scale should cache documents or use their own resolver.

Where to go next

Build: verifiable credentials implementation guide. Overview: decentralized identity explained and decentralized vs federated identity. Vendors: decentralized identity directory and choosing a decentralized identity platform.