Internet DRAFT - draft-latour-dns-and-digital-trust
draft-latour-dns-and-digital-trust
Network Working Group J. Carter
Internet-Draft J. Latour
Intended status: Informational CIRA
Expires: 12 April 2024 M. Glaude
NorthernBlock
10 October 2023
Leveraging DNS in Digital Trust: Credential Exchanges and Trust
Registries
draft-latour-dns-and-digital-trust-01
Abstract
This memo describes an architecture for digital credential
verification and validation using Decentralized Identifiers (DIDs),
distributed ledgers, trust registries, and the DNS. This
architecture provides a verifier with a simple process by which to
cryptographically verify the credential they are being presented
with, verify and resolve the issuer of that credential to a domain,
and verify that issuer's membership in a trust registry.
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/DNS-Based-VCs-and-Trust-Registries-ID/
draft-DNS-Based-Digital-Verifiable-Credential-Verification-and-Trust-
Registry-Architecture.html. Status information for this document may
be found at https://datatracker.ietf.org/doc/draft-latour-dns-and-
digital-trust/.
Source for this draft and an issue tracker can be found at
https://github.com/CIRALabs/DNS-Based-VCs-and-Trust-Registries-ID.
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 12 April 2024 [Page 1]
Internet-Draft TODO - Abbreviation October 2023
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 12 April 2024.
Copyright Notice
Copyright (c) 2023 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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Note . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Mapping a DID to the DNS . . . . . . . . . . . . . . . . . . 5
4.1. URI record scoping . . . . . . . . . . . . . . . . . . . 6
4.2. Issuer Handles . . . . . . . . . . . . . . . . . . . . . 6
5. DID Public Keys in the DNS . . . . . . . . . . . . . . . . . 6
5.1. TLSA Record Scoping, Selector Field . . . . . . . . . . . 7
5.2. Issuer Handles . . . . . . . . . . . . . . . . . . . . . 7
5.3. Instances of Multiple Key Pairs . . . . . . . . . . . . . 7
5.4. Benefits of Public Keys in the DNS . . . . . . . . . . . 8
6. Digital Credential Verification using DIDs and the DNS . . . 8
7. Role of DNSSEC for Assurance and Revocation . . . . . . . . . 8
8. The Role of Trust Registries in Bidirectional Credential
Verification . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Issuer's Membership Claim in a Trust Registry . . . . . . 10
8.1.1. URI Record Name Scoping . . . . . . . . . . . . . . . 10
8.2. Trust Registry Membership Proof . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13
Carter, et al. Expires 12 April 2024 [Page 2]
Internet-Draft TODO - Abbreviation October 2023
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
With the increasing adoption and deployment of digital credentials
around the world, as well as the numerous different standards and
implementations surrounding them, there is a strong likelihood the
digital credential ecosystem will become fragmented. There all
already 150+ DID Methods listed in the
[DID-Specification-Registries], meaning that implementers of digital
credentialing solutions would have to ensure they can support the
resolution of the right DID Methods that are being used in their
interactions. This will present a significant burden to implementers
across different nations and organizations, creating large barriers
to interoperability.
This memo aims to improve global interoperability between different
decentralized digital identity ecosystems by ensuring that public DID
owners (i.e. credential issuers and sometimes verifiers) have unique
and accessible global identifiers. The memo also aims to demonstrate
how trust registries can enable global interoperability by providing
a layer of digital trust in the use of digital credentials,
demonstrating that trust registries can facilitate a more efficient
and trustworthy credential verification process. By leveraging the
publicly resolvable and widely supported DNS/DNSSEC infrastructure,
entities looking to make a trust decision can easily validate not
only the integrity of the credential they are presented with, but
also quickly associate the entity in question with a domain name and
organization, as well as their authority and trustworthiness by
confirming their membership in a trust registry. We will explore how
this implementation can present a more decentralized approach to
making trust decisions, without having to integrate directly to all
trust registries, but instead letting entities involved in private
transactions leverage existing internet infrastructure to facilitate
their own trust decisions.
We will focus this memo around a use case involving an individual or
an organization receiving a verifiable credential [AnonCreds]
[W3C-VC-Data-Model] from an issuer and storing it in their digital
wallet. When the individual needs to provide proof of identity or
other claims, they present the verifiable credential to a verifier in
the form of a verifiable claim which normally includes a digital
signature. The verifier then performs several steps to verify the
authenticity of the credential, including extracting the issuer's DID
from the credential, resolving it on a distributed ledger (Indy
ledger) to obtain the issuer's DID document, verifying the signature
of the credential using the public key in the issuer's DID document,
verifying the issuer's domain name and public key through DNS queries
Carter, et al. Expires 12 April 2024 [Page 3]
Internet-Draft TODO - Abbreviation October 2023
using URI and TLSA records, and finally verifying the issuer through
a trust registry grounded in the DNS using URI and TLSA records,
while ensuring all these DNS records are properly signed and
validated with DNSSEC.
This process allows for the secure and decentralized verification of
digital credentials in a manner that is transparent and auditable,
while also existing alongside and independent of the many different
decentralized identity ecosystems and implementations by grounding
itself in the DNS.
1.1. Note
The standardization of the various implementations of DIDs,
Verifiable Credentials, and more specifically, Trust Registries, is
required to to ensure global interoperability of the diverse and
emerging digital identity ecosystem.
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.
3. Terminology
* *Issuer*: The source of credentials—every verifiable credential
has an issuer. Issuers can include organizations such as
government agencies (passports, verified person), financial
institutions (credit cards), universities (degrees), corporations
(employment IDs), churches (awards), etc. Individuals can issue
themselves self-attested credentials - and depending on the
governance framework of a digital credentialing ecosystem,
individuals could issue credentials to others.
* *Holder*: The recipient of digital credentials. The Holder stores
their credentials inside a digital wallet and uses agent
technology to interact with other entities. A Holder can be a
person, an organization or a machine.
Carter, et al. Expires 12 April 2024 [Page 4]
Internet-Draft TODO - Abbreviation October 2023
* *Verifier*: A verifier can be anyone seeking trust assurance of
some kind about the holder of a credential. Verifiers request the
credentials they need and then follow their own policy to verify
their authenticity and validity. For example, a TSA agent at an
airport will look for specific features of a passport or driver’s
license to see if it is valid, then check to ensure it is not
expired.
* *Digital Wallet/Agent*: A digital wallet, in the context of
digital identity, is a secure platform or application that stores
and manages an individual's personal identification and
authentication credentials, such as government-issued IDs,
passports, driver's licenses, and biometric data in the form of
verifiable credentials. The Agent allows the subject to establish
unique, confidential, private and authentic channels with other
agents.
* *Verifiable Data Registry (VDR)*: A storage location where
information relating to Decentralized Identifiers (DIDs) and
credential metadata are stored. Permissionless blockchains or
permissioned distributed ledger networks can be used to facilitate
the discovery and resolution of DIDs and credential information.
* *Trust Registry*: Trust registries are services that help
determine the authenticity and authorization of entities in an
ecosystem governance framework. They allow governing authorities
to specify what actions are authorized for governed parties and
enable checking if an issuer is authorized to issue a particular
credential type. Essentially, trust registries serve as a trusted
source for verifying the legitimacy of credential issuers, wallet
apps, and verifiers.
4. Mapping a DID to the DNS
The W3C DID Core spec supports multiple ways of associating a DID to
a domain.
*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.
*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.
Carter, et al. Expires 12 April 2024 [Page 5]
Internet-Draft TODO - Abbreviation October 2023
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:sov: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 resides on which may not have the same degree
of access or support, enhancing discoverability.
4.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).
4.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 will need to be registered
separately in a trust registry and will likely 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 the issuer.
*_Ex: _did.diplomas.university-issuer.ca IN URI 1 0
“did:sov:XXXXXXX”_*
*_Ex: _did.certificates.university-issuer.ca IN URI 1 0
“did:sov:XXXXXXX”_*
5. DID Public Keys in the DNS
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 distributed ledger where it resides,
Carter, et al. Expires 12 April 2024 [Page 6]
Internet-Draft TODO - Abbreviation October 2023
facilitating interoperability.
TLSA records [RFC6698] provide a simple way of hosting cryptographic
information in the DNS.
5.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].
5.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 registered
in a trust registry, and 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.university-issuer.ca IN TLSA 3 1 0
“4e18ac22c00fb9...b96270a7b2”_*
*_Ex: _did.certificates.university-issuer.ca IN TLSA 3 1 0
“4e18ac22c00fb9...b96270a7b3”_*
5.3. 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 mechanism to differentiate which
verificationMethod the public key is related to will need to be added
to the name of the TLSA RRset.
A simple solution would be to create a standardized naming convention
by expanding the RRset name using the fragment of the target
verificationMethod's ID.
*_Ex: _did.key-1.example-issuer.ca IN TLSA 3 1 0
"4e18ac22c00fb9...b96270a7b4"_*
Carter, et al. Expires 12 April 2024 [Page 7]
Internet-Draft TODO - Abbreviation October 2023
*_Ex: _did.key-2.example-issuer.ca in TLSA 3 1 0
“4e18ac22c00fb9...b96270a7b5”_*
5.4. 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
only needs to resolve the DID document on the distributed ledger and
can perform the remainder of the cryptographic verification process
using data available in the DNS, potentially limiting the burden of
having to interoperate with a multitude of different distributed
ledger technologies and transactions for key access.
6. Digital Credential Verification using DIDs and the DNS
By leveraging the records and relationships outlined above, the
verifier can verify a digital credential claim by:
* Looking up the credential’s issuer’s DID on a distributed ledger
to resolve a DID document.
* Extracting the issuer’s domain from that DID document.
* Querying that domain for a __did_ URI record to confirm the
issuer’s domain is also claiming ownership over that DID.
* Performing a verification of the credential’s signature/proof
using the relevant verificationMethod in the DID document.
* Querying that domain for a __did_ TLSA record to confirm the
public key expressed by the verificationMethod is also expressed
by the issuer’s domain.
Through this process, the verifier has not only cryptographically
verified the credential they are being presented with, but also
associated the issuing DID to a publicly resolvable domain,
confirming it’s validity both semantically and cryptographically.
7. Role of DNSSEC for Assurance and Revocation
It is a MUST that all the participants in this digital identity
ecosystem enable DNSSEC signing for all the DNS instances they
operate. See [RFC9364].
Carter, et al. Expires 12 April 2024 [Page 8]
Internet-Draft TODO - Abbreviation October 2023
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 the distributed ledger 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 validity of DIDs
and public keys by reducing the need for complex revocation
mechanisms or implementation specific technologies.
8. The Role of Trust Registries in Bidirectional Credential
Verification
A trust registry is a decentralized system that enables the
verification of the authenticity and trustworthiness of issuers of
digital credentials. Trust registries can be implemented using
distributed ledger technology and leverage the DNS to provide a
transparent and auditable record of issuer information.
When an entity is presented with a verifiable claim, there are three
things they will want to ensure:
1. That a claim hasn’t been altered/falsified at any point in time,
via cryptographic verifiability and Verifiable Data Registries
(VDRs).
2. That a claim has accurate representation via authentication, via
DID Discovery & mapping within DNS as described above.
3. That a claim has authority, or in other words, does the issuer
have authority in its issuance of credentials, via the use of
trust registries (or trust lists).
In this memo, trust registries enable the verification of the
authority of an issuer and by extent their credentials. The role of
a trust registry within the context of this document is to confirm
the authenticity and trustworthiness of the issuer to the verifier
after they have validated the digital credential using the mechanisms
described previously. This involves the trust registry taking on the
role of a trust anchor for a given ecosystem, providing input for the
verifier’s ultimate trust decision regarding the credential they are
being presented with. The assumption is made that the trust registry
would be operated under the authority of an institution or
Carter, et al. Expires 12 April 2024 [Page 9]
Internet-Draft TODO - Abbreviation October 2023
organization such that their claims and input to the trust decision
would be considered significant or definitive. An example of such an
organization would be a government entity in relation to the issuance
of a driver’s licence.
It is important to note that the DNS based trust registry mechanism
described in this section is not meant to operate in place of an
alternative implementation but provide an easy to implement and use
mechanism to extend such a solution.
This section also does not describe the process of the trust
registry’s verification of an issuer, or the process of how an issuer
would become accredited by or join a trust registry.
8.1. Issuer's Membership Claim in a Trust Registry
Once the verifier has successfully completed the credential
verification process outlined in section 6, they have definitive
proof that the credential they are being presented with was issued by
the claimed issuer, and that issuer can be resolved to an
organization’s or entity’s domain. However, this process does not
provide definitive proof the issuer is to be trusted or has the
authority to issue such a credential. The issuer, through use of URI
records and the __trustregistry_ label, can assert the claim that
they are a member of a trust registry.
*_Ex: _trustregistry.example-issuer.ca IN URI 0 1 “example-
trustregistry.ca”_*
This record indicates the verifier can query the _example-
trustregistry.ca_ DNS based trust registry for TLSA records
containing _example-issuer.ca's_ public key/s, proving their
membership.
8.1.1. URI Record Name Scoping
When trust registry membership claims are published in the DNS
* The records MUST be scoped by setting the global (highest-level)
underscore name of the URI RRset to __trustregistry_ (0x5F 0x74
0x72 0x75 0x73 0x74 0x72 0x65 0x67 0x69 0x73 0x74 0x72 0x79)
8.2. Trust Registry Membership Proof
The trust registry can assert an issuer's membership using TLSA
records in a similar fashion to the methods outlined by section 5.1.
Carter, et al. Expires 12 April 2024 [Page 10]
Internet-Draft TODO - Abbreviation October 2023
*_Ex: _example-issuer.ca._trustregistration.example-trustregistry.ca
in TLSA 3 1 0 “4e18ac22c00fb9...b96270a7b6”_*
Note that the first component of the URI is the issuer’s domain,
followed by the __trustregistration_ label. This combination
indicates that the domain expressed is registered by this trust
registry as per its governance model, and this is their public key.
This association created by the TLSA record effectively has created a
chain of trust, beginning at the DID’s verificationMethod, continuing
to the issuer’s domain, and finally resolving at the Trust Registry.
9. Security Considerations
TODO Security
10. IANA Considerations
This document has no IANA actions.
11. References
11.1. Normative References
[alsoKnownAs]
"Decentralized Identifiers (DIDs) v1.0", n.d.,
<https://www.w3.org/TR/did-core/#also-known-as>.
[AnonCreds]
"AnonCreds Specification", n.d.,
<https://hyperledger.github.io/anoncreds-spec/>.
[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>.
[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>.
Carter, et al. Expires 12 April 2024 [Page 11]
Internet-Draft TODO - Abbreviation October 2023
[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>.
[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>.
[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
[Pan-Canadian_Trust_Framework]
DIACC, "PCTF Trust Registries Draft Recommendation V1.0
DIACC / PCTF13", n.d., <https://diacc.ca/wp-
content/uploads/2023/03/PCTF-Trust-Registries-Component-
Overview_Draft-Recomendation-V1.0.pdf>.
[Self-Sovereign_Identity]
Reed, D. and A. Preukschat, "Self-Sovereign Identity",
ISBN 9781617296598, 2021.
Carter, et al. Expires 12 April 2024 [Page 12]
Internet-Draft TODO - Abbreviation October 2023
[ToIP_Trust_Registry_Specification]
Trust Over IP (ToIP) Working Group, "ToIP Trust Registry
Protocol V1 Specification", n.d.,
<https://github.com/trustoverip/tswg-trust-registry-
tf/blob/main/v1/docs/
ToIP%20Trust%20Registry%20V1%20Specification.md>.
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
Carter, et al. Expires 12 April 2024 [Page 13]
