# Introduction {% hint style="info" %} NOTE: This documentation is still in progress and will evolve further as the DARP protocol is developed. {% endhint %} Complex addresses (e.g. cryptocurrency, network, physical) are difficult to share and remember, which adds risk to their use. The Decentralised Address Resolution Protocol is being designed to provide easy to remember Address Names to help mitigate against these problems While some services already exist which focus on simplifying the use of cryptocurrency addresses, they are not implemented on a third generation blockchain and use smart contracts to store records on the blockchain that map a friendly name to an address. While this technically decentralises the name resolution service, it unnecessarily adds bloat to the blockchain with data that doesn't necessarily need to be immutable and can also add cost through the use of gas. # Foundations The DARP protocol will be built on top of existing open Decentralised Identity (DI) standards, as we consider friendly Address Names (and the addresses they resolves to) to be an identity construct. Decentralised Identity (sometimes called Self Sovereign Identity) is a burgeoning use case for blockchain technology that is being led by organisations such as the [W3C](https://www.w3.org/), [OASIS](https://www.oasis-open.org/), the [Decentralised Identity Foundation](https://identity.foundation/) (DIF) and projects such as The Linux Foundation's Hyperledger [Indy](https://www.hyperledger.org/use/hyperledger-indy) & [Aries](https://www.hyperledger.org/use/aries). In addition to using Decentralised Identity standards, the team working on the DARP protocol will be using the [Cardano](https://cardano.org/) blockchain for the required decentralised ledger components, which are being introduced by [IOHK](https://iohk.io/) to support their [Atala PRISM](https://atalaprism.io/) identity solution. Cardano is the first provably secure third generation blockchain that has been designed using peer reviewed scientific research and developed using formal methods. This provides a strong foundation that we believe will endure for some time and provides confidence to those that have not yet come to trust earlier generation blockchains. # Decentralised Identity Standards The Decentralised Identity standards that will be used in the DARP protocol and by Decentralised Address Name Registrars are [Decentralised Identifiers](https://www.w3.org/TR/did-core/) (DIDs) and [Verifiable Credentials](https://www.w3.org/TR/vc-data-model/). A DID is a URI (e.g. did:example:123456789abcdefghi) that is unique to an entity (person, organisation) wanting to store identity information. A DID resolves to a DID Document that is stored on a blockchain and is cryptographically signed by the owner. An example of a DID Document is as follows: ```javascript { "@context": "https://www.w3.org/ns/did/v1", "id": "did:example:123456789abcdefghi", "authentication": [{ "id": "did:example:123456789abcdefghi#keys-1", "type": "Ed25519VerificationKey2018", "controller": "did:example:123456789abcdefghi", "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" }], "service": [{ "id":"did:example:123456789abcdefghi#ard", "type": "AddressResolverDocument", "serviceEndpoint": "https://example.com/myaddress/", "ardHash": "sha512-3bb12eda3c298db5de25597f54d924f2e17e78a26ad8953ed8218ee682f0bbbe9021e2f3009d152c911bf1f25ec683a902714166767afbd8e5bd0fb0124ecb8a" }] } ``` # Purpose of the Address Resolver Document To use the DARP protocol in a supported application a user must register a DID Document that includes a service endpoint that DARP compliant applications (wallets, dApps, browsers, etc) can use to access an Address Resolver Document (ARD) which stores resolution information for a given Address Name. An example of how the Address Resolver Document may be structured is as follows: ```javascript { "addressName": "myname.address", "addresses": [{ "ada": "addr123456789abcdefghijklmnopqrstuvwxyz123456789abcdefghijklmnopqrstuvwxyz123456789abcdefghijklmnopqrst", "btc": "1PC9aZC4hNX2rmmrt7uHTfYAS3hRbph4UN", "http": "www.myname.com" }], "subNames": [{ "addressName": "iohk.myname.address", "addresses": [{ "ada": "addrabcdefghijklmnopqrstuvwxyz123456789abcdefghijklmnopqrstuvwxyz123456789abcdefghijklmnopqrstuvwxyz123", "http": "54.206.19.82", "gps": "22.277478493216226, 114.16839175078059" }] }], "timestamp": "2020-12-17T06:35:22Z", "signature": "DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSApmWQxfKTUJqPP3-Kg6NU01Q" } ``` {% hint style="info" %} NOTE: An Address Resolver Document can include more than just cryptocurrency addresses, which means over time entities can begin to manage all their address resolution requirements using a common protocol. {% endhint %} While Decentralised Address Name Registrars will likely host users Address Resolver Documents as part of their service, the user is free to store it anywhere they want (e.g. IPFS, a Cardano SPO, a private server, Google Drive) as long as the endpoint registered in the DID Document is accessible. Consideration is also being given from providing a mechanism to include multiple ARD endpoints in the DID Document. This will allow a user to store their ARD in distributed locations for redundancy purposes (i.e. if a hosting location becomes unavailable). # Trusting an Address Resolver Document If anyone can register a DID Document that claims to have the location of an Address Name's Address Resolver Document, how do we know that the DID Document (and its referenced ARD) was created by the Address Name's owner? There are 2 features of the DARP protocol that deal with this: * Verifying the Address Resolver Document * Verifying Address Name Ownership # Verifying the Address Resolver Document Assuming a DARP compliant application can verify Address Name ownership (see next section) and therefore trusts that the correct DID and service endpoint is being used, there may be scenarios where the integrity of the ARD can be compromised. For example, if the Address Name owner is hosting their ARD through a third party, that third party may have the ability to modify it. To protect against this the ARD is cryptographically signed using the keys associated with the corresponding DID, something only the DID owner can do. Whenever a change is made to the ARD, the associated DID Document is also updated to include a hash of the ARD. These features allow a DARP compliant application to not only ensure the ARD hasn't been tampered with, but also ensure it is the correct version. # Verifying Address Name Ownership While the previous section describes how a DARP compliant application can verify if the contents of an ARD can be trusted, this doesn't indicate whether a DID represents the true owner of an Address Name. The DARP protocol will therefore support this through the following: * Verified Address Name Ownership * Address Name Registry Both these features are delivered by Decentralised Address Name Registrars. # Purpose of Decentralised Address Name Registrars Decentralised Address Name Registrars serve two important functions in the DARP protocol. * Issuing Verifiable Credentials to verify Address Name ownership * Provide Address Name Registry services # Verified Address Name Ownership This feature uses a capability of the open Decentralised Identity standards called Verifiable Credentials (see [Verifiable Credentials 101](https://www.youtube.com/watch?v=6O_iJnhIh5o) for more information about how they work). Decentralised Address Name Registrars will issue a Verifiable Credential stating that a DID is the owner of a specified address name. DARP compliant applications can use the Verifiable Credential to ensure it is using the owner's DID (i.e. who the Decentralised Address Name Registrar has determined to be the owner) to access their ARD. Decentralised Address Name Registrars may issue Verifiable Credentials as a service for address name spaces they manage, or for address name spaces managed by other entities (if they have a mechanism for verifying ownership). An example of the latter might be verifying names issued as top-level/root domains by [IANA](https://www.iana.org/domains/root/db) as part of the current Domain Name System (DNS) used to resolve domains to network addresses (e.g. IP addresses). If a user wants to use an Address Name that matches a DNS name they have purchased (e.g. myname.com), Decentralised Address Name Registrars could provide a mechanism for verifying ownership of that domain name and then issue a Verifiable Credential confirming ownership. Like many traditional credentials, the Verifiable Credential issued can have an expiry date that matches the DNS domain's registered expiry. # Address Name Registry Similar to how domain names are issued through a domain registrar in the DNS system, Decentralised Address Name Registrars will maintain a registry of Address Names that users have registered through them. In addition to allowing a DARP compliant application to use this registry to verify a DID's ownership of an Address Name, it also serves as the initial lookup source for starting the resolution process of an Address Name entered into the application by one of their users. While a registry lookup can be used to verify address name ownership, it should still be used in conjunction with a Verifiable Credential issued by a Decentralised Address Name Registrar as this provides a cryptographic proof, which the registry entry doesn't. Not relying solely on the registry for verifying ownership will allow registries to be used in different ways to provide optimisations and greater decentralisation, such as caching or distribution of their hosting. Although there are currently no constraints on how a Decentralised Address Name Registrar should host a registry it maintains, the DARP team will be exploring peering arrangements that will allow the decentralisation of registries so that a registrar doesn't become a single point of failure.