Version: 0.1
Status: Draft
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 specification defines the did7 URI scheme, an authority-scoped decentralized identifier format that extends the conceptual model of Decentralized Identifiers (DIDs). DID7 introduces an explicit authority layer above DID methods and defines a two-stage resolution process. DID7 is designed to be compatible with the DID Core data model while enabling forward-compatible namespace routing and governance flexibility.

1. Introduction

The Decentralized Identifier (DID) architecture defined by DID Core provides a method-based identifier system without a global authority namespace.

This specification introduces:

• A new URI scheme: did7
• An authority-scoped identifier structure
• A two-stage resolution model
• A forward-compatible namespace design

DID7 is intended to:

• Enable explicit namespace partitioning
• Support multiple governance domains
• Provide a top-level resolution entry point

2. Conformance

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

This specification:

• Normatively references DID Core for DID Document structure and semantics
• Does not modify DID Documents
• Overrides identifier syntax and resolution entry point only

3. DID7 Identifier Syntax

3.1 Primary Form

did7://<authority>/<method>:<method-specific-id>

3.2 Shorthand Form

did7:<method>:<method-specific-id>

3.3 Expansion Rule (Normative)

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

4. ABNF Grammar

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

5. Authority Model

5.1 Definition

An authority is a namespace identifier that scopes DID methods and resolution behavior.

Examples:

• w3.org
• dif
• ietf
• toip
• web7
• acbd1234

5.2 Authority Semantics

This specification defines the authority as a:

Resolution control namespace

Authorities MAY:

• Define resolver endpoints
• Define method availability
• Establish governance or trust frameworks

Authorities MUST NOT:

• Alter the internal semantics of DID Documents defined by DID Core

5.3 Default Authority

If omitted via shorthand:

did7:<method>:<id>

The authority MUST default to:

w3.org

6. Resolution Model

DID7 defines a two-stage resolution process.

6.1 Stage 1: Authority Resolution

Input:

did7://<authority>/<method>:<id>

Process:

• Resolve <authority> to resolver metadata

Output:

• Resolver endpoint(s)
• Supported methods
• Resolution policies (optional)

6.2 Stage 2: Method Resolution

Input:

<method>:<method-specific-id>

Process:

• Invoke method-specific resolution

Output:

• A DID Document conforming to DID Core

6.3 Resolution Flow Example

did7://w3.org/example:123
        ↓
[DID7 Resolver]
        ↓
Authority: w3.org
        ↓
Delegates to example method
        ↓
Returns DID Document

7. Compatibility with DID Core

7.1 One-Way Mapping (Normative)

Allowed:

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

7.2 Non-Equivalence (Normative)

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

7.3 Implications

• DID7 is a strict superset namespace
• Not all DID7 identifiers are valid DIDs
• Equivalence MUST NOT be assumed

8. Resolver Discovery

This specification does not mandate a single discovery mechanism.

Authorities MAY define resolver discovery via:

• Static configuration
• HTTPS well-known endpoints
• DNS-based discovery (e.g., TXT or SRV records)
• Decentralized registries

9. Security Considerations

9.1 Authority Trust

• Authorities introduce a potential trust layer
• Implementers MUST evaluate authority trustworthiness

9.2 Namespace Collisions

• Authorities are not globally enforced
• Collisions MAY occur without coordination

9.3 Resolution Integrity

• Resolver endpoints SHOULD support secure transport (e.g., HTTPS)
• Integrity of resolution responses MUST be verifiable via DID Document cryptography

10. IANA Considerations (Optional)

The did7 URI scheme MAY be registered with IANA.

Required fields:

• Scheme name: did7
• Status: provisional or permanent
• Specification: this document

11. Design Rationale (Non-Normative)

DID Core omits a global namespace layer. DID7 introduces:

• Explicit authority routing (similar to DNS)
• Separation of governance domains
• Forward-compatible extensibility

This enables:

• Federation models
• Multi-organization ecosystems
• Layered trust frameworks

12. Comparison to DID Core

13. Implementation Notes (Non-Normative)

A minimal DID7 resolver can be implemented as:

1. Parse DID7 URI
2. Expand shorthand
3. Lookup authority configuration
4. Dispatch to method resolver
5. Return DID Document

What you now have (verification-style)

Well-supported

• Clean separation from DID Core
• Proper layering model
• Spec is publishable and reviewable
• ABNF + normative language included

New / experimental (but coherent)

• Authority as a first-class routing layer
• Two-stage resolution model
• One-way compatibility rule

Open design decisions (you may want to refine next)

• Canonical authority registry (or none)
• Resolver discovery standard (DNS vs HTTPS)
• Trust semantics of authority (light vs strong governance)