DID7: Authority-Scoped Decentralized Identifier Scheme

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 18 September 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

The W3C Decentralized Identifiers (DIDs) specification [DID-CORE] defines method-based identifiers without a global namespace. DID7 introduces an optional authority layer, enabling namespace partitioning, governance domains, and scalable resolution infrastructure while remaining compatible with DID Core.¶

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

DID Document:

As defined in [DID-CORE].¶

Authority:

A namespace controller that defines resolver endpoints and governance rules for a set of DID7 identifiers.¶

Method:

A named DID method as defined in [DID-CORE].¶

3. DID7 Syntax

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

did7-uri       = "did7:" [ authority ] method ":" method-id

authority      = "//" authority-name "/"
authority-name = 1*( ALPHA / DIGIT / "-" )

method         = 1*( ALPHA / DIGIT )
method-id      = 1*( unreserved / pct-encoded / "." / "-" / "_" )

pct-encoded    = "%" HEXDIG HEXDIG

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

4. Authority Model

Authorities define resolution namespaces for DID7 identifiers. An authority:¶

• MAY define resolver endpoints, governance models, and supported methods.¶
• MUST NOT alter DID Document semantics as defined in [DID-CORE].¶
• Introduces an optional trust boundary for identifiers in its namespace.¶

5. Resolution Model

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

6. Compatibility

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

7. Security Considerations

The following security considerations apply to implementations of this specification:¶

• Authorities introduce a trust surface. The integrity of resolver endpoints MUST be verified before use. Implementations SHOULD use certificate-based authentication when contacting resolver endpoints.¶
• DNS responses used for authority resolution SHOULD be validated using DNSSEC to prevent DNS spoofing attacks.¶
• Resolver endpoints SHOULD use HTTPS (TLS) to protect data in transit. Endpoints using plain HTTP MUST NOT be used in production deployments.¶
• Cryptographic verification of DID Documents MUST follow the procedures defined in [DID-CORE].¶
• Implementations MUST NOT accept resolver endpoints that redirect to third-party domains not associated with the declared authority.¶

8. IANA Considerations

This document requests registration of the URI scheme "did7" in the "Uniform Resource Identifier (URI) Schemes" registry maintained by IANA, in accordance with [RFC7595].¶

URI scheme name:

did7¶

Status:

Provisional¶

URI scheme syntax:

See Section 3.2 of this document.¶

URI scheme semantics:

The "did7" URI scheme identifies authority-scoped decentralized identifiers. Resolution proceeds in two stages: authority discovery via DNS, followed by method-specific DID resolution. The resulting resource is a DID Document as defined in [DID-CORE].¶

Encoding considerations:

The "did7" URI scheme uses only ASCII characters as defined by the ABNF in Section 3.2. Non-ASCII characters in the method-specific identifier component MUST be percent-encoded per [RFC3986].¶

Applications/protocols that use this URI scheme:

Applications implementing decentralized identity, verifiable credentials, or self-sovereign identity frameworks that require authority-scoped namespace governance.¶

Interoperability considerations:

DID7 URIs are not directly interchangeable with W3C DID URIs. See Section 6 for the one-way mapping from W3C DID to DID7.¶

Security considerations:

See Section 7 of this document.¶

Contact:

Michael Herman <michael@web7.foundation>¶

Author/change controller:

Michael Herman, Web 7.0 Foundation¶

References:

This document.¶

9. Examples

The following are valid DID7 URIs:¶

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

10. Conformance (Non-Normative)

The following URIs are valid under the syntax defined in Section 3.2:¶

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

The following URIs are invalid and MUST be rejected by conforming implementations:¶

did7:///          (empty authority-name and empty method)
did7://w3.org/    (empty method and method-id)
did7:             (missing method and method-id)

Author's Address