Decentralized Identifier Method: `did:drn`

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


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

5.2 Normalization

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 Construction

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

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

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.

Those are the pieces that would move this from clean spec → deployable ecosystem.

link to the original content

Decentralized Identifier Method: did:drn