DID Methods

info

Please note that this content is under development and is not ready for implementation. This status message will be updated as content development progresses.

Overview

The UNTP supports the use of decentralized identifiers (DIDs) to uniquely and verifiably represent organizations, facilities, products, and other actors across global supply chains. These identifiers form the foundation for establishing Digital Identity Anchors (DIAs), resolving linksets via a Identity Resolver, and verifying credential issuers and holders.

The W3C DID Core specification allows for a broad range of DID methods, many of which are registered in the W3C DID Extensions - DID Methods registry. However, not all methods offer equivalent levels of verifiability, governance assurance, or operational fit for the UNTP's trust model. It is reasonable to expect that this proliferation of DID methods will consolidate to a much smaller number of methods, each designed to meet specific business needs.

This specification defines guidance on the use of different DID methods within UNTP implementations and extensions. Different DID methods introduce different assumptions about trust anchors, resolution mechanisms, and control guarantees. Some methods rely solely on DNS and HTTPS infrastructure; others incorporate explicit proofs, registries, or governance contracts to strengthen control verification. In UNTP, the choice of DID method directly impacts the integrity of identity resolution and the downstream reliability of linked credentials and services.

This guidance supports implementers in selecting DID methods that align with the UNTP's goals of transparency, decentralization, and verifiability while also providing a foundation for consistent resolver behavior across the ecosystem. As the specification evolves, additional methods may be assessed and incorporated through working group consensus, taking into account the ongoing evolution of the DID method landscape reflected in the W3C DID Extensions - DID Methods registry.

Acknowledged DID Methods

The following DID methods are acknowledged by the UNTP specification as having been assessed for their suitability, governance characteristics, and alignment with UNTP requirements. A method is "acknowledged" when it has been evaluated by the UNTP working group and determined to offer appropriate levels of verifiability, governance assurance, or operational fit for specific UNTP use cases.

The list of acknowledged methods, their implementation requirements, and status recommendations are subject to ongoing evaluation and revision as the UNTP specification evolves. As new DID methods emerge, mature, or demonstrate enhanced capabilities, they may be added to this list through working group consensus. Similarly, requirements and guidance for existing methods may be updated based on implementation experience and ecosystem developments.

did:web

The did:web method enables identifiers to be derived from domain names and resolved via well-known HTTPS endpoints. It is widely supported and simple to implement, relying on the existing DNS and TLS infrastructure to bind identifiers to hosting environments.

Within the UNTP framework, did:web offers a pragmatic entry point for identity publication and resolution. Its structure is compatible with the Digital Identity Anchor model, and can be used to expose service endpoints, credential metadata, and other linkable assets.

However, did:web relies on implicit trust in domain ownership and HTTPS hosting. It does not, by itself, provide strong or auditable guarantees of control — particularly in shared hosting environments, federated platforms, or supply chains involving resellers and intermediaries. Its use is sensitive to domain expiration, certificate mismanagement, and untracked delegation.

UNTP implementations MAY use did:web where simplicity and broad interoperability are prioritized, and where trust in domain ownership is independently verified.

Implementation Requirements for did:web

A conformant UNTP implementation:

• MUST implement the did:web method as an Organizational Identifier
• SHOULD implement the did:web method using the web domain of the issuer to avoid portability challenges

Field	Description
Method Name	did:web
Identifier Syntax	did:web:<domain> or did:web:<domain>:<path>.
Status	✅ Recommended — widely interoperable and suitable for institutional and organizational identifiers.
Governance / Issuing Organisation	W3C-registered DID method maintained by the Decentralized Identity Foundation (DIF) and the W3C community.
Resolver(s) / Resolution Endpoint(s)	Well-known HTTPS endpoints (typically /.well-known/did.json or /did.json), resolved via DNS and TLS infrastructure.
Use Case(s) in UNTP	Organizational identifiers, Digital Identity Anchors, identity publication and resolution. Compatible with exposing service endpoints, credential metadata, and other linkable assets. Suitable where simplicity and broad interoperability are prioritized.
Advantages / Key Features	Widely supported and simple to implement. Relies on existing DNS and TLS infrastructure, making it accessible and easy to adopt. Compatible with the Digital Identity Anchor model. Provides a pragmatic entry point for identity publication and resolution.
Known limitations or considerations	Relies on implicit trust in domain ownership and HTTPS hosting. Does not provide strong or auditable guarantees of control, particularly in shared hosting environments, federated platforms, or supply chains involving resellers and intermediaries. Sensitive to domain expiration, certificate mismanagement, and untracked delegation.
Implementation Notes	MUST be implemented as an Organizational Identifier. SHOULD be implemented using the web domain of the issuer to avoid portability challenges. Requires independent verification of domain ownership.
Remarks	Entry point for identity publication and resolution within the UNTP framework. Suitable for institutional and organizational identifiers where trust in domain ownership is independently verified.

did:webvh

The did:webvh method extends the widely used did:web approach by introducing verifiable history, enabling tamper-evident tracking of identifier updates over time. It allows organizations to maintain a cryptographically linked log of key rotations, control changes, and migrations across domains, providing strong assurances of authenticity and continuity.

Within the UNTP, did:webvh is recommended for institutional and organizational identifiers where auditability, long-term trust, and accountability are required, such as Digital Identity Anchors, credential issuers, or registry maintainers. While it retains the accessibility of web-based publishing via HTTPS, it adds a transparent, verifiable chain of control that aligns with UNTP’s principles of traceability, integrity, and transparency.

Field	Description
Method Name	did:webvh
Identifier Syntax	did:webvh:<domain> or did:webvh:<domain>:<path>. Resolved via HTTPS to a did.jsonl (JSON Lines) file containing a verifiable chain of DID document versions.
Status	✅ Recommended (Advanced) — suitable for institutional, organizational, and delegated identifiers requiring verifiable history, key rotation, and auditability.
Governance / Issuing Organisation	Maintained by the Decentralized Identity Foundation (DIF) as an extension of the W3C-registered did:web method. Defined in the DIF DID Web Verifiable History specification.
Resolver(s) / Resolution Endpoint(s)	HTTPS endpoints hosting a did.jsonl log file, typically located at /.well-known/did.jsonl or a specified path under the domain. Resolution involves verifying a chain of cryptographically linked versions (previousVersionHash + proof) to produce a tamper-evident DID Document history.
Use Case(s) in UNTP	Recommended for Digital Identity Anchors and institutional identifiers requiring auditability, traceability, and long-term trust. Enables transparent verification of key rotations, ownership transfers, and historical control of identities within supply chains. Supports continuity of identity even when domains change, ensuring transparent migration records for verifiable data sources.
Advantages / Key Features	Extends did:web with verifiable, append-only history of updates. Enables tamper-evident key rotation, continuity of trust, and portability between domains. Provides an immutable audit trail of identifier control, supporting UNTP principles of transparency and accountability. Backward compatible with existing did:web resolvers when version history is ignored.
Known Limitations or Considerations	Still relies on HTTPS hosting and DNS domain ownership; subject to availability and correct domain management. Implementation is more complex due to the requirement to maintain and publish a valid did.jsonl chain. Requires careful management of key rotation and chain integrity. Historical transparency may expose metadata about operational changes — privacy implications should be assessed per use case.
Implementation Notes	MUST be implemented where auditability of identity control is required (e.g., accredited data publishers, credential issuers). SHOULD maintain the did.jsonl file with proper version linking and proofs (previousVersionHash and proof). Implementers SHOULD plan for domain portability using the alsoKnownAs and newDomain parameters. Supports pre-rotation and witness confirmation for resilience.
Remarks	Provides a tamper-evident, verifiable history of identity updates aligned with UNTP’s principles of transparency and accountability. Recommended where traceability and provenance of identity control are important — for example, in managing registries, conformance issuers, or long-lived supply chain identifiers. Offers a bridge between web-based and verifiable, history-aware identity ecosystems.

Future Roadmap

Future versions of this specification will:

• Provide richer guidance on DID methods via a decision tree that helps to select the right method for the right purpose
• Address the proliferation of DID methods and their consolidation to meet specific business needs
• Provide guidance for different use cases (e.g., legal entities vs products)

Registry Template

Field	Description
Method Name	...
Identifier Syntax	...
Status	...
Governance / Issuing Organisation	...
Resolver(s) / Resolution Endpoint(s)	...
Use Case(s) in UNTP	...
Advantages / Key Features	...
Known limitations or considerations	...
Implementation Notes	...
Remarks	...