DID Method

How a DID Method Works

A DID method is the rule set that determines how a Decentralized Identifier is created, updated, resolved, and deactivated on a particular ledger or system. In practice, the method is the bridge between the DID string a user sees and the underlying registry or network logic that makes that identifier usable.

Because methods are system-specific, they define more than syntax. They also determine which operations are valid, how changes are recorded, and what a resolver must do to obtain the current DID document, including verification material and service endpoints. That makes the method part of the trust model, not just a formatting convention.

Methods vary in how much they expose through the ledger or registry, how they represent controller authority, and how they handle key rotation or deactivation. For a reader comparing implementations, this is where the operational differences between DID ecosystems become visible, including trade-offs in decentralisation, governance, and recoverability. NHIMG’s Decentralised identifiers (DIDs) guide covers those method-level trade-offs in more depth.

DID Syntax, Resolution, and DID Documents

The DID method sits behind the DID’s persistent identifier form and the rules for resolving it into a DID document. That document is what external systems use to learn how to verify signatures, route interactions, or discover endpoints. The method therefore shapes interoperability: two DIDs can look similar at the string level while behaving very differently once resolved.

Resolution is the operational step that turns an identifier into live state. If a method is poorly designed or inconsistently implemented, a resolver may retrieve stale, incomplete, or incorrect document data. In identity workflows, that can affect authentication, verification, and service discovery, especially when relying parties assume the resolved document always reflects the current controller state.

Methods also determine how much the ledger or backing system reveals about the identifier lifecycle. Some implementations prioritise transparency and portability; others minimise on-ledger detail to reduce linkability and privacy exposure. That balance is central to how DIDs are used in real systems, including wallets and verifiable credential ecosystems. NHIMG’s Digital Identity, eID and Identity Wallets Guide is useful context for where DID methods fit in broader digital identity architectures.

Why DID Methods Matter for Trust and Interoperability

A DID method is effectively the policy boundary for a DID ecosystem. It defines who can make changes, what constitutes a valid update, and what evidence a resolver should trust. That matters because the DID document often anchors higher-value trust decisions, such as whether a verifier accepts a key, service endpoint, or controller assertion.

Interoperability depends on method semantics being understood by both issuers and verifiers. If different implementations interpret update, rotation, or deactivation rules differently, the same DID may not behave consistently across systems. That can create integration failures even when the syntax is valid and the identifier itself resolves successfully.

The method choice also influences portability and vendor or network dependence. Some methods are tightly coupled to a single ledger or governance model, while others are designed for simpler portability. For organisations, that means the method is not just an implementation detail, but a design choice that affects lifecycle control, resilience, and future migration options.

Governance and Operational Design Choices

A DID method is not useful unless someone owns its operational rules and upgrade path. The practical questions are who controls method governance, how changes are approved, and what happens when a method or registry is deprecated. Those decisions shape whether DIDs remain reliable over time, especially in ecosystems that depend on long-lived identifiers.

Method design also has privacy consequences. If resolution requests, document contents, or update patterns expose too much metadata, the method can enable correlation across interactions. Good design reduces unnecessary disclosure while still allowing verifiers to resolve the information they need.

For implementers, the central judgement is whether the method’s trust assumptions match the use case. A method that is acceptable for a low-risk pilot may be too centralised, too opaque, or too rigid for a high-assurance identity workflow. The right choice depends on how much governance, portability, and disclosure control the surrounding system needs.

Related resources from NHI Mgmt Group

• When does a phishing-resistant login method still leave organisations exposed?
• What breaks if an EUDI wallet is treated like a generic login method?
• What breaks when Java auth is added without method-level authorization?
• What breaks when banks rely on SMS OTP as the only transaction authentication method?