The Decentralized Identifier (DID) in the DNS

Decentralized Identifiers (DIDs) use a Uniform Resource Identifier (URI) scheme to identify persons, organizations, or things in decentralized infrastructure, such as blockchains and distributed ledgers. DIDs are structured around "methods", each method defining the syntax of the "method specific identifier" and the operations on the respective DIDs (See Section 3.2 of and ). For many methods, the method specific identifier is not human-friendly (such as hash values, referring to transactions on a blockchain). Most DIDs are therefore inherently hard to memorize for humans. By referring to DIDs from the Domain Name System (DNS), those hard to memorize identifiers can be discovered via well known, human friendly and widely established names. This document specifies how DIDs can be published in the DNS for discovery on the base of host names and email addresses. Since DIDs use a URI scheme ('did'), this specification leverages the existing URI DNS Resource Record Type (RRType). Records are scoped using the '_did' global underscore node name, as described in .

"Owner name", "Priority", "Weight" and "Target" refer to the respective fields of the URI RRType, as specified in Section 4 of RFC 7553. 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 when, and only when, they appear in all capitals, as shown here.

DIDs use an URI scheme ('did:'), so the most suitable option to publish DIDs in the DNS is the use of the 'URI' RRType. During the development of this document, various alternatives were considered, see for a list. When Decentralized Identifiers (DIDs) are published in the DNS, the 'URI' RRType MUST be used.

describes the advantages of scoping an existing RRType over the definition (and complex deployment) of a new RRType. The "URI" RRType is specifically mentioned as one example where scoping is particularly useful (and part of the design). When DIDs are published in the DNS the records MUST be scoped by setting the global (highest-level) underscore name of the URI RRset to '_did' (0x5F 0x64 0x69 0x64), and the Target field of all records in the RRset MUST contain a URI of the 'did:' URI scheme.

The semantics of the Weight and Priority fields remain. When a client encounters a DID method it does not support, it SHOULD consider the respective URI "unreachable" for the purpose of record selection, and proceed to the record with the next-lowest-numbered Priority, in accordance with Section 4.2 of RFC 7553.

In order to discover the set of DIDs associated with a Host Name, a client prepends the given Host Name with the '_did' global underscore name to create the Owner name, and then queries the resulting Query Name for the URI RRType set.

To discover DIDs associated with email addresses, the (experimental) model from DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP is used. A client prepares the email address following the procedure outlined in Section 5 in RFC7929 the form the Query Name, but in step 5 MUST use the string '_mailto._did' instead of '_openpgpkey' as the second left-most label. Subsequently, the client performs a DNS query, but MUST use the URI RRType as Query Type (rather than the OPENPGPKEY RRType described in said section).

The following example is a URI Resource Record which refers from the host name "example.net" to a Decentralized Identifier using the 'sov' method: _did.example.net. IN URI 100 10 "did:sov:1234abcd"

During the development of this document, the following alternatives were considered: A dedicated RRType, TXT records, an Enumservice, Well-Known URIs, direct registration in the Service Name Registry. Using the URI RRType was found to be the option with the least impact on existing specifications and highest interoperability potential. Support for URI RRTypes is widespread in DNS software, which means that implementation and deployment of the proposed protocol should be possible without any changes to underlying infrastructure. Furthermore, the Identifiers and Discovery Working Group of the Decentralized Identity Foundation (DIF) is considering a .well-known URL based approach to discovering DIDs from web sites.

DNS-DID is considered for implementation in the following frameworks / applications: The "Registration" function of the "Fission" framework (https://whitepaper.fission.codes/accounts/verifiable-claims)

Acknowledgements will be added here.

Per IANA is requested to add the following entry to the DNS Underscore Global Scoped Entry Registry: RR Type _NODE NAME REFERENCE URI _did {THISRFC} Please replace the above "{THISRFC}" text with a reference to this document's RFC number. Note that IANA has already created a provisional URI scheme registration for the 'did:' scheme itself.

Most of the considerations outlined in the base specification of the URI RRType (RFC7553) also apply to the DID use case - particularly the concerns around downgrade attacks when the record is not signed with the help of DNSSEC. Note that the DID resolving process itself (out of scope of this document) can provide additional security information. The "Linked Domain Service Endpoint" of a DID document can be used to back-reference to the Domain which was originally used to discover that DID. Such a "closed loop" (similar to verifying DNS reverse lookups against their corresponding forward lookups) would increase the confidence in non-DNSSEC scenarios. Including a DID in the DNS allows for correlation of that DID with DNS information (and potentially registration information of that DNS name). Therefore DIDs which are supposed to be private SHOULD NOT be added to the DNS.

[Note to RFC Editors: This whole section is to be removed before publication]

Adding "implementation" section

Reworded "Alternatives" Added text about backreference using DID's Linked Domain Service Endpoint.

Updated DID spec to v1.0 document Minor editorial changes to make text more clear.

Updated attrleaf reference to RFC8552 Changed author information for D. Klesev Added sentence on .well-known discovery scheme

email addresses further scoped with '_mailto._did' Changed protocol registration to attrleaf drafts Made clear requirements regarding use of the URI scheme Added privacy aspect to security considerations

Initial version