SDO: Authority-Scoped Decentralized Identifiers (DID7)

Version: 0.1
Status: W3C-style Working Draft / Informational
Editor: Michael Herman (Chief Digital Officer, Web 7.0 Foundation)
Intended Audience: Standards bodies, implementers, protocol designers
SDO: Web 7.0 Foundation
Also Known As: did://ietf/docs:draft-herman-did7-identifier-01

Abstract

This document defines the did7 URI scheme, an authority-scoped DID format. DID7 adds:

• An optional authority component
• Two-stage resolution (authority → method)
• Forward-compatible namespace expansion

The specification is fully compatible with the W3C DID Core data model [DID-CORE].

NOTE: This version mirrors W3C specification formatting conventions, including:

• Clear separation of normative vs non-normative content
• ABNF blocks with examples
• In-line references to DID Core
• Sectioning like W3C DID Core Recommendation

1 Introduction

The DID Core specification [DID-CORE] defines method-based identifiers without a global namespace. DID7 introduces an optional authority layer, allowing namespace partitioning and federation while remaining compatible with DID Core.

DID7 goals:

• Namespace partitioning
• Governance flexibility
• Forward-compatible routing

2 Terminology

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, MAY are interpreted as described in [RFC2119][RFC8174].

• DID Document: As defined in [DID-CORE].
• Authority: A namespace identifier controlling resolution behavior.

3 DID7 Syntax

3.1 URI Form

did7:[//<authority-name>/]<method>:<method-specific-id>

3.2 ABNF

did7-uri        = "did7:" [ authority ] method ":" method-id
authority       = "//" authority-name "/"
authority-name  = 1*( ALPHA / DIGIT / "-" )
method          = 1*( ALPHA / DIGIT )
method-id       = 1*( unreserved / ":" / "." / "-" / "_" )

3.3 Default Authority

If authority is absent, it MUST default to w3.org.

3.4 Expansion Rule

did7:<method>:<id> → did7://w3.org/<method>:<id>

4 Authority Model

Authorities define resolution namespaces.

• MAY define resolver endpoints, governance, and supported methods
• MUST NOT alter DID Document semantics [DID-CORE]

Note: Authorities introduce optional trust boundaries.

5 Resolution Model

5.1 Stage 1: Authority Resolution

• Implementations SHOULD use DNS TXT or SRV records:

_did7.<authority-domain> TXT "resolver=https://resolver.example.com"

5.2 Stage 2: Method Resolution

• Method resolver returns a DID Document conforming to [DID-CORE].

6 Compatibility with DID

6.1 One-Way Mapping

did:<method>:<id> → did7://w3.org/<method>:<id>

6.2 Non-Equivalence

• did7 identifiers are not equivalent to DID Core identifiers.

7 Security Considerations

• Authority introduces a trust surface; verify authority integrity
• DNS responses SHOULD be validated using DNSSEC
• Resolver endpoints SHOULD use HTTPS
• DID Document integrity MUST follow cryptographic verification in [DID-CORE]

8 IANA Considerations

• Register did7 URI scheme
• Status: provisional
• Reference: this document

9 Examples

did7:example:123
did7://w3.org/example:123
did7://dif/web:abc
did7://acbd1234/custom:xyz_123

10 Conformance Testing (Non-Normative)

Valid

did7:example:123
did7://w3.org/example:123
did7://dif/web:abc.def

Invalid

did7:///
did7://w3.org/
did7:

Note: Implementations MUST fail parsing invalid URIs.

11 References

Normative

[DID-CORE]
Decentralized Identifiers (DIDs) v1.0, W3C Recommendation, 2022
https://www.w3.org/TR/did-core/

[RFC2119]
S. Bradner, “Key words for use in RFCs to Indicate Requirement Levels”, 1997

[RFC8174]
B. Leiba, “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, 2017

Non-Normative

Italicized explanations, rationale, and conformance examples are non-normative.