Choosing a DID Method for Product Data

A verifiable credential attached to a product passport is only meaningful if a verifier can establish who signed it. Decentralised Identifiers are the W3C mechanism for that, and choosing a method is one of the earlier architectural decisions a passport programme faces.

What a DID actually does

A DID is an identifier that resolves to a document listing public keys and service endpoints. When a credential is signed, the signature references the key; the verifier resolves the DID, retrieves the key and checks the signature.

The methods worth considering

The DID specification permits many methods and most are unsuitable for supply chain use for one reason or another. Four are genuinely worth evaluating.

The pattern in that table is a familiar one. The methods that need no infrastructure give up something in key management, and the methods with the strongest independence properties cost the most to run.

Why did:web is usually the right answer

did:web resolves an identifier to a document hosted at a well-known path on a domain. Control of the DID is control of the domain, which is a trust model every organisation already operates and every verifier already understands.

For a manufacturer issuing claims about its own products, that is exactly the right property. The organisation asserting the claim is the organisation that owns the brand domain, and the link between them requires no additional explanation to anybody.

• No new infrastructure — a static document served over HTTPS is the entire hosting requirement.
• Rotation is straightforward — publish a new key in the document; the identifier is unchanged.
• Failure modes are understood — DNS and TLS problems are problems operations teams already know how to handle.
• Verifiers need nothing special — resolution is an HTTPS fetch, not a ledger client.

The objection, and how much it weighs

The standard criticism of did:web is that it is not decentralised in any meaningful sense. If the domain lapses, is transferred, or is compromised, control of the identifier moves with it.

That criticism is technically correct and mostly beside the point for this use case. A manufacturer’s claims about its own products are already only as trustworthy as the manufacturer, and the domain is how the market already identifies that manufacturer.

The criticism gains force in a different scenario: long-lived claims that must remain verifiable after the issuing organisation has ceased to exist. A construction product with a fifty-year service life is a genuine example, and it argues for anchoring rather than for abandoning did:web.

Key rotation is the real design problem

Issuing a first key is easy in every method. What separates them is what happens when a key must be replaced, which will occur through routine rotation, staff departure or compromise.

The practical requirement is that a DID document retains retired keys with the period during which each was valid. Without it, every credential signed with a rotated key fails verification, which for a passport programme means every product shipped before the rotation.

A workable default

For most manufacturers the sensible position is did:web on a stable subdomain dedicated to the purpose, with retired keys retained and validity periods recorded.

Use a subdomain rather than the marketing domain, because marketing domains get restructured and an identifier that breaks when a site is redesigned is a liability. Treat the DNS record and the hosted document as production infrastructure with the change control that implies.

Where claims genuinely need to outlive the organisation, add anchoring of credential hashes rather than switching method. That addresses the durability concern directly without importing ledger operations into everyday issuance.

One further practical point is worth planning for from the start. A single organisation frequently needs more than one issuing key — separate keys per business unit, per product line, or per signing system — and a DID document accommodates that naturally by listing several verification methods.

Deciding that structure early is considerably easier than retrofitting it, because splitting one heavily used key into several later means either reissuing credentials or accepting that historic claims cannot be attributed to the unit that actually made them.