Web 7.0 DIDLibOS™ / TDW AgenticOS™ / Hyperonomy™ Digital Identity Lab

Create your own magic with Web 7.0 DIDLibOS™ / TDW AgenticOS™. Imagine the possibilities.

Copyright © 2026 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
Web 7.0™, Web 7.0 DILibOS™, TDW AgenticOS™, TDW™, Trusted Digital Web™ and Hyperonomy™ are trademarks of the Web 7.0 Foundation. All Rights Reserved.

Web 7.0 Federation – Trusted Digital Web™ (TDW™)

Web 7.0 is a general-purpose infrastructure for:

1. DID Document management (W3C spec compliant)
2. Verifiable Credential issuance and lifecycle (W3C VC v2 JWT)
3. DIDComm v2 encrypted messaging (full spec implementation)
4. Append-only RFC 6962 Merkle audit log
5. UTXO-based token accounting
6. GDPR Article 17 erasure
7. Implements Sovrona Shared Reserve Currency (SRC) Pools (Ticker: SVRN7)

NOTE: The first four capbabilities are general decentralized identity infrastructure that any organization could use independently of the monetary layer.

Sovrona Shared Reserve Currency (SRC) (Ticker: SVRN7™)

Sovrona (SVRN7™) is the Shared Reserve Currency (SRC) for the Web 7.0 digital ecosystem, implemented as an embeddable .NET 8 library that manages citizen and society wallets, enforces a governance-controlled three-epoch monetary lifecycle, and maintains a cryptographically tamper-evident audit log of all transactions.

Unlike traditional and modern digital currencies, SVRN7 is built on a foundation of self-sovereign identity — every participant is a DID holder, every entitlement/endowment is a Verifiable Credential, and trust between parties is established through standards-based cryptographic proofs rather than a shared blockchain or central authority.

Web 7.0 Use Cases

With configurable DID method names, the library becomes usable in scenarios that have nothing to do with the SVRN7 SRC.

Healthcare network. A hospital consortium where each hospital operates its own DID method (did:hospital-a, did:hospital-b). Patient VCs issued by one hospital are verifiable by any other. The Merkle log provides an auditable record of credential issuance without exposing patient data. DIDComm handles encrypted referral messages between hospitals.

Supply chain. A manufacturing network where each tier-1 supplier owns a DID method. Components carry VC provenance records signed by their manufacturer’s DID. The Federation equivalent is the brand owner who sets the governance rules. The UTXO model tracks component custody rather than currency.

Professional credentialing. A federation of professional bodies (law societies, medical councils, engineering institutes) where each body owns its DID method and issues member credentials. Cross-body credential verification uses the same IDidResolver routing the SVRN7 library already needs.

Government identity federation. Multiple municipal or provincial identity systems where each jurisdiction owns its DID method. Citizens have identities under their jurisdiction’s method. Cross-jurisdiction services verify credentials without requiring a central identity broker.

Create your own magic with Web 7.0 DIDLibOS™ / TDW AgenticOS™. Imagine the possibilities.

Copyright © 2025 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
Web 7.0™, Web 7.0 DILibOS™, TDW AgenticOS™, TDW™, Trusted Digital Web™ and Hyperonomy™ are trademarks of the Web 7.0 Foundation. All Rights Reserved.

Great question — and worth thinking through carefully, because the SAE framing maps surprisingly well onto digital agents if you abstract it correctly.

The Core Analogy

In autonomous vehicles, the levels measure how much human oversight and intervention is required for safe operation. The same axis applies to digital agents: how much must a human monitor, correct, or authorize before the agent acts?

A Proposed Digital Agent Autonomy Scale

What Makes Level 5 Hard for Digital Agents

Just like autonomous vehicles, nobody has achieved digital Level 5 yet — and for parallel reasons:

• Identity — who authorized this agent to act, and can that be verified in real time by any system it touches?
• Integrity — is the agent acting on real, unmanipulated data/context, or has its information environment been poisoned?
• Accountability — is every decision cryptographically auditable after the fact?
• Trust portability — can the agent’s authorization travel with it across organizational boundaries, jurisdictions, and protocols?

These are almost exactly the same gaps the did:level5 site frames for vehicles — just in a digital context.

Where Web 7.0 Trusted Digital Assistants Fit

Your TDA concept is explicitly designed to be a Level 5 digital agent architecture. The components map directly:

The TDA is essentially a Level 5 digital agent that carries its own sovereign identity, operates within cryptographically governed trust circles, and can act across systems without requiring human re-authorization at each step — while remaining fully auditable.

The Key Distinction from Lower Levels

The leap from Level 4 to Level 5 — for both vehicles and digital agents — is trust portability across unknown contexts. A Level 4 agent can operate autonomously within a known, pre-configured environment. A Level 5 agent can walk into an entirely new system, organization, or jurisdiction and be trusted on first contact because its identity, credentials, and authorization chain are self-contained and cryptographically verifiable.

That’s exactly what did:drn + VTCs + cryptoseals are designed to enable — the agent doesn’t need a prior relationship with the system it’s interacting with. The trust travels with it.

A Possible Contribution

Given your standards work, there may be value in formally proposing a Digital Agent Autonomy Level framework — analogous to SAE J3016 but for agentic AI systems — with Web 7.0 / TDA architecture positioned as the reference implementation for Level 5. It would give the broader field (IETF, W3C, ISO, IEEE) a vocabulary for discussing agent trust requirements at each level, and anchor your work as foundational infrastructure rather than one implementation among many.

Do digital agents need to use AI to be compliant with Level 5 Autonomous Operation?

No — and this is an important distinction worth being precise about.

Level 5 is about autonomy architecture, not AI

In the SAE vehicle context, Level 5 says nothing about how the driving decisions are made — only that the system can handle all conditions without human intervention. The intelligence mechanism is orthogonal to the autonomy level.

The same applies to digital agents. Level 5 is a statement about:

• Trust — the agent’s identity and authorization are sovereign and portable
• Accountability — every action is cryptographically auditable
• Scope — the agent can operate across any context without human re-authorization
• Integrity — the agent acts on verified, unmanipulated information

None of those properties require AI. A deterministic rule-based agent, a scripted workflow engine, or a pure cryptographic protocol daemon could in principle satisfy all four.

What AI adds — and doesn’t add

AI (specifically LLMs or reasoning models) adds:

• Natural language understanding and generation
• Handling of ambiguous or novel situations
• Flexible goal decomposition
• Adaptability across unanticipated contexts

But AI also complicates Level 5 compliance because:

• LLM outputs are non-deterministic — the same input can produce different actions
• Reasoning chains are not natively auditable in a cryptographic sense
• AI can be manipulated via prompt injection — a direct analogue to the visual injection attack the did:level5 site describes
• AI doesn’t inherently carry sovereign identity or verifiable authorization

So paradoxically, AI is the component that most threatens Level 5 compliance if not properly bounded, and the trust architecture — DIDs, VTCs, cryptoseals, runspace governance — is what contains the AI and makes its actions compliant.

The Right Mental Model

Think of it in layers:

AI sits only in the task intelligence layer. All the layers that make an agent Level 5 compliant are below it and independent of it.

For TDA Specifically

A Trusted Digital Assistant could be fully Level 5 compliant running nothing but deterministic logic — scripted workflows, rule engines, protocol handlers — as long as the identity, authorization, integrity, and auditability infrastructure is in place.

When an AI reasoning layer is present, the TDA architecture constrains it: the AI operates within a bounded runspace, its outputs are subject to credential-gated authorization before execution, and its actions are sealed into the audit record. The AI doesn’t grant Level 5 — the architecture does. The AI is a passenger, not the driver.

This is actually a meaningful standards argument: Level 5 digital agent compliance is an infrastructure and governance property, not a capability property. A very capable AI with no trust architecture is not Level 5. A simple deterministic agent with full sovereign identity and cryptographic accountability is.

Create your own magic with Web 7.0 DIDLibOS™ / TDW AgenticOS™. Imagine the possibilities.

Copyright © 2026 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
Web 7.0™, Web 7.0 DILibOS™, TDW AgenticOS™, TDW™, Trusted Digital Web™ and Hyperonomy™ are trademarks of the Web 7.0 Foundation. All Rights Reserved.

DSA: Which field values of the following documents are locator DIDs and which are identity DIDs?

• DID Document
• VC Document
• DIDComm Message

In what follows, each document type is systematically and precisely mapped to the DID identity/locator framework.

DID Document

{
  "id": "did:drn:z6Mk...9xEg",                          ← IDENTITY
  "controller": "did:drn:z6MkController...abc",          ← IDENTITY
  "alsoKnownAs": ["did:drn:z6MkAka...xyz"],              ← IDENTITY
  "verificationMethod": [{
    "id": "did:drn:z6Mk...9xEg#key-1",                   ← LOCATOR
    "controller": "did:drn:z6Mk...9xEg",                 ← IDENTITY
    "type": "Ed25519VerificationKey2020",
    "publicKeyMultibase": "z6Mk..."
  }],
  "authentication": [
    "did:drn:z6Mk...9xEg#key-1"                          ← LOCATOR
  ],
  "assertionMethod": [
    "did:drn:z6Mk...9xEg#key-1"                          ← LOCATOR
  ],
  "capabilityInvocation": [
    "did:drn:z6Mk...9xEg#key-1"                          ← LOCATOR
  ],
  "capabilityDelegation": [
    "did:drn:z6Mk...9xEg#key-1"                          ← LOCATOR
  ],
  "keyAgreement": [
    "did:drn:z6Mk...9xEg#key-2"                          ← LOCATOR
  ],
  "service": [{
    "id": "did:drn:z6Mk...9xEg#vcregistry-1",            ← LOCATOR
    "type": "CredentialRegistry",
    "serviceEndpoint": "https://registry.example.com/..."  ← URL (retrieval)
  },
  {
    "id": "did:drn:z6Mk...9xEg#didcomm-1",               ← LOCATOR
    "type": "DIDCommMessaging",
    "serviceEndpoint": "https://agent.example.com/..."     ← URL (retrieval)
  }]
}

Pattern: id at the document root is always an identity DID. Every field that contains a fragment — verification methods, verification relationships, service entries — is always a locator DID. controller is always an identity DID. serviceEndpoint values are retrieval URLs, outside the DID identity/locator taxonomy entirely.

VC Document

{
  "@context": [...],
  "id": "did:drn:z6MkCredential...abc",                  ← IDENTITY (envelope identity)
  "type": ["VerifiableCredential", "MembershipCredential"],
  "issuer": {
    "id": "did:drn:z6MkIssuer...3kRt",                   ← IDENTITY
    "name": "Web 7.0 Foundation"
  },
  "validFrom": "2026-01-01T00:00:00Z",
  "validUntil": "2027-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:drn:z6MkSubject...9xEg",                  ← IDENTITY (subject identity)
    "memberOf": "did:drn:z6MkOrg...7fPq",                ← IDENTITY
    "role": "Member"
  },
  "credentialStatus": {
    "id": "did:drn:z6MkStatus...8bNm",                   ← LOCATOR (points into status registry)
    "type": "StatusList2021Entry"
  },
  "cryptoseal": [{
    "type": "DataIntegrityProof",
    "verificationMethod": "did:drn:z6MkIssuer...3kRt#key-1",  ← LOCATOR
    "cryptosuite": "eddsa-2022",
    "created": "2026-01-01T00:00:00Z",
    "proofValue": "z58DAdFfa..."
  }]
}

Pattern: Top-level id, issuer.id, credentialSubject.id, and any DID references within claims are all identity DIDs — they name entities. credentialStatus.id and proof.verificationMethod are locator DIDs — they navigate to sub-resources. The credentialStatus.id is the one field that often goes unrecognized as a locator but clearly is: it points into a status registry to retrieve the current revocation state of this specific credential.

DIDComm Message

{
  "id": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6", ← IDENTITY (message identity — URN, not DID)
  "type": "https://didcomm.org/basicmessage/2.0/message", ← IDENTITY (IRI naming message type)
  "typ": "application/didcomm-encrypted+json",
  "from": "did:drn:z6MkSender...abc",                    ← IDENTITY
  "to": ["did:drn:z6MkRecipient...xyz"],                 ← IDENTITY
  "thid": "urn:uuid:parent-thread-id",                   ← IDENTITY (thread identity)
  "pthid": "urn:uuid:parent-parent-thread-id",           ← IDENTITY (parent thread identity)
  "created_time": 1704067200,
  "expires_time": 1704153600,
  "from_prior": {
    "iss": "did:drn:z6MkPrior...def",                    ← IDENTITY (prior DID — rotation)
    "sub": "did:drn:z6MkSender...abc",                   ← IDENTITY (new DID — rotation)
    "aud": "did:drn:z6MkRecipient...xyz"                 ← IDENTITY
  },
  "body": {
    "content": "..."
  },
  "attachments": [{
    "id": "attachment-1",                                 ← IDENTITY (attachment identity)
    "media_type": "application/vc+ld+json",
    "data": {
      "links": ["did:drn:z6MkSubject...9xEg?service=CredentialRegistry"]  ← LOCATOR
    }
  }]
}

Pattern: DIDComm message fields are overwhelmingly identity DIDs — from, to, from_prior.iss, from_prior.sub, from_prior.aud all name parties, not locations. The message id is typically a URN UUID — an identity token outside the DID space entirely. Locator DIDs appear only when explicitly navigating to a sub-resource — such as a CredentialRegistry service endpoint in an attachment link, or a verification method reference in an attached cryptoseal.

Cross-Document Summary

The governing rule across all three document types is consistent and clean:

A DID with no # or ? is always an identity DID — it names an entity.
A DID with # or ? is always a locator DID — it navigates to a sub-resource.
This rule holds uniformly across DID Documents, VC Documents, and DIDComm Messages.

Copyright © 2026 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
Web 7.0™, Web 7.0 DILibOS™, TDW AgenticOS™, TDW™, Trusted Digital Web™ and Hyperonomy™ are trademarks of the Web 7.0 Foundation. All Rights Reserved.

Abstract

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.¶

Derivation Notice

This note is to be removed before publishing as an RFC.¶

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.¶

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”¶

This Internet-Draft will expire on 25 September 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶▲

Table of Contents

• 1.  Introduction
• 2.  Conventions and Definitions
• 3.  Terminology
• 4.  Method Name
• 5.  Method-Specific Identifier
  • 5.1.  Syntax
  • 5.2.  Normalization
• 6.  Core Properties
  • 6.1.  Determinism
  • 6.2.  Reversibility
  • 6.3.  Infrastructure Independence
• 7.  DID Resolution
  • 7.1.  Resolution Input
  • 7.2.  Resolution Output
  • 7.3.  Resolution Modes
    • 7.3.1.  Mode 1 – Stateless Resolution (REQUIRED)
    • 7.3.2.  Mode 2 – Deterministic Fingerprint (RECOMMENDED)
    • 7.3.3.  Mode 3 – Discovery-Enhanced Resolution (OPTIONAL)
• 8.  DID Document Structure
  • 8.1.  Base Document
  • 8.2.  Optional Properties
    • 8.2.1.  Verification Methods
    • 8.2.2.  Service Endpoints
    • 8.2.3.  Equivalent Identifier
• 9.  Controller Model
  • 9.1.  Default Behaviour
  • 9.2.  Establishing Control
• 10. Verification and Trust
• 11. CRUD Operations
• 12. Interoperability
  • 12.1.  With URN Systems
  • 12.2.  With the DID Ecosystem
• 13. Design Rationale
• 14. Privacy Considerations
  • 14.1.  Correlation Risks
  • 14.2.  Mitigations
• 15. Security Considerations
  • 15.1.  Limitations
  • 15.2.  Recommendations
• 16. IANA Considerations
• 17. References
  • 17.1.  Normative References
  • 17.2.  Informative References
• Appendix A.  Complete Example
• Acknowledgements
• Author’s Address

1. Introduction

Uniform Resource Names (URNs) [RFC8141] provide a well-established mechanism for assigning persistent, location-independent identifiers to resources. However, URNs predate the Decentralized Identifier (DID) ecosystem [W3C.DID-CORE] 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 [W3C.DID-CORE].¶

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.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals as shown here.¶

ABNF notation used in this document follows [RFC5234].¶

3. Terminology

URN (Uniform Resource Name): A persistent, location-independent identifier conforming to the syntax defined in [RFC8141], 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 [W3C.DID-CORE].¶ Resolver: A software component that, given a DID, returns a DID Document conforming to the requirements of [W3C.DID-RESOLUTION].¶ Controller: An entity, as identified by a DID, that has the capability to make changes to a DID Document, as defined in [W3C.DID-CORE].¶ Fingerprint: A cryptographic hash of a canonical representation of the embedded URN, used to derive a did:key-compatible equivalent identifier.¶

4. 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.¶

5. Method-Specific Identifier

5.1. Syntax

The ABNF grammar for a did7:web7 DID is as follows:¶

did-web7-urn = "did7://web7/" urn
urn     = "urn:" NID ":" NSS
NID     = <URN Namespace Identifier per RFC 8141>
NSS     = <Namespace-Specific String per RFC 8141>

¶

The following are conformant examples of did7:web7 identifiers:¶

did7://web7/urn:isbn:9780141036144
did7://web7/urn:uuid:6ba7b810-9dad-11d1-80b4-00c04fd430c8
did7://web7/urn:ietf:rfc:8141
did7://web7/urn:epc:id:sgtin:0614141.107346.2017

¶

5.2. Normalization

Implementations MUST normalize the embedded URN according to the lexical equivalence and case-folding rules specified in Section 3.1 of [RFC8141] 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 [RFC3986]) applies to the NSS component where permitted by the applicable namespace registration.¶

6. Core Properties

6.1. 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 [RFC8141] MUST produce the same did7:web7.¶

6.2. 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.¶

6.3. 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, Section 7.3).¶

7. DID Resolution

7.1. Resolution Input

The resolution input is a did7:web7 string conforming to the syntax defined in Section 5.1, optionally accompanied by resolution options as defined in [W3C.DID-RESOLUTION].¶

Input:  did7://web7/<urn>

¶

7.2. Resolution Output

A conforming resolver MUST return a DID Document. The minimum conformant DID Document for any did7:web7 identifier is:¶

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did7://web7/urn:isbn:9780141036144",
  "alsoKnownAs": [
    "urn:isbn:9780141036144"
  ]
}

¶

The alsoKnownAs property MUST contain the embedded URN in its normalized form (per Section 5.2).¶

7.3. Resolution Modes

7.3.1. 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.¶

7.3.2. Mode 2 – Deterministic Fingerprint (RECOMMENDED)

Resolvers SHOULD support derivation of a cryptographic fingerprint from the canonical URN. The fingerprint is derived as:¶

fingerprint = hash(canonical-urn)

¶

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 [I-D.multiformats-multibase]). The derived fingerprint SHOULD be expressed as a did:key identifier and added to the DID Document as follows:¶

"equivalentId": [
  "did:key:<multibase-encoded-fingerprint>"
]

¶

7.3.3. 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.¶

8. DID Document Structure

8.1. Base Document

Every DID Document produced by a did7:web7 resolver MUST conform to the following template:¶

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did7://web7/<urn>",
  "alsoKnownAs": ["<urn>"]
}

¶

Where <urn> is the normalized URN as defined in Section 5.2.¶

8.2. Optional Properties

8.2.1. 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:¶

"verificationMethod": [
  {
    "id": "did7://web7/<urn>#key-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did7://web7/<urn>",
    "publicKeyMultibase": "z6Mk..."
  }
]

¶

Verification methods MUST conform to Section 5.2 of [W3C.DID-CORE].¶

8.2.2. 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:¶

"service": [
  {
    "id": "did7://web7/<urn>#resource",
    "type": "URNResourceService",
    "serviceEndpoint":
      "https://example.com/urn/<encoded-urn>"
  }
]

¶

Service endpoints MUST conform to Section 5.4 of [W3C.DID-CORE]. The type value SHOULD be registered in a publicly accessible DID Specification Registries entry [W3C.DID-SPEC-REGISTRIES].¶

8.2.3. Equivalent Identifier

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

9. Controller Model

9.1. 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.¶

9.2. Establishing Control

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

• Verifiable Credentials [W3C.VC-DATA-MODEL] 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.¶

10. 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 Section 8.2.1.¶
• 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.¶

11. CRUD Operations

The did7:web7 method supports the following subset of CRUD operations as defined in [W3C.DID-CORE]:¶

12. Interoperability

12.1. 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.¶

12.2. With the DID Ecosystem

The did7:web7 method is compatible with the W3C DID Core specification [W3C.DID-CORE] and the DID Resolution specification [W3C.DID-RESOLUTION]. It is composable with the following DID methods:¶

• did:key – via the deterministic fingerprint mechanism (Section 7.3.2).¶
• 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 Section 14.2).¶

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

13. 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 [W3C.DID-CORE] 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 Section 9) so that implementations may adopt only the complexity they require.¶

14. Privacy Considerations

14.1. 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.¶

14.2. 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.¶

15. Security Considerations

15.1. 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.¶

15.2. 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 [W3C.VC-DATA-MODEL] 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 [RFC8446] and SHOULD use certificate transparency.¶
• Input validation: Resolvers MUST validate the embedded URN against the ABNF grammar of [RFC8141] before performing any resolution activity.¶

16. IANA Considerations

This document requests registration of the following DID method name in the W3C DID Specification Registries [W3C.DID-SPEC-REGISTRIES]:¶

This document has no other IANA actions.¶

17. References

17.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>. [RFC5234] Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/rfc/rfc5234>. [RFC8141] Saint-Andre, P. and J. Klensin, “Uniform Resource Names (URNs)”, RFC 8141, DOI 10.17487/RFC8141, April 2017, <https://www.rfc-editor.org/rfc/rfc8141>. [RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. [RFC8446] Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>. [W3C.DID-CORE] Sporny, M., Guy, A., Sabadello, M., and D. Reed, “Decentralized Identifiers (DIDs) v1.0”, W3C Recommendation, July 2022, <https://www.w3.org/TR/did-core/>. [W3C.DID-RESOLUTION] Sabadello, M., “Decentralized Identifier Resolution (DID Resolution) v0.3”, W3C Working Group Note , 2023, <https://w3c-ccg.github.io/did-resolution/>.

17.2. Informative References

[I-D.multiformats-multibase] Sporny, M., “The Multibase Data Format”, Work in Progress, Internet-Draft, draft-multiformats-multibase, 2023, <https://datatracker.ietf.org/doc/ draft-multiformats-multibase/>. [W3C.DID-SPEC-REGISTRIES] Sporny, M. and O. Steele, “DID Specification Registries”, W3C Working Group Note , 2023, <https://www.w3.org/TR/did-spec-registries/>. [W3C.VC-DATA-MODEL] Sporny, M., Longley, D., and D. Chadwick, “Verifiable Credentials Data Model v2.0”, W3C Candidate Recommendation , 2024, <https://www.w3.org/TR/vc-data-model-2.0/>. [WEB70-URN] Herman, M., “SDO: W3C Decentralized Universal Resource Name (URN) DID Method (Web 7.0)”, Licensed under Creative Commons Attribution-ShareAlike 4.0 International Public License , March 2026, <https://hyperonomy.com/2026/03/24/ sdo-web-7-0-decentralized-resource-name-urn-did-method/>.

Appendix A. 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:¶

urn:isbn:9780141036144

¶

Derived URN DID:¶

did7://web7/urn:isbn:9780141036144

¶

Resolved DID Document (Modes 1 + 2 + service endpoint):¶

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did7://web7/urn:isbn:9780141036144",
  "alsoKnownAs": [
    "urn:isbn:9780141036144"
  ],
  "equivalentId": [
    "did:key:zQm..."
  ],
  "service": [
    {
      "id": "did7://web7/urn:isbn:9780141036144#info",
      "type": "BookMetadata",
      "serviceEndpoint":
        "https://example.org/isbn/9780141036144"
    }
  ]
}

¶

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.¶

Author’s Address

Michael Herman

Web 7.0 Foundation

BindlossAlberta

Canada

Email:mwherman@gmail.com

URI:https://hyperonomy.com/about/

Copyright © 2026 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
Web 7.0™, Web 7.0 DILibOS™, TDW AgenticOS™, TDW™, Trusted Digital Web™ and Hyperonomy™ are trademarks of the Web 7.0 Foundation. All Rights Reserved.

Full name: Decentralized Resource Name (DRN) DID Method
Status: Draft Recommendation
SDO: Web 7.0 Foundation
Editor: Michael Herman, Chief Digital Officer, Web 7.0 Foundation
Related standards: DID Core, URN (RFC 8141 via )

1. Abstract

The did:drn method defines a deterministic mapping from Uniform Resource Names (URNs) into a DID-compatible identifier format called a Decentralized Resource Name (DRN).

This method:

• Preserves URN semantics
• Enables DID resolution without mandatory centralized infrastructure
• Provides optional cryptographic and service-layer extensibility

2. Conformance

The key words MUST, SHOULD, and MAY are to be interpreted as described in RFC 2119.

3. Method Name

did:drn

4. Terminology

• URN: A persistent, location-independent identifier defined by RFC 8141
• DRN: A URN expressed within the did:drn method
• Controller: An entity asserting control over a DID Document

5. Method-Specific Identifier

5.1 Syntax

did-drn = "did:drn:" drn
drn     = "urn:" NSS
NSS     = <RFC 8141 namespace-specific string>

Examples

5.2 Normalization

did:drn:urn:isbn:9780141036144
did:drn:urn:uuid:6ba7b810-9dad-11d1-80b4-00c04fd430c8

Implementations MUST:

• Normalize the embedded URN according to RFC 8141
• Preserve namespace-specific comparison rules

6. Core Properties

6.1 Determinism

A given URN MUST map deterministically to a single did:drn.

6.2 Reversibility

The original URN MUST be recoverable without loss.

6.3 Infrastructure Independence

The method MUST NOT require a centralized registry for baseline resolution.

7. DID Resolution

7.1 Input

did:drn:<urn>

7.2 Output

A conforming resolver MUST return a DID Document.

Minimum Conformant Document

{
  "id": "did:drn:urn:isbn:9780141036144",
  "alsoKnownAs": [
    "urn:isbn:9780141036144"
  ]
}

7.3 Resolution Modes

Mode 1 — Stateless (REQUIRED)

• Resolver constructs the DID Document locally
• No external lookup required

Properties:

• Deterministic
• Zero infrastructure dependency

Mode 2 — Deterministic Fingerprint (RECOMMENDED)

Resolvers SHOULD derive a cryptographic fingerprint:

fingerprint = hash(urn)

Add:

"equivalentId": [
  "did:key:<fingerprint>"
]

Mode 3 — Discovery-Enhanced (OPTIONAL)

Resolvers MAY perform discovery using:

• DNS-based lookup
• HTTPS well-known endpoints
• Content-addressed storage (e.g., IPFS)

Discovery rules SHOULD be namespace-aware.

8. DID Document

8.1 Base Document

{
  "id": "did:drn:<urn>",
  "alsoKnownAs": ["<urn>"]
}

8.2 Optional Properties

Verification Methods

"verificationMethod": [
  {
    "id": "#key-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:drn:<urn>",
    "publicKeyMultibase": "..."
  }
]

Services

"service": [
  {
    "id": "#resource",
    "type": "DRNResourceService",
    "serviceEndpoint": "https://example.com/drn/<encoded-urn>"
  }
]

9. Controller Model

9.1 Default Behavior

• A DRN does not imply a controller

9.2 Establishing Control

Control MAY be asserted via:

• Verifiable Credentials
• Signed DID Documents
• Namespace authority attestations

10. Verification & Trust

10.1 Baseline

did:drn does not inherently guarantee authenticity

10.2 Trust Mechanisms

Trust SHOULD be layered using:

• Cryptographic proofs
• Third-party attestations
• Namespace authority validation

11. CRUD Operations

12. Privacy Considerations

Risks

• Deterministic mapping enables correlation
• Public URNs may expose identity linkage

Mitigations

• Pair with pairwise DIDs (did:peer)
• Avoid sensitive URNs in public contexts

13. Security Considerations

Limitations

• No inherent proof-of-control
• Susceptible to spoofed service endpoints

Recommendations

• Require signed metadata
• Use verifiable credentials for binding

14. Interoperability

With URN Systems

• Fully backward compatible
• No changes to existing URN infrastructure

With DID Ecosystem

• Compatible with DID Core
• Composable with:
  • did:key
  • did:web
  • did:peer

15. Example

Input

urn:isbn:9780141036144

DRN DID

did:drn:urn:isbn:9780141036144

Resolved Document

{
  "id": "did:drn:urn:isbn:9780141036144",
  "alsoKnownAs": [
    "urn:isbn:9780141036144"
  ],
  "equivalentId": [
    "did:key:zQm..."
  ],
  "service": [
    {
      "id": "#info",
      "type": "BookMetadata",
      "serviceEndpoint": "https://example.org/isbn/9780141036144"
    }
  ]
}

16. Design Rationale

Well-supported:

• Deterministic mapping aligns with DID design principles
• alsoKnownAs ensures semantic preservation
• Stateless resolution maximizes portability

Tradeoffs:

• No built-in trust layer
• No lifecycle operations

17. Positioning

What did:drn IS

• A universal adapter between URN and DID ecosystems
• A semantic identity bridge
• A zero-infrastructure resolution method (baseline)

What it is NOT

• A self-sovereign identity system by itself
• A registry-backed authority system

18. One-line Definition

did:drn transforms a URN into a resolvable, interoperable DID while preserving its original meaning and structure.