High Assurance DIDs with DNS
draft-carter-high-assurance-dids-with-dns-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Jesse Carter , Jacques Latour , Mathieu Glaude , Tim Bouma | ||
| Last updated | 2024-03-21 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-carter-high-assurance-dids-with-dns-00
Network Working Group J. Carter
Internet-Draft J. Latour
Intended status: Informational CIRA
Expires: 22 September 2024 M. Glaude
NorthernBlock
T. Bouma
Digital Governance Council
21 March 2024
High Assurance DIDs with DNS
draft-carter-high-assurance-dids-with-dns-00
Abstract
This document outlines a method for improving the authenticity,
discoverability, and portability of Decentralized Identifiers (DIDs)
by utilizing the current DNS infrastructure and its technologies.
This method offers a straightforward procedure for a verifier to
cryptographically cross-validate a DID using data stored in the DNS,
separate from the DID document.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://ciralabs.github.io/high-assurance-dids-with-dns/draft-carter-
high-assurance-dids-with-dns.html. Status information for this
document may be found at https://datatracker.ietf.org/doc/draft-
carter-high-assurance-dids-with-dns/.
Source for this draft and an issue tracker can be found at
https://github.com/CIRALabs/high-assurance-dids-with-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/.
Carter, et al. Expires 22 September 2024 [Page 1]
Internet-Draft hiadid March 2024
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 22 September 2024.
Copyright Notice
Copyright (c) 2024 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Securing a DID using the DNS . . . . . . . . . . . . . . . . 4
3.1. Specifically for did:web . . . . . . . . . . . . . . . . 4
3.2. Other DID methods . . . . . . . . . . . . . . . . . . . . 4
3.3. DIDs with URI records . . . . . . . . . . . . . . . . . . 5
3.3.1. URI record scoping . . . . . . . . . . . . . . . . . 5
3.3.2. Issuer Handles . . . . . . . . . . . . . . . . . . . 5
3.4. PKI with TLSA records . . . . . . . . . . . . . . . . . . 6
3.4.1. TLSA Record Scoping, Selector Field . . . . . . . . . 6
3.4.2. Issuer Handles . . . . . . . . . . . . . . . . . . . 6
3.4.3. Instances of Multiple DIDs . . . . . . . . . . . . . 7
3.4.4. Instances of Multiple Key Pairs . . . . . . . . . . . 7
3.4.5. Benefits of Public Keys in the DNS . . . . . . . . . 7
4. Role of DNSSEC for Assurance and Revocation . . . . . . . . . 8
5. Digital Signature and Proof Value of the DID Document . . . . 8
6. Verification Process . . . . . . . . . . . . . . . . . . . . 9
6.1. Verification Failure . . . . . . . . . . . . . . . . . . 10
7. Control Requirements . . . . . . . . . . . . . . . . . . . . 10
8. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. W3C Considerations . . . . . . . . . . . . . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Carter, et al. Expires 22 September 2024 [Page 2]
Internet-Draft hiadid March 2024
1. Introduction
In the ever-evolving digital world, the need for secure and
verifiable identities is paramount. DIDs have emerged as a promising
solution, providing a globally unique, persistent identifier that
does not require a centralized registration authority. However, like
any technology, DIDs face challenges in terms of authenticity,
discoverability, and portability.
This is where the Domain Name System (DNS), a well-established and
globally distributed internet directory service, comes into play. By
leveraging the existing DNS infrastructure, we can enhance the
verification process of DIDs. Specifically, we can use Transport
Layer Security Authentication (TLSA) and Uniform Resource Identifier
(URI) DNS records to add an additional layer of verification and
authenticity to DIDs.
TLSA records in DNS allow us to associate a certificate or public key
with the domain name where the record is found, thus providing a form
of certificate pinning. URI records, on the other hand, provide a
way to publish mappings from hostnames to URIs, such as DIDs.
By storing crucial information about a DID, such as the DID itself
and its Public Key Infrastructure (PKI) in these DNS records, we can
provide a verifier with a simple yet effective method to cross-
validate and authenticate a DID. This not only ensures the
authenticity of the DID document but also allows for interaction with
material signed by the DID without access to the DID document itself.
In essence, the integration of DIDs with DNS, specifically through
the use of TLSA and URI records, provides a robust solution to some
of the challenges faced by DIDs, paving the way for a more secure and
trustworthy digital identity landscape.
2. Conventions and Definitions
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.
Carter, et al. Expires 22 September 2024 [Page 3]
Internet-Draft hiadid March 2024
3. Securing a DID using the DNS
Much like presenting two pieces of ID to provide a higher level of
assurance when proving your identity or age, replicating important
information about a DID into a different domain (like the DNS)
enables a similar form of cross validation. This enhances the
initial trust establishment between the user and the DID document, as
the key information can be compared and verified across two
segregated sets of infrastructure. This also acts as a form of
ownership verification in a similar way to 2FA, as the implementer
must have control over both the DNS zone and the DID document to
properly duplicate the relevant information.
+----------------+ +----------------+ | | | | | DNS Server | | Web
Server | | | | | | +-------+ | | +-------+ | | | DID |<---+-----+-->|
DID | | | +-------+ | | +-------+ | | +-------+ | | +-------+ | | |
PKI |<---+-----+-->| PKI | | | +-------+ | | +-------+ | | | | |
+----------------+ +----------------+
The diagram above illustrates how a web server storing the DID
document, and the DNS server storing the URI and TLSA records shares
and links the key information about the DID accross to independant
sets of infrastructure.
3.1. Specifically for did:web
With did:web, there’s an inherent link between the DNS needed to
resolve the associated DID document and the domain where the relevant
supporting DNS records are located. This means that the domain
specified by the did:web identifier (for example,
did:web:*example.ca*) is also the location where you can find the
supporting DNS records.
3.2. Other DID methods
In the case of other DID methods, the association between a DID and a
DNS domain is still possible although less obvious than with the
aformentioned did:web. The W3C DID Core spec supports multiple ways
of creating the association between a DID to a domain. This is most
intuitively accomplished using one of two different fields.
*alsoKnownAs*: The assertion that two or more DIDs (or other types of
URI, such as a domain name) refer to the same DID subject can be made
using the [alsoKnownAs] property.
Carter, et al. Expires 22 September 2024 [Page 4]
Internet-Draft hiadid March 2024
*Services*: Alternatively, [services] are used in DID documents to
express ways of communicating with the DID subject or associated
entities. In this case we are referring specifically to the
"LinkedDomains" service type.
3.3. DIDs with URI records
However, this association stemming only from the DID is
unidirectional. By leveraging URI records as outlined in
[DID-in-the-DNS], we can create a bidirectional relationship,
allowing a domain to publish their associated DIDs in the DNS.
*_Ex: _did.example-issuer.ca IN URI 1 0 “did:example:XXXXXXX”_*
This relationship enhances security, as an entity would require
control over both the DID and the domain’s DNS server to create this
bidirectional association, reducing the likelihood of malicious
impersonation.
The ability for an organization to publish a list of their DIDs on
the DNS is also beneficial as it establishes a link between the DNS,
which is ubiquitously supported, and the distributed ledger (or other
places) where the DID document resides on which may not have the same
degree of access or support, enhancing discoverability.
3.3.1. URI record scoping
* The records MUST be scoped by setting the global underscore name
of the URI RRset to __did_ (0x5F 0x64 0x69 0x64).
3.3.2. Issuer Handles
An issuer may have multiple sub entities issuing credentials on their
behalf, such as the different faculties in a university issuing
diplomas. Each of these entities may have one or more DIDs of their
own. For this reason, the introduction of an issuer handle,
represented as a subdomain in the resource record name, provides a
simple way to facilitate the distinction of DIDs, their public keys,
and credentials they issue in their relationship to an issuer or root
authority.
*_Ex: _did.diplomas.example-issuer.ca IN URI 1 0
“did:example:XXXXXXX”_*
*_Ex: _did.certificates.example-issuer.ca IN URI 1 0
“did:example:XXXXXXX”_*
Carter, et al. Expires 22 September 2024 [Page 5]
Internet-Draft hiadid March 2024
3.4. PKI with TLSA records
The DID to DNS mapping illustrated in section 4 provides a way of
showing the association between a DID and a domain, but no way of
verifying that relationship. By hosting the public keys of that DID
in its related domain’s zone, we can provide a cryptographic linkage
to bolster this relationship while also providing access to the DID’s
public keys outside of the infrastructure where the DID document
itself resides, facilitating interoperability. If a verifier is
presented with a credential issued or signed by a DID using a method
they do not support, they would have the option to perform the
cryptographic verification of the credential's signature using the
public key stored in the DNS.
TLSA records [RFC6698] provide a simple way of hosting cryptographic
information in the DNS.
3.4.1. TLSA Record Scoping, Selector Field
When public keys related to DIDs are published in the DNS as TLSA
records:
* The records MUST be scoped by setting the global underscore name
of the TLSA RRset to __did_ (0x5F 0x64 0x69 0x64).
* The Selector Field of the TLSA record must be set to 1,
SubjectPublicKeyInfo: DER-encoded binary structure as defined in
[RFC5280].
3.4.2. Issuer Handles
As mentioned in section 4.2, an issuer may have multiple sub entities
issuing credentials on their behalf, likely with their own set or
sets of keypairs. Because these keypairs will need to be represented
in the DNS as TLSA records, the use of an issuer handle as outlined
in section 4.2 will facilitate the distinction of the different
public keys in their relation to the issuer.
*_Ex: _did.diplomas.example-issuer.ca IN TLSA 3 1 0
“4e18ac22c00fb9...b96270a7b2”_*
*_Ex: _did.certificates.example-issuer.ca IN TLSA 3 1 0
“4e18ac22c00fb9...b96270a7b3”_*
Carter, et al. Expires 22 September 2024 [Page 6]
Internet-Draft hiadid March 2024
3.4.3. Instances of Multiple DIDs
It is also likely an issuer may be using or wish to associate
multiple DIDs with a single domain or subdomain. In this case it is
possible to expand the name of the RRset using both the related DID
method and identifier to more clearly associate the public key and
its corresponding DID. In this circumstance, we propose using
another 2 additional sub names, the first following the _did global
identifier denoting the method, and the second denoting the DID's id.
*_Ex: _did.example.123abc.example-issuer.ca IN TLSA 3 1 0
“4e18ac22c00fb9...b96270a7b2”_*
*_Ex: _did.example2.456abc.example-issuer.ca IN TLSA 3 1 0
“4e18ac22c00fb9...b96270a7b3”_*
3.4.4. Instances of Multiple Key Pairs
Depending on the needs of the issuer, it is possible they may use
multiple keypairs associated with a single DID to sign and issue
credentials. In this case, a TLSA record will be created per
[verificationMethod] and then be bundled into the corresponding TLSA
RRset. A resolver can then parse the returned records for the
corresponding verificationMethod they wish to interact with or
verify.
*_Ex: _did.example-issuer.ca IN TLSA 3 1 0
"4e18ac22c00fb9...b96270a7b4"_* *_Ex: _did.example-issuer.ca IN TLSA
3 1 0 "4e18ac22c00fb9...b96270a7b5"_*
3.4.5. Benefits of Public Keys in the DNS
Hosting the public keys in TLSA records provides a stronger mechanism
for the verifier to verify the issuer with, as they are able to
perform a cryptographic challenge against the DID using the
corresponding TLSA records, or against the domain using the
corresponding [verificationMethod] in the DID document. The
accessibility of the public keys is also beneficial, as the verifier
does not need to resolve the DID document using a did method they do
not support to access the key material. This limits the burden of
having to interoperate with a multitude of different did methods and
for credential verification, facilitating interoperability and
adoption.
Carter, et al. Expires 22 September 2024 [Page 7]
Internet-Draft hiadid March 2024
4. Role of DNSSEC for Assurance and Revocation
It is hihgly recommended that all the participants in this digital
identity ecosystem enable DNSSEC signing for the DNS instances they
operate. See [RFC9364].
DNSSEC provides cryptographic assurance that the DNS records returned
in response to a query are authentic and have not been tampered with.
This assurance within the context of the __did_ URI and __did_ TLSA
records provides another mechanism to ensure the integrity of the DID
and its public keys outside of infrastructure it resides on directly
from the domain of its owner.
Within this use-case, DNSSEC also provides revocation checks for both
DIDs and public keys. In particular, a DNS query for a specific
__did_ URI record or __did_ TLSA record can return an NXDOMAIN
[RFC8020] response if the DID or public key has been revoked. This
approach can simplify the process of verifying the current validity
of DIDs and public keys by reducing the need for complex revocation
mechanisms or implementation specific technologies.
5. Digital Signature and Proof Value of the DID Document
Digital signatures ensure the integrity of the DID Document, and by
extent the public keys, authentication protocols, and service
endpoints necessary for initiating trustworthy interactions with the
identified entity. The use of digital signatures in this context
provides a robust mechanism for verifying that the DID Document has
not been tampered with and indeed originates from the correct entity.
In accordance with W3C specifications, we propose including a data
integrity proof such as those outlined in [dataIntegrityProofECDSA]
and [dataIntegrityProofEdDSA], with the mandatory inclusions of the
"created" and "expiry" fields. The inclusion of which acts as a
lifespan for the document, similar to the TTL for a DNS record.
Depending on the use case and security requirement, a longer or
shorter expiry period would be used as necessary.
javascript "proof": { "type": "DataIntegrityProof", "cryptosuite":
"ecdsa-jfc-2019", "created": "2023-10-11T15:27:27Z", "expires":
"2099-10-11T15:27:27Z", "verificationMethod":
"did:web:trustregistry.ca#key-1", }
Carter, et al. Expires 22 September 2024 [Page 8]
Internet-Draft hiadid March 2024
The data integrety proof SHOULD be signed using a verificationMethod
that has an associated TLSA record to allow for the verification of
the data integrity proof using data contained outside of the DID
document. This provides an added layer of authenticity, as the
information contained in the DID document would need to be supported
accross 2 different domains.
6. Verification Process
Using the new DNS records and proof object in the DID document, we
enable a more secure and higher assurance verification process for
the DID. It is important to note that while not strictly necessary,
DNSSEC verification should be performed each time a DNS record is
resolved to ensure authenticity.
1. *Initial presentation:* The user is presented with a DID
document, ex. did:web:example.ca.
2. *Verification of the DID:* The user verifies the DID is
represented as a URI record in the associated domain.
1. In the case of did:web, the domain to be queried is indicated
by the last segment of the did. ex. *did:web:example.ca ->
_did.example.ca*
2. In the case of other did methods, the domain to be queried is
indicated by the value held in the "alsoKnownAs" or "service"
fields.
1. ex. javascript {"alsoKnownAs": "example.ca"} ->
_did.example.ca
2. ex. javascript {"services": [{
"id":"did:example:123abc#linked-domain", "type":
"LinkedDomains", "serviceEndpoint": "https://example.ca"
-> _did.example.ca }] }
3. *Verification of the PKI:* With the association between the DID
and the domain verified, the user would then proceed to verify
the key material between the DID and the domain.
1. The user would query for a TLSA record. Depending on the
record/s returned, the user would verify either the hash of
the verificationMethod or verificationMethod itself matches
what was returned by the TLSA record content.
Carter, et al. Expires 22 September 2024 [Page 9]
Internet-Draft hiadid March 2024
1. Note: This may require some conversion, as TLSA records
store key material as hex encoded DER format, and this
representation is not supported by [verificationMethod].
However, there are many well supported cryptography
libraries in a variety of languages that facilitate the
conversion process.
4. *Verification of the DID document's integrity:* After verifying
that the did's key material matches what is represented in the
TLSA records of the associated domain, the user would then verify
the "proof" object to ensure the integrity of the DID document.
1. This can be accomplished by using either the
[verificationMethod] directly from the did document, or using
the key material stored in the TLSA record. Using the TLSA
record would provide a higher level of assurance as this
confirms the key material is being accurately represented
accross 2 different domains, both at the DID document level
and the DNS level.
2. As mentioned above, if using the TLSA record, some conversion
will be necessary to convert the DER format public key to
whatever is required by the proof's cryptosuite.
6.1. Verification Failure
If at any given step verification fails, the DID document should be
deemed INSECURE. Whether it is due to the DID and DNS being out of
sync with recent updates, or the DID document or DNS zone themselves
have been compromised, it is highly advised that the user stop
interacting with the given DID until verification succeeds and cross-
verification is restored.
7. Control Requirements
This section defines a simple framework to define a set of technical
controls that can be implemented and mapped into levels of assurance
for did:web identifiers.
To assist in decision-making and implementation, The controls are
ordered in increasing level of security assurance and are grouped
into levels of assurance from *LOW-* to *HIGH+*
* *Issuing Authority* is the entity accountable for the did:web
identifier.
* *Issuing Service* is the entity responsible for operating the
did:web identifier insfrastructure.
Carter, et al. Expires 22 September 2024 [Page 10]
Internet-Draft hiadid March 2024
In many cases the *Issuing Authority* may delegate elements of
providing a high assurance did:web identitifier to an *Issuing
Service* that may be a commercial provider.
In the simplest case, the *Issuing Authority* can be regarded as the
same as the *Issuing Service*.
Note that Controls 9, 10, and 11 CANNOT BE DELEGATED to an *Issuing
Service*
11 technical controls are defined. These controls would be
implemented in order of precedence for an increasing level of
security assurance. (e.g., Control No. N would need to be
implemented before implementing Control No. N+1)
+=========+============+==========================================+
| Control | Control | Description |
| No. | Name | |
+=========+============+==========================================+
| 1 | DID | The Issuing Service MUST control the |
| | Resource | resource that generates the DID |
| | Control | document. (i.e., website) |
+---------+------------+------------------------------------------+
| 2 | DID | The Issuing Service MUST have the |
| | Document | ability to do CRUD operations on the DID |
| | Management | document. |
+---------+------------+------------------------------------------+
| 3 | DID | The Issuing Service MUST ensure the data |
| | Document | integrity of the DID document by |
| | Data | cryptographic means, typically a digital |
| | Integrity | signature or other means. The use of |
| | | approved or established cryptographic |
| | | algorithmsis HIGHLY RECOMMENDED |
+---------+------------+------------------------------------------+
| 4 | DID | The Issuing Service MUST control the |
| | Document | keys required to sign the DID document. |
| | Key | |
| | Control | |
+---------+------------+------------------------------------------+
| 5 | DID | With proper delegation from the Issuing |
| | Document | Authority, the DID Document signing key |
| | Key | MAY be generated by the Issuing Service. |
| | Generation | Otherwise, the signing key must be |
| | | generated by the Issuing Authority. |
+---------+------------+------------------------------------------+
| 6 | Domain | The Issuing Service MUST have control of |
| | Zone | the domain zone (or subdomain zone).If |
| | Control | direct control of the domain is not |
Carter, et al. Expires 22 September 2024 [Page 11]
Internet-Draft hiadid March 2024
| | | feasible, the use of an accredited DNS |
| | | provider is HIGHLY RECOMMENDED |
+---------+------------+------------------------------------------+
| 7 | Domain | There MUST be domain zone records that |
| | Zone | map the necessary URI, TLSA, CERT and/or |
| | Mapping | TXT records to the specified did:web |
| | | identifier. |
+---------+------------+------------------------------------------+
| 8 | Domain | The domain zone records MUST be signed |
| | Zone | according to DNSSEC. (RRSIG) |
| | Signing | |
+---------+------------+------------------------------------------+
| 9 | Domain | The Issuing Authority MUST have control |
| | Zone | over the domain zone keys used for |
| | Signing | signing and delegation. (KSK and ZSK) |
| | Key | |
| | Control | |
+---------+------------+------------------------------------------+
| 10 | Domain | The signing keys MUST be generated under |
| | Zone | the control of the Issuing Authority. |
| | Signing | |
| | Key | |
| | Generation | |
+---------+------------+------------------------------------------+
| 11 | Hardware | A FIPS 140-2 compliant hardware security |
| | Security | module must be under the control of the |
| | Module | Issuing Authority. |
+---------+------------+------------------------------------------+
Table 1
8. Levels of Assurance
Many trust frameworks specify levels of assurance to assist in
determing which controls must be implemented.
The following table is not a definitive mapping to trust framework
levels of assurance. It is intended to assist in determing mappings
by grouping the controls within a range from *LOW-* to *HIGH+*
relating to the appropriate risk level. Note that controls are
additive in nature. (i.e.,, controls of the preceding level must be
fulfilled).
Carter, et al. Expires 22 September 2024 [Page 12]
Internet-Draft hiadid March 2024
+===========+==========+=====================================+
| Level of | Controls | Description |
| Assurance | | |
+===========+==========+=====================================+
| *LOW-* | Control | SHOULD only be used for low risk |
| | 1 | transactions where attribution to |
| | | originator is desireable. |
+-----------+----------+-------------------------------------+
| *LOW* | Control | SHOULD only be used for lower risk |
| | 2 | transactions where establishing the |
| | | accountablity of the originator is |
| | | desirable. |
+-----------+----------+-------------------------------------+
| *MEDIUM* | Controls | MAY be used for medium risk |
| | 3, 4 and | commercial transactions, such as |
| | 5 | correspondence, proposals, etc. |
+-----------+----------+-------------------------------------+
| *MEDIUM+* | Controls | MAY be used for higher risk |
| | 6 and 7 | transcations, such as signing and |
| | | verifying invoices, contracts, or |
| | | official/legal docmentation |
+-----------+----------+-------------------------------------+
| *HIGH* | Controls | MUST be high risk transactions, |
| | 8, 9 and | such as government transactions for |
| | 10 | signing and verifying licenses, |
| | | certifications or identification |
+-----------+----------+-------------------------------------+
| *HIGH+* | Control | MUST be used for extremely high |
| | 11 | risk transactions where there may |
| | | be systemic or national security |
| | | implications |
+-----------+----------+-------------------------------------+
Table 2
9. Security Considerations
TODO Security
10. IANA Considerations
Per [RFC8552], IANA is requested to add the following entries to the
"Underscored and Globally Scoped DNS Node Names" registry:
Carter, et al. Expires 22 September 2024 [Page 13]
Internet-Draft hiadid March 2024
+---------+------------+-------------------------------------------+
| RR Type | _NODE NAME | Reference |
+---------+------------+-------------------------------------------+
| TLSA | _did | [draft-ietf-high-assurance-dids-with-dns] |
| URI | _did | [draft-mayrhofer-did-dns-01] |
+---------+------------+------------------------------------------+.
11. References
11.1. Normative References
[alsoKnownAs]
"Decentralized Identifiers (DIDs) v1.0", n.d.,
<https://www.w3.org/TR/did-core/#also-known-as>.
[dataIntegrityProofECDSA]
"Data Integrity ECDSA Cryptosuites v1.0", n.d.,
<https://www.w3.org/TR/vc-di-ecdsa/#proof-
representations>.
[dataIntegrityProofEdDSA]
"Data Integrity ECDSA Cryptosuites v1.0", n.d.,
<https://www.w3.org/TR/vc-di-eddsa/#proof-
representations>.
[DID-in-the-DNS]
"The Decentralized Identifier (DID) in the DNS", n.d.,
<https://datatracker.ietf.org/doc/html/draft-mayrhofer-
did-dns-05#section-2>.
[DID-Specification-Registries]
"DID Specification Registries", n.d.,
<https://www.w3.org/TR/did-spec-registries/#did-methods>.
[issuer] "Verifiable Credentials Data Model v2.0", n.d.,
<https://www.w3.org/TR/vc-data-model-2.0/#issuer>.
[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/rfc/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
Carter, et al. Expires 22 September 2024 [Page 14]
Internet-Draft hiadid March 2024
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/rfc/rfc6698>.
[RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
November 2016, <https://www.rfc-editor.org/rfc/rfc8020>.
[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/rfc/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/rfc/rfc8552>.
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/rfc/rfc9364>.
[services] "Decentralized Identifiers (DIDs) v1.0", n.d.,
<https://www.w3.org/TR/did-core/#services>.
[verificationMethod]
"Decentralized Identifiers (DIDs) v1.0", n.d.,
<https://www.w3.org/TR/did-core/#verification-methods>.
[W3C-VC-Data-Model]
"Verifiable Credentials Data Model v1.1", n.d.,
<https://www.w3.org/TR/vc-data-model/>.
11.2. Informative References
[Self-Sovereign-Identity]
Reed, D. and A. Preukschat, "Self-Sovereign Identity",
ISBN 9781617296598, 2021.
Appendix A. W3C Considerations
1. We propose the inclusion of an optional data integrity proof for
the DID document, as outlined in [dataIntegrityProofECDSA] and
[dataIntegrityProofEdDSA].
2. We propose the inclusion of an optional TTL ("timeToLive") field
in the DID document to indicate the amount of time a resolver
should cache the document.
Carter, et al. Expires 22 September 2024 [Page 15]
Internet-Draft hiadid March 2024
Acknowledgments
TODO acknowledge.
Authors' Addresses
Jesse Carter
CIRA
Email: jesse.carter@cira.ca
Jacques Latour
CIRA
Email: jacques.latour@cira.ca
Mathieu Glaude
NorthernBlock
Email: mathieu@northernblock.io
Tim Bouma
Digital Governance Council
Email: tim.bouma@dgc-cgn.org
Carter, et al. Expires 22 September 2024 [Page 16]