diff --git a/draft-latour-dns-and-digital-trust.md b/draft-latour-dns-and-digital-trust.md index a21bdd2..9ac3e44 100644 --- a/draft-latour-dns-and-digital-trust.md +++ b/draft-latour-dns-and-digital-trust.md @@ -87,17 +87,15 @@ author: --- 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. +This memo describes an architecture for trust registry membership association and verification using Decentralized Identifiers (DIDs), trust registries, and the DNS. This architecture provides a verifier with a simple process by which to determine and verify an issuer's membership in a trust registry. --- middle # 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 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. -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 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. +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 according to the corresponding did method to obtain the issuer's DID document, verifying the signature of the credential using the public key in the issuer's DID document, 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. @@ -117,89 +115,6 @@ The standardization of the various implementations of DIDs, Verifiable Credentia - **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. -# 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. - -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. - -## URI record scoping - -- The records MUST be scoped by setting the global underscore name of the URI RRset to *_did* (0x5F 0x64 0x69 0x64). - -## 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”*** - -# 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, facilitating interoperability. - -TLSA records {{!RFC6698}} provide a simple way of hosting cryptographic information in the DNS. - -## 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}}. - -## 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”*** - -## 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"*** - -***Ex: _did.key-2.example-issuer.ca in TLSA 3 1 0 “4e18ac22c00fb9...b96270a7b5”*** - -## 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. - -# 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. - -# 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}}. - -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. - # 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. @@ -218,7 +133,7 @@ This section also does not describe the process of the trust registry’s verifi ## 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. +Once a verifier has successfully completed the credential verification process, they have definitive proof that the credential they are being presented with was issued by the claimed issuer. 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”*** @@ -232,11 +147,19 @@ When trust registry membership claims are published in the DNS ## 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. +The trust registry can assert an issuer's membership using TLSA records. ***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. +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 Issuer's public key, continuing to the issuer’s domain, and finally resolving at the Trust Registry. + +# 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}}. + +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. # Security Considerations