The Decentralized Identifier (DID) in the DNS
draft-mayrhofer-did-dns-02

Document Type Active Internet-Draft (individual)
Last updated 2019-08-26
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                       A. Mayrhofer
Internet-Draft                                               nic.at GmbH
Intended status: Standards Track                               D. Klesev
Expires: February 26, 2020
                                                            M. Sabadello
                                                        Danube Tech GmbH
                                                         August 25, 2019

             The Decentralized Identifier (DID) in the DNS
                       draft-mayrhofer-did-dns-02

Abstract

   This document specifies the use of the URI Resource Record Type to
   publish Decentralized Identifiers (DIDs) in the DNS.

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 February 26, 2020.

Copyright Notice

   Copyright (c) 2019 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Mayrhofer, et al.       Expires February 26, 2020               [Page 1]
Internet-Draft           draft-mayrhofer-did-dns             August 2019

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Use of the 'URI' RRType . . . . . . . . . . . . . . . . . . .   3
     3.1.  Owner Name Scoping, Target  . . . . . . . . . . . . . . .   3
     3.2.  Weight, Priority  . . . . . . . . . . . . . . . . . . . .   3
   4.  Location of the Records . . . . . . . . . . . . . . . . . . .   4
     4.1.  Host Names  . . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Email Addresses (Experimental)  . . . . . . . . . . . . .   4
   5.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Considered Alternatives . . . . . . . . . . . . . . . . . . .   4
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   10. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     10.1.  draft-mayrhofer-did-dns-02 . . . . . . . . . . . . . . .   5
     10.2.  draft-mayrhofer-did-dns-01 . . . . . . . . . . . . . . .   6
     10.3.  draft-mayrhofer-did-dns-00 . . . . . . . . . . . . . . .   6
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   6
     11.2.  Informative References . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Decentralized Identifiers (DIDs) [W3C-DID] use a Uniform Resource
   Identifier (URI) scheme [RFC3986] 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 [W3C-DID] and [DID-METHODS]).
   For many methods, the method specific identifier is not human-
   friendly (for example, hash values referring to transactions on a
   blockchain).  Most DIDs are therefore inherently hard to memorize for
   humans.

   By referring to DIDs from the 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) [RFC7553].  Records

Mayrhofer, et al.       Expires February 26, 2020               [Page 2]
Internet-Draft           draft-mayrhofer-did-dns             August 2019

   are scoped using the '_did' global underscore node name, as described
   in Section 3.1.

2.  Terminology

   "Owner name", "Priority", "Weight" and "Target" refer to the
   respective fields of the URI RRType, as specified in Section 4 of
   RFC7553.

   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.

3.  Use of the 'URI' RRType

   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 Section 6 for a list.

   o  When Decentralized Identifiers (DIDs) are published in the DNS,
      the 'URI' RRType MUST be used.

3.1.  Owner Name Scoping, Target

   [RFC8552] 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

   o  the records MUST be scoped by setting the global (highest-level)
      underscore name of the URI RRset to '_did' (0x5F 0x64 0x69 0x64),

   o  and the Target field of all records in the RRset MUST contain a
      URI of the 'did:' URI scheme.

3.2.  Weight, Priority

   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 DID "unreachable" for the purpose of record
   selection, and proceed to the URI with the next-lowest-numbered
   Priority, in accordance with Section 4.2 of RFC 7553.

Mayrhofer, et al.       Expires February 26, 2020               [Page 3]
Internet-Draft           draft-mayrhofer-did-dns             August 2019

4.  Location of the Records

4.1.  Host Names

   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.

4.2.  Email Addresses (Experimental)

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

5.  Example

   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"

6.  Considered Alternatives

   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.
   Updating the URI specification was found to be the option with the
   highest likeliness of interoperability combined with the lowest
   effort in standardization and implementation/deployment.

   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.

7.  Acknowledgements

   Acknowledgements will be added here.

Mayrhofer, et al.       Expires February 26, 2020               [Page 4]
Internet-Draft           draft-mayrhofer-did-dns             August 2019

8.  IANA Considerations

      Per [RFC8552] IANA is requested to add the following entry to the
      DNS Underscore Global Scoped Entry Registry:

                   +---------+-------------+-----------+
                   | RR Type | _NODE NAME  | REFERENCE |
                   +---------+-------------+-----------+
                   | URI     | _did        | {THISRFC} |
                   +---------+-------------+-----------+

     Table 1: Underscore Global Registry Entry Registration for '_did'

   Note to RFC Editor:   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.

9.  Security Considerations

   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 (such as a backreference to the DNS domain name).

   Including a DID in the DNS allows to correlate that DID with DNS
   information, and is therefore NOT RECOMMENDED for DIDs which are
   supposed to be private.

10.  Changes

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

10.1.  draft-mayrhofer-did-dns-02

   o  Updated attrleaf reference to RFC8552

   o  Changed author information for D.  Klesev

   o  Added sentence on .well-known discovery scheme

Mayrhofer, et al.       Expires February 26, 2020               [Page 5]
Internet-Draft           draft-mayrhofer-did-dns             August 2019

10.2.  draft-mayrhofer-did-dns-01

   o  email addresses further scoped with '_mailto._did'

   o  Changed protocol registration to attrleaf drafts

   o  Made clear requirements regarding use of the URI scheme

   o  Added privacy aspect to security considerations

10.3.  draft-mayrhofer-did-dns-00

   o  Initial version

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7553]  Faltstrom, P. and O. Kolkman, "The Uniform Resource
              Identifier (URI) DNS Resource Record", RFC 7553,
              DOI 10.17487/RFC7553, June 2015,
              <https://www.rfc-editor.org/info/rfc7553>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8552]  Crocker, D., "Scoped Interpretation of DNS Resource
              Records through "Underscored" Naming of Attribute Leaves",
              BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
              <https://www.rfc-editor.org/info/rfc8552>.

   [W3C-DID]  W3C, W3C., "Decentralized Identifiers (DIDs) v0.11", July
              2018, <https://w3c-ccg.github.io/did-spec/>.

11.2.  Informative References

   [DID-METHODS]
              W3C, W3C., "DID Method Registry", June 2018,
              <https://w3c-ccg.github.io/did-method-registry/>.

Mayrhofer, et al.       Expires February 26, 2020               [Page 6]
Internet-Draft           draft-mayrhofer-did-dns             August 2019

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC6116]  Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
              Uniform Resource Identifiers (URI) Dynamic Delegation
              Discovery System (DDDS) Application (ENUM)", RFC 6116,
              DOI 10.17487/RFC6116, March 2011,
              <https://www.rfc-editor.org/info/rfc6116>.

   [RFC6117]  Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA
              Registration of Enumservices: Guide, Template, and IANA
              Considerations", RFC 6117, DOI 10.17487/RFC6117, March
              2011, <https://www.rfc-editor.org/info/rfc6117>.

   [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
              Cheshire, "Internet Assigned Numbers Authority (IANA)
              Procedures for the Management of the Service Name and
              Transport Protocol Port Number Registry", BCP 165,
              RFC 6335, DOI 10.17487/RFC6335, August 2011,
              <https://www.rfc-editor.org/info/rfc6335>.

   [RFC7929]  Wouters, P., "DNS-Based Authentication of Named Entities
              (DANE) Bindings for OpenPGP", RFC 7929,
              DOI 10.17487/RFC7929, August 2016,
              <https://www.rfc-editor.org/info/rfc7929>.

Authors' Addresses

   Alexander Mayrhofer
   nic.at GmbH
   Karlsplatz 1/2/9
   Vienna  1010
   Austria

   Email: alex.mayrhofer.ietf@gmail.com

   Dimitrij Klesev

   Email: dimitrij.klesev@gmail.com

Mayrhofer, et al.       Expires February 26, 2020               [Page 7]
Internet-Draft           draft-mayrhofer-did-dns             August 2019

   Markus Sabadello
   Danube Tech GmbH
   Annagasse 8/1/8
   Vienna  1010
   Austria

   Email: markus@danubetech.com

Mayrhofer, et al.       Expires February 26, 2020               [Page 8]