SDO: W3C Decentralized Resource Name (DRN) DID Method

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

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

  1. Conformance

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

  1. Method Name

did:drn

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

  1. Method-Specific Identifier

5.1 Syntax

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

Examples

5.2 Normalization

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

Implementations MUST:

• Normalize the embedded URN according to RFC 8141

• Preserve namespace-specific comparison rules

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

  1. DID Resolution

7.1 Input

did:drn:

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:"]

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.

  1. DID Document

8.1 Base Document

{ "id": "did:drn:", "alsoKnownAs": [""]}

8.2 Optional Properties

Verification Methods

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

Services

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

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

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

  1. CRUD Operations

OperationSupportCreateImplicit (deterministic derivation)ReadREQUIREDUpdateNOT supported (stateless baseline)DeactivateNOT supported

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

  1. Security Considerations

Limitations

• No inherent proof-of-control

• Susceptible to spoofed service endpoints

Recommendations

• Require signed metadata

• Use verifiable credentials for binding

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

  1. 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" } ]}

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

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

  1. One-line Definition

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

Read original article →