idnits 2.17.1 draft-mayrhofer-did-dns-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 9, 2021) is 1050 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6116' is defined on line 322, but no explicit reference was found in the text == Unused Reference: 'RFC6117' is defined on line 328, but no explicit reference was found in the text == Unused Reference: 'RFC6335' is defined on line 333, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7553 -- Possible downref: Non-RFC (?) normative reference: ref. 'W3C-DID' Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Mayrhofer 3 Internet-Draft nic.at GmbH 4 Intended status: Standards Track D. Klesev 5 Expires: December 11, 2021 6 M. Sabadello 7 Danube Tech GmbH 8 June 9, 2021 10 The Decentralized Identifier (DID) in the DNS 11 draft-mayrhofer-did-dns-05 13 Abstract 15 This document specifies the use of the URI Resource Record Type to 16 publish Decentralized Identifiers (DIDs) in the DNS. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 11, 2021. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Use of the 'URI' RRType . . . . . . . . . . . . . . . . . . . 3 55 3.1. Owner Name Scoping, Target . . . . . . . . . . . . . . . 3 56 3.2. Weight, Priority . . . . . . . . . . . . . . . . . . . . 3 57 4. Location of the Records . . . . . . . . . . . . . . . . . . . 4 58 4.1. Host Names . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.2. Email Addresses (Experimental) . . . . . . . . . . . . . 4 60 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 6. Considered Alternatives . . . . . . . . . . . . . . . . . . . 4 62 7. Implementations . . . . . . . . . . . . . . . . . . . . . . . 5 63 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 11.1. draft-mayrhofer-did-dns-05 . . . . . . . . . . . . . . . 6 68 11.2. draft-mayrhofer-did-dns-04 . . . . . . . . . . . . . . . 6 69 11.3. draft-mayrhofer-did-dns-03 . . . . . . . . . . . . . . . 6 70 11.4. draft-mayrhofer-did-dns-02 . . . . . . . . . . . . . . . 6 71 11.5. draft-mayrhofer-did-dns-01 . . . . . . . . . . . . . . . 6 72 11.6. draft-mayrhofer-did-dns-00 . . . . . . . . . . . . . . . 6 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 12.2. Informative References . . . . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 Decentralized Identifiers (DIDs) [W3C-DID] use a Uniform Resource 81 Identifier (URI) scheme [RFC3986] to identify persons, organizations, 82 or things in decentralized infrastructure, such as blockchains and 83 distributed ledgers. 85 DIDs are structured around "methods", each method defining the syntax 86 of the "method specific identifier" and the operations on the 87 respective DIDs (See Section 3.2 of [W3C-DID] and [DID-METHODS]). 88 For many methods, the method specific identifier is not human- 89 friendly (such as hash values, referring to transactions on a 90 blockchain). Most DIDs are therefore inherently hard to memorize for 91 humans. 93 By referring to DIDs from the Domain Name System (DNS), those hard to 94 memorize identifiers can be discovered via well known, human friendly 95 and widely established names. This document specifies how DIDs can 96 be published in the DNS for discovery on the base of host names and 97 email addresses. 99 Since DIDs use a URI scheme ('did'), this specification leverages the 100 existing URI DNS Resource Record Type (RRType) [RFC7553]. Records 101 are scoped using the '_did' global underscore node name, as described 102 in Section 3.1. 104 2. Terminology 106 "Owner name", "Priority", "Weight" and "Target" refer to the 107 respective fields of the URI RRType, as specified in Section 4 of RFC 108 7553. 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 3. Use of the 'URI' RRType 118 DIDs use an URI scheme ('did:'), so the most suitable option to 119 publish DIDs in the DNS is the use of the 'URI' RRType. During the 120 development of this document, various alternatives were considered, 121 see Section 6 for a list. 123 o When Decentralized Identifiers (DIDs) are published in the DNS, 124 the 'URI' RRType MUST be used. 126 3.1. Owner Name Scoping, Target 128 [RFC8552] describes the advantages of scoping an existing RRType over 129 the definition (and complex deployment) of a new RRType. The "URI" 130 RRType is specifically mentioned as one example where scoping is 131 particularly useful (and part of the design). 133 When DIDs are published in the DNS 135 o the records MUST be scoped by setting the global (highest-level) 136 underscore name of the URI RRset to '_did' (0x5F 0x64 0x69 0x64), 138 o and the Target field of all records in the RRset MUST contain a 139 URI of the 'did:' URI scheme. 141 3.2. Weight, Priority 143 The semantics of the Weight and Priority fields remain. When a 144 client encounters a DID method it does not support, it SHOULD 145 consider the respective URI "unreachable" for the purpose of record 146 selection, and proceed to the record with the next-lowest-numbered 147 Priority, in accordance with Section 4.2 of RFC 7553. 149 4. Location of the Records 151 4.1. Host Names 153 In order to discover the set of DIDs associated with a Host Name, a 154 client prepends the given Host Name with the '_did' global underscore 155 name to create the Owner name, and then queries the resulting Query 156 Name for the URI RRType set. 158 4.2. Email Addresses (Experimental) 160 To discover DIDs associated with email addresses, the (experimental) 161 model from DNS-Based Authentication of Named Entities (DANE) Bindings 162 for OpenPGP [RFC7929] is used. A client prepares the email address 163 following the procedure outlined in Section 5 in RFC7929 the form the 164 Query Name, but in step 5 MUST use the string '_mailto._did' instead 165 of '_openpgpkey' as the second left-most label. Subsequently, the 166 client performs a DNS query, but MUST use the URI RRType as Query 167 Type (rather than the OPENPGPKEY RRType described in said section). 169 5. Example 171 The following example is a URI Resource Record which refers from the 172 host name "example.net" to a Decentralized Identifier using the 'sov' 173 method: 175 _did.example.net. IN URI 100 10 "did:sov:1234abcd" 177 6. Considered Alternatives 179 During the development of this document, the following alternatives 180 were considered: A dedicated RRType, TXT records, an Enumservice, 181 Well-Known URIs, direct registration in the Service Name Registry. 182 Using the URI RRType was found to be the option with the least impact 183 on existing specifications and highest interoperability potential. 184 Support for URI RRTypes is widespread in DNS software, which means 185 that implementation and deployment of the proposed protocol should be 186 possible without any changes to underlying infrastructure. 188 Furthermore, the Identifiers and Discovery Working Group of the 189 Decentralized Identity Foundation (DIF) is considering a .well-known 190 URL based approach to discovering DIDs from web sites. 192 7. Implementations 194 DNS-DID is considered for implementation in the following frameworks 195 / applications: 197 The "Registration" function of the "Fission" framework 198 (https://whitepaper.fission.codes/accounts/verifiable-claims) 200 8. Acknowledgements 202 Acknowledgements will be added here. 204 9. IANA Considerations 206 Per [RFC8552] IANA is requested to add the following entry to the 207 DNS Underscore Global Scoped Entry Registry: 209 +---------+-------------+-----------+ 210 | RR Type | _NODE NAME | REFERENCE | 211 +---------+-------------+-----------+ 212 | URI | _did | {THISRFC} | 213 +---------+-------------+-----------+ 215 Table 1: Underscore Global Registry Entry Registration for '_did' 217 Note to RFC Editor: Please replace the above "{THISRFC}" text with 218 a reference to this document's RFC number. 220 Note that IANA has already created a provisional URI scheme 221 registration for the 'did:' scheme itself. 223 10. Security Considerations 225 Most of the considerations outlined in the base specification of the 226 URI RRType (RFC7553) also apply to the DID use case - particularly 227 the concerns around downgrade attacks when the record is not signed 228 with the help of DNSSEC. Note that the DID resolving process itself 229 (out of scope of this document) can provide additional security 230 information. The "Linked Domain Service Endpoint" of a DID document 231 can be used to back-reference to the Domain which was originally used 232 to discover that DID. Such a "closed loop" (similar to verifying DNS 233 reverse lookups against their corresponding forward lookups) would 234 increase the confidence in non-DNSSEC scenarios. 236 Including a DID in the DNS allows for correlation of that DID with 237 DNS information (and potentially registration information of that DNS 238 name). Therefore DIDs which are supposed to be private SHOULD NOT be 239 added to the DNS. 241 11. Changes 243 [Note to RFC Editors: This whole section is to be removed before 244 publication] 246 11.1. draft-mayrhofer-did-dns-05 248 o Adding "implementation" section 250 11.2. draft-mayrhofer-did-dns-04 252 o Reworded "Alternatives" 254 o Added text about backreference using DID's Linked Domain Service 255 Endpoint. 257 11.3. draft-mayrhofer-did-dns-03 259 o Updated DID spec to v1.0 document 261 o Minor editorial changes to make text more clear. 263 11.4. draft-mayrhofer-did-dns-02 265 o Updated attrleaf reference to RFC8552 267 o Changed author information for D. Klesev 269 o Added sentence on .well-known discovery scheme 271 11.5. draft-mayrhofer-did-dns-01 273 o email addresses further scoped with '_mailto._did' 275 o Changed protocol registration to attrleaf drafts 277 o Made clear requirements regarding use of the URI scheme 279 o Added privacy aspect to security considerations 281 11.6. draft-mayrhofer-did-dns-00 283 o Initial version 285 12. References 287 12.1. Normative References 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, 291 DOI 10.17487/RFC2119, March 1997, 292 . 294 [RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource 295 Identifier (URI) DNS Resource Record", RFC 7553, 296 DOI 10.17487/RFC7553, June 2015, 297 . 299 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 300 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 301 May 2017, . 303 [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource 304 Records through "Underscored" Naming of Attribute Leaves", 305 BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, 306 . 308 [W3C-DID] W3C, W3C., "Decentralized Identifiers (DIDs) v1.0", 309 February 2020, . 311 12.2. Informative References 313 [DID-METHODS] 314 W3C, W3C., "DID Method Registry", June 2018, 315 . 317 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 318 Resource Identifier (URI): Generic Syntax", STD 66, 319 RFC 3986, DOI 10.17487/RFC3986, January 2005, 320 . 322 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 323 Uniform Resource Identifiers (URI) Dynamic Delegation 324 Discovery System (DDDS) Application (ENUM)", RFC 6116, 325 DOI 10.17487/RFC6116, March 2011, 326 . 328 [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA 329 Registration of Enumservices: Guide, Template, and IANA 330 Considerations", RFC 6117, DOI 10.17487/RFC6117, March 331 2011, . 333 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 334 Cheshire, "Internet Assigned Numbers Authority (IANA) 335 Procedures for the Management of the Service Name and 336 Transport Protocol Port Number Registry", BCP 165, 337 RFC 6335, DOI 10.17487/RFC6335, August 2011, 338 . 340 [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities 341 (DANE) Bindings for OpenPGP", RFC 7929, 342 DOI 10.17487/RFC7929, August 2016, 343 . 345 Authors' Addresses 347 Alexander Mayrhofer 348 nic.at GmbH 349 Karlsplatz 1/2/9 350 Vienna 1010 351 Austria 353 Email: alex.mayrhofer.ietf@gmail.com 355 Dimitrij Klesev 357 Email: dimitrij.klesev@gmail.com 359 Markus Sabadello 360 Danube Tech GmbH 361 Annagasse 8/1/8 362 Vienna 1010 363 Austria 365 Email: markus@danubetech.com