Web 7.0 Foundation

Bindloss Alberta Canada mwherman@gmail.com https://hyperonomy.com/about/

Applications and Real-Time Decentralized Identifiers DID URN Decentralized Identifier Decentralized Universal Resource Name URN did7:web7 identity This document specifies the did7:web7 Decentralized Identifier (DID) method, which defines a deterministic mapping from Uniform Resource Names (URNs) (RFC 8141) into a DID-compatible identifier format called a Decentralized Universal Resource Name (URN). The did7:web7 method preserves URN semantics, enables DID resolution without mandatory centralized infrastructure, and provides optional cryptographic and service-layer extensibility. The method is fully compatible with the W3C DID Core specification (W3C DID Core, 2022) and the broader DID ecosystem. This Internet-Draft is derived from the Web 7.0 Foundation specification "SDO: W3C Decentralized Resource Name (URN) DID Method (Web 7.0)" authored by Michael Herman, published 24 March 2026 at https://hyperonomy.com/2026/03/24/ sdo-web-7-0-decentralized-resource-name-urn-did-method/ and licensed under the Creative Commons Attribution-ShareAlike 4.0 International Public License. Web 7.0(TM), Web 7.0 DIDLibOS(TM), TDW AgenticOS(TM), TDW(TM), Trusted Digital Web(TM), and Hyperonomy(TM) are trademarks of the Web 7.0 Foundation. All Rights Reserved.

Introduction Uniform Resource Names (URNs) provide a well-established mechanism for assigning persistent, location-independent identifiers to resources. However, URNs predate the Decentralized Identifier (DID) ecosystem and lack native support for DID resolution, DID Document retrieval, cryptographic verification methods, or service endpoint declaration. At the same time, many existing information systems such as bibliographic catalogues, digital libraries, standards registries, and supply-chain systems rely heavily on URN-based identification. Retrofitting these systems with entirely new identifier schemes is often impractical. The did7:web7 method bridges this gap. It defines a deterministic, reversible transformation from any well-formed URN into a DID-compatible identifier called a Decentralized Universal Resource Name (URN). The resulting DID is fully resolvable, is backwards compatible with the source URN, requires no mandatory centralized registry, and is composable with other DID methods such as did:key, did:web, and did:peer. The primary design goals of did7:web7 are:

• Preservation of URN semantics and namespace-specific comparison rules.
• Deterministic, stateless baseline resolution requiring no external infrastructure.
• Optional cryptographic extensibility through verification methods.
• Optional service-layer extensibility through service endpoints.
• Full conformance with the W3C DID Core specification .

The did7:web7 method is positioned as a universal adapter between the URN and DID ecosystems, serving as a semantic identity bridge that preserves existing meaning while enabling participation in the modern decentralized identity landscape.

Conventions and Definitions The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals as shown here. ABNF notation used in this document follows .

Terminology

URN (Uniform Resource Name):

A persistent, location-independent identifier conforming to the syntax defined in , of the form urn:<NID>:<NSS>.

NID (Namespace Identifier):

The registered URN namespace label (e.g., isbn, uuid, ietf).

NSS (Namespace-Specific String):

The portion of a URN following the NID, interpreted according to the rules of the corresponding URN namespace registration.

URN (Decentralized Universal Resource Name):

A URN expressed within the did7:web7 method namespace; the method-specific identifier portion of a did7:web7 DID.

DID Document:

A set of data describing the DID subject, as defined in Section 5 of .

Resolver:

A software component that, given a DID, returns a DID Document conforming to the requirements of .

Controller:

An entity, as identified by a DID, that has the capability to make changes to a DID Document, as defined in .

Fingerprint:

A cryptographic hash of a canonical representation of the embedded URN, used to derive a did:key-compatible equivalent identifier.

Method Name The method name that identifies this DID method is: urn. A DID conforming to this specification begins with the prefix did7://web7/. This prefix is case-insensitive for resolution purposes, but implementations SHOULD produce lowercase prefixes in all output.

Method-Specific Identifier

Syntax The ABNF grammar for a did7:web7 DID is as follows: NSS = ]]> The following are conformant examples of did7:web7 identifiers:

Normalization Implementations MUST normalize the embedded URN according to the lexical equivalence and case-folding rules specified in Section 3.1 of before constructing or comparing a did7:web7 identifier. Namespace-specific comparison rules (q-component handling, etc.) as registered with IANA for each NID MUST also be preserved. Percent-encoding normalization (Section 2.1 of ) applies to the NSS component where permitted by the applicable namespace registration.

Core Properties

Determinism A given URN MUST map deterministically to exactly one did7:web7 identifier. The transformation is purely syntactic; no randomness or external state is introduced. Two URNs that are lexically equivalent per MUST produce the same did7:web7.

Reversibility The original URN MUST be exactly recoverable from the did7:web7 identifier without loss of information. No encoding, hashing, or irreversible transformation is applied to the URN content.

Infrastructure Independence Baseline resolution of a did7:web7 identifier MUST NOT require access to any centralized registry, distributed ledger, or network service. A conformant resolver MUST be capable of constructing a minimal conformant DID Document entirely from the information contained within the DID string itself (see Mode 1, ).

DID Resolution

Resolution Input The resolution input is a did7:web7 string conforming to the syntax defined in , optionally accompanied by resolution options as defined in . ]]>

Resolution Output A conforming resolver MUST return a DID Document. The minimum conformant DID Document for any did7:web7 identifier is: The alsoKnownAs property MUST contain the embedded URN in its normalized form (per ).

Resolution Modes

Mode 1 - Stateless Resolution (REQUIRED) A conformant resolver MUST support stateless resolution. In this mode the resolver constructs the DID Document locally from the DID string alone, without any external network lookup. Properties of this mode:

• Fully deterministic.
• Zero infrastructure dependency.
• Always available regardless of network connectivity.

Mode 2 - Deterministic Fingerprint (RECOMMENDED) Resolvers SHOULD support derivation of a cryptographic fingerprint from the canonical URN. The fingerprint is derived as: where canonical-urn is the normalized URN string (UTF-8 encoded) and hash is a cryptographic hash function registered for use with did:key (e.g., SHA-256 with multibase encoding ). The derived fingerprint SHOULD be expressed as a did:key identifier and added to the DID Document as follows: " ] ]]>

Mode 3 - Discovery-Enhanced Resolution (OPTIONAL) Resolvers MAY perform external discovery to supplement the locally constructed DID Document. Permitted discovery mechanisms include:

• DNS-based lookup (e.g., using the DNS-SD mechanism).
• HTTPS well-known endpoints (e.g., /.well-known/did.json).
• Content-addressed storage systems (e.g., IPFS).

Discovery rules SHOULD be namespace-aware, such that a resolver for urn:isbn: DIDs may apply different discovery heuristics than one for urn:uuid: DIDs. When external discovery yields a DID Document, that document MUST be validated for consistency with the locally constructed baseline document before being returned to the caller. Specifically, the id and alsoKnownAs values MUST match the baseline.

DID Document Structure

Base Document Every DID Document produced by a did7:web7 resolver MUST conform to the following template: ", "alsoKnownAs": [""] } ]]> Where <urn> is the normalized URN as defined in .

Optional Properties

Verification Methods A DID Document MAY include one or more verification method entries to support cryptographic operations associated with the identified resource. The following is an example using the Ed25519VerificationKey2020 type: #key-1", "type": "Ed25519VerificationKey2020", "controller": "did7://web7/", "publicKeyMultibase": "z6Mk..." } ] ]]> Verification methods MUST conform to Section 5.2 of .

Service Endpoints A DID Document MAY include service endpoint entries to enable discovery of resources or services associated with the URN. The following is an illustrative example: #resource", "type": "URNResourceService", "serviceEndpoint": "https://example.com/urn/" } ] ]]> Service endpoints MUST conform to Section 5.4 of . The type value SHOULD be registered in a publicly accessible DID Specification Registries entry .

Equivalent Identifier Where Mode 2 resolution () is supported, the DID Document MAY include an equivalentId property expressing the deterministic fingerprint-derived did:key as described in .

Controller Model

Default Behaviour A did7:web7 identifier does not inherently assert or imply a controller. In the baseline stateless resolution mode (Mode 1), the DID Document contains no controller property. The absence of a controller property indicates that control has not been established through this mechanism.

Establishing Control Control over a did7:web7 DID Document MAY be asserted through any of the following mechanisms:

• Verifiable Credentials binding a controller identity to the URN.
• Signed DID Documents, where the document is signed by a verification method under the controller's authority.
• Namespace authority attestations, where the registrant or maintainer of the relevant URN namespace asserts controller status.

When a controller is established, the controller property MUST be included in the DID Document and MUST reference a resolvable DID.

Verification and Trust The did7:web7 method does not inherently provide authenticity guarantees. A DID Document produced by a stateless resolver (Mode 1) is constructed locally and carries no cryptographic proof of its origin or integrity. Implementations that require trust assurances SHOULD layer one or more of the following mechanisms on top of the baseline:

• Cryptographic proofs: Attach verification methods and associated proofs (e.g., JSON-LD Proofs, JOSE signatures) to the DID Document as described in .
• Third-party attestations: Bind Verifiable Credentials from trusted issuers to the URN to assert provenance, authenticity, or ownership.
• Namespace authority validation: Dereference the URN through its canonical namespace registry to verify that the identified resource exists and that any asserted attributes are consistent.

Consumers of did7:web7 DID Documents SHOULD NOT infer trustworthiness solely from the presence of the DID; trust evaluation MUST take into account the verification mechanisms present in the DID Document and the verifier's trust policy.

CRUD Operations The did7:web7 method supports the following subset of CRUD operations as defined in :

Operation	Status	Notes
Create	Implicit	A URN is created implicitly by forming the syntactic transformation of a well-formed URN per . No registration step is required.
Read	REQUIRED	Resolution MUST be supported in at least Mode 1 (stateless), per .
Update	NOT SUPPORTED	The baseline stateless method does not support document updates. Updates are only possible in Mode 3 via an external discovery service that supports document management.
Deactivate	NOT SUPPORTED	Deactivation is not supported in the baseline method. External service layers may implement deactivation semantics independently.

Interoperability

With URN Systems The did7:web7 method is fully backward compatible with existing URN infrastructure. The embedded URN is preserved verbatim (after normalization) within the DID string, and no changes to existing URN registries, resolvers, or applications are required. The alsoKnownAs property in the DID Document ensures that a did7:web7 DID can always be mapped back to its source URN, enabling interoperability with legacy systems that do not support DID resolution.

With the DID Ecosystem The did7:web7 method is compatible with the W3C DID Core specification and the DID Resolution specification . It is composable with the following DID methods:

• did:key - via the deterministic fingerprint mechanism ().
• did:web - a did7:web7 DID Document MAY reference a did:web service endpoint for resource discovery.
• did:peer - pairwise did:peer identifiers MAY be used in conjunction with did7:web7 to reduce correlation in privacy-sensitive contexts (see ).

Implementations MAY register additional DID method compositions in a publicly accessible DID Method Registry.

Design Rationale The following design decisions underpin the did7:web7 specification. Deterministic mapping: Aligning with the broader principle that DID methods SHOULD be deterministic where possible, the syntactic transformation from URN to URN requires no external state and produces stable, reproducible identifiers. Use of alsoKnownAs: The alsoKnownAs property from is used rather than a custom extension to ensure semantic preservation while remaining fully conformant with the core specification. Stateless baseline: Requiring only syntactic processing for baseline resolution maximises portability and eliminates single points of failure that would arise from mandatory registry dependencies. Acknowledged trade-offs: The method does not include a built-in trust layer or lifecycle operations (Update/Deactivate) at the baseline level. These capabilities are intentionally delegated to optional layers (Modes 2 and 3, and the controller model of ) so that implementations may adopt only the complexity they require.

Privacy Considerations

Correlation Risks The deterministic mapping from URN to URN means that any party who observes a did7:web7 identifier can immediately recover the underlying URN. Where the URN encodes personally identifiable information (e.g., a personal UUID or a registry identifier linked to an individual), this creates a direct correlation vector. Additionally, because the transformation is deterministic and publicly known, two parties who independently resolve the same URN will arrive at the same URN, enabling linkage across otherwise unrelated contexts.

Mitigations Implementers handling sensitive or personal identifiers SHOULD consider the following mitigations:

• Pairwise DIDs: Use pairwise did:peer identifiers in contexts where individual interaction tracking is a concern, rather than exposing the did7:web7 identifier directly.
• Avoid sensitive URNs: Refrain from forming did7:web7 identifiers from URNs that encode sensitive personal data in public or semi-public contexts.
• Selective disclosure: Where verification is required, use Verifiable Presentations with selective disclosure rather than directly sharing the did7:web7 identifier.

This document does not address the privacy properties of the underlying URN namespaces; implementers MUST consult the privacy considerations of the applicable namespace registration before using that namespace in a did7:web7 context.

Security Considerations

Limitations The baseline did7:web7 method (Mode 1) provides no inherent proof-of-control. Any party can construct a syntactically valid did7:web7 DID from any well-formed URN without demonstrating authority over the named resource. This is an intentional consequence of the zero-infrastructure design; however, it means that a did7:web7 DID alone cannot be used to assert ownership or authority. In Mode 3 (Discovery-Enhanced), resolvers that accept DID Documents from external services are susceptible to spoofed or tampered service endpoints. A malicious service could return a crafted DID Document containing false verification methods or service endpoints.

Recommendations To mitigate the limitations identified above, implementations SHOULD apply the following measures:

• Signed metadata: Require that DID Documents obtained via Mode 3 discovery carry a valid cryptographic proof (e.g., a JSON-LD Data Integrity Proof) before accepting them as authoritative.
• Verifiable Credentials for binding: Use Verifiable Credentials issued by a trusted authority to bind the URN to a controller identity, rather than relying solely on the DID Document structure.
• TLS for discovery endpoints: All HTTPS endpoints used in Mode 3 discovery MUST be protected with TLS 1.2 or higher and SHOULD use certificate transparency.
• Input validation: Resolvers MUST validate the embedded URN against the ABNF grammar of before performing any resolution activity.

IANA Considerations This document requests registration of the following DID method name in the W3C DID Specification Registries :

Field	Value
Method Name	urn
Status	provisional
Specification	This document
Contact	See Author's Address

This document has no other IANA actions.

References Normative References W3C Recommendation W3C Working Group Note Informative References W3C Working Group Note W3C Candidate Recommendation Web 7.0 Foundation Licensed under Creative Commons Attribution-ShareAlike 4.0 International Public License

Complete Example This appendix illustrates a complete did7:web7 resolution using an ISBN URN as input, with Mode 2 (fingerprint) and a service endpoint included. Source URN: Derived URN DID: Resolved DID Document (Modes 1 + 2 + service endpoint):

Acknowledgements The author thanks the members of the W3C Decentralized Identifier Working Group and the broader DID community for their foundational work on the DID Core specification, and the IETF URN community for their long-standing stewardship of URN namespaces.