Start with Identity
Subscribe
← Guides
Decentralized Identity · Advanced

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

By SWI Community Team · Updated 2026-07-06 · 9 min

The method in a decentralized identifier determines how it is created and resolved, and the choice has real operational consequences. This guide compares the methods that matter in production so you can pick one without over-engineering. For the standard itself, see the DID standard deep dive and the DID method glossary entry.

Two families

DID methods split into two camps:

  • Ledgerless: resolution uses ordinary infrastructure (DNS, HTTPS, or the identifier itself). Simple to operate, no blockchain.
  • Ledger-anchored: resolution uses a distributed ledger, adding decentralization independent of any single domain or provider, at the cost of ledger dependency, governance, and sometimes fees.

The methods that matter

did:web anchors a DID to a domain by hosting the DID document at a well-known HTTPS path. It reuses the TLS and DNS trust you already run, needs no ledger, and is the most common enterprise choice. The tradeoff: it inherits DNS and domain-control assumptions, so it is only as decentralized as your domain.

did:key encodes a public key directly in the identifier, so it is fully self-contained with no network lookup. Ideal for ephemeral or holder-side identifiers and testing. The tradeoff: no rotation or service endpoints, because there is nothing to update.

did:jwk is similar to did:key but wraps a JWK, convenient in JWT-heavy stacks.

did:ion anchors to Bitcoin via the Sidetree protocol, giving strong decentralization without per-operation on-chain cost. The tradeoff: more moving parts and reliance on the ION network.

did:ethr anchors to Ethereum, common in Web3-adjacent ecosystems. The tradeoff: chain dependency and gas considerations.

did:indy is used in Hyperledger Indy ecosystems, often paired with AnonCreds credentials. The tradeoff: it ties you to that ecosystem's governance and ledger.

How to choose

Work from constraints, not novelty:

  1. Do you need decentralization independent of DNS? If no, did:web is almost always right.
  2. Is the identifier ephemeral or holder-side? did:key fits.
  3. Are you joining an existing ecosystem (an EU pilot, a Hyperledger network, a Web3 project)? Use the method that ecosystem standardizes on.
  4. As a verifier, support every method your issuers use, gated by what your resolver and libraries handle.

For most organizations issuing or accepting credentials, the answer is did:web for issuers and whatever the wallets use for holders, with ledger methods added only when a concrete requirement demands them.

Where to go next

Build: verifiable credentials implementation guide. Overview: decentralized identity explained. Vendors: decentralized identity directory.

Frequently asked questions

What is a DID method?
A DID method is the scheme 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 ion part of did:ion.
Which DID method should I use?
For most enterprises, did:web is the pragmatic default: it anchors to a domain you already control over HTTPS, needs no blockchain, and is widely supported. Use ledger-anchored methods only when you specifically need decentralization that does not depend on DNS.
Do DID methods require a blockchain?
No. Ledgerless methods like did:web and did:key use no blockchain at all. Only ledger-anchored methods such as did:ion, did:ethr, and did:indy rely on a distributed ledger.
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.