SDO: Web 7.0 Decentralized Resource Name (DRN) DID Method

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
Intended venue:
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.