Proposal on the Design and Implementation of a DID method over DNSSEC (did:dnssec)

Table of Contents

1. Introduction

Decentralized Identifier (DID)[DID-CORE] is a technology for implementing verifiable identifiers in a decentralized manner. It can be implemented in a way that eliminates dependence on other entities, also able to materialize a Self-Sovereign Identity (SSI). By applying blockchain technology, a fully decentralized identity is possible. Because of its decentralization focusing design, there is a clear distinction from the centralized or hierarchical control delegation mechanisms often used in the current Internet.¶

While we anticipate broad deployments of applications using DID in the future, deployment often requires dependence on existing distributed systems such as Domain Name Systems (DNS). For example, did:web [DID-WEB] depends on DNS. Also, some DID method implementation indirectly depends on DNS, i.e., to reach the service described in DID documents as service endpoints.¶

The new did:dnssec method uses DNS Resource Records (DNS RRs)[RFC1035] and DNSSEC Resource Records (DNSSEC RRs)[RFC4034] as a Verifiable Data Registry (VDR) to eliminate the gap between the existing Internet world and the new DID world. Using DNS RRs and DNSSEC RRs as a VDR (DNSSEC VDR hereafter) and applying the signature verification mechanism in DNSSEC enable establishing the chain of trust of a Fully Qualified Domain Name (FQDN) through multiple DNS zones. Using locally verifiable FQDN to RR mapping can eliminate external entity dependencies in DID documents such as DNS resolver dependency in did:web, if the cost of local validation is acceptable.¶

Access to DNSSEC VDRs is possible via the currently available DNS transport mechanisms. Since browsers can now access DNS servers via TCP[RFC7766], the whole process, including RR retrieval and RR set validation, can be completed within the browser. Also, since the DNSSEC VDR only depends on already deployed DNS servers, there are numerous advantages over blockchain-based VDR implementations, such as: extremely high availability, a wide range of implementation, a long list of experienced operators, rich operational experiences, and so on.¶

Furthermore, since DNSSEC is designed to work without transport security, successful validation is guaranteed as long as the necessary RR sets are available at the validation stage. It is possible to mix sets of RRs retrieved from multiple servers for a validation process. The DID document of did:dnssec consists of the subject FQDN and a set of RRsets required to verify the subject RR. The DID document is fully verifiable by following the chain of trust starting from the DNSSEC trust anchor (public keys which bound to the root zone key signing keys), which are statically preconfigured as the trust anchor in the verification library, which is common among typical DNS resolver implementations.¶

This proposal describes the list of design decisions needed and presents the necessary actions to design and implement did:dnssec.¶

Note: The author of this proposal demonstrated the use of DNSSEC Resource Records similarly in a paper [PKB-ADHOC].¶

2. Key Ideas

• Treat DNS/DNSSEC RRs in the DNS zones as a Verifiable Data Registry¶

  • A VDR with the same control and hierarchical delegation policy as DNS¶

• DID resolver returns a set of RRs for a given DID as a DID document¶

  • Resolver collects and returns all of the RRs require to verify the entire chain of trust for an RRset¶

  • Resolver is also able to provide individual RRset if necessary¶

  • Since the target of signing, which is the wire-format of RRset, is already in a canonical form, the values in DID document is mere a text converted wire-format values¶

• Verifier can verify the validity of the subject RRset referred by the FQDN¶

• Using DNS query over TCP [RFC7766] makes the entire process possible to complete within a browser¶

3. Actions

• Obtain method-id dnssec by registering did:dnssec to the DID Spec Registry¶

• Decides on the patterns of did:dnssec DID to express query options¶

• Develop DNSSEC RRSIG Resource Record Signature Format¶

• Develop DID document format of did:dnssec¶

• Write the specification on DNSSEC RRSIG Resource Record Signature Format¶

• Write the did:dnssec specification¶

• Implement did:dnssec DID document verification library¶

• Implement did:dnssec resolver¶

Note: the author of this proposal has implemented the part of library code in C++, which is the part of the iOS application code prepared for the experiment of [PKB-ADHOC]. The author is currently actively translating and refactoring the code as libraries in TypeScript language.¶

4. Deliverables

5. Security Considerations

To be discussed¶

6. IANA Considerations

This document has no IANA actions.¶

Author's Address