SDO: Authority-Scoped Decentralized Identifiers (DID7)

Create your own magic with Web 7.0 DIDLibOS / TDW AgenticOS. Imagine the possibilities.

Copyright © 2026 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License Web 7.0, TDW AgenticOS and Hyperonomy are trademarks of the Web 7.0 Foundation. All Rights Reserved

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:///:

3.2 Shorthand Form

did7::

3.3 Expansion Rule (Normative)

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

4. ABNF Grammar

did7-uri = "did7://" authority "/" method ":" method-iddid7-short = "did7:" method ":" method-idauthority = 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::

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:///:

Process:

• Resolve to resolver metadata

Output:

• Resolver endpoint(s)

• Supported methods

• Resolution policies (optional)

6.2 Stage 2: Method Resolution

Input:

:

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::→ did7://w3.org/:

7.2 Non-Equivalence (Normative)

did7://w3.org/:≠ did::

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

FeatureDID CoreDID7Schemedid:did7:NamespaceMethod-onlyAuthority + MethodResolutionMethod-specificAuthority → MethodTrust LayerImplicitExplicit (optional)

13. Implementation Notes (Non-Normative)

A minimal DID7 resolver can be implemented as:

• Parse DID7 URI

• Expand shorthand

• Lookup authority configuration

• Dispatch to method resolver

• 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)