The Web currently does not have a mechanism where people and organizations can claim identifiers that they have sole ownership over. Identifiers, such as those rooted in domain names like emails addresses and website addresses, are effectively rented by people and organizations rather than owned. Therefore, their use as long-term identifiers is dependent upon parameters outside of their control. One danger is that if the rent is not paid, all data associated with the identifier can be made temporarily or permanently inaccessible. This document specifies a mechanism where people and organizations can cryptographically claim ownership over identifiers such that they control them and the documents that they refer to.

This is an experimental specification that is currently undergoing rapid change and is not ready for widespread implementation. The reference implementation of this technology can be found on Github

Introduction

The Web currently does not have a mechanism where people and organizations can claim identifiers that they have sole ownership over. Identifiers, such as those rooted in domain names like emails addresses and website addresses, are effectively rented by people and organizations rather than owned. Therefore, their use as long-term identifiers is dependent upon parameters outside of their control. One danger is that if the rent is not paid, all data associated with the identifier can be made temporarily or permanently inaccessible.

The main reason this problem exists is two fold: it's a particularly hard one to solve and there was no time to build out the solution when the Web was starting its rapid rise in the late 1990s. The solutions for creating identifiers that we have in place today, particularly DNS, HTTP, and URLs, are powerful tools that have scaled the Web to the billions of people that use it today.

However, as the Web expands and becomes more personal, there is a growing need for a type of dereference-able identifier that can be created and owned by people and organizations without the need for a central organization or federation of organizations to control the namespace. Having such a scheme would enable more personal and organizational freedom on the Web.

Terminology

Decentralized Identifier Registration Algorithm

The following algorithm specifies how to register a decentralized identifier in the WebDHT. The algorithm takes a private key, a public key, and stores a DID document in the WebDHT.

The discovery and storage mechanism for the final WebDHT is still an area of active research and debate. One possible technology that may be used is a security hardened version of Kademlia DHT algorithms that have gained widespread use in peer-to-peer systems like tracker-less Bittorrent networks.

The mechanism for generating a DID is likely to change to one based on a cryptographic hash of a public key. Once an identifier is claimed, the key used is not necessarily significant, unlike in systems that use blockchain technology, ie: the key can sign a change to the DID document granting authorization to other keys, such that the loss of the original claiming key does not result in the loss of control over the identity.

  1. Create the decentralized identifier by generating a version 4 UUID [[UUID]] and pre-pending the string did: to the identifier. Example: did:a8ebdaf1-3c47-45d1-addc-26ce643b9a0c
  2. Create the public key URL. The URL value MUST be compatible with the Linked Data Signatures [[LD-SIGNATURES]] specification. The URL SHOULD be a DID-based URL that points to a resource in the DID document. The URL MAY be an HTTP-based URL or any other sort of dereferenceable URL. Example: did:a8ebdaf1-3c47-45d1-addc-26ce643b9a0c/keys/1
  3. Set the DID document to a JSON-LD document with atleast the following key-value pairs:
    @context
    https://w3id.org/identity/v1
    id
    The value of the decentralized identifier.
    accessControl
    writePermission
    An array of public key identifiers or other decentralized identifiers that are allowed to modify this document. At a minimum, one entry MUST exist:
    id
    The value of the public key URL.
    type
    CryptographicKey
    publicKey
    id
    The value of the public key URL.
    type
    CryptographicKey
    owner
    The value of the decentralized identifier.
    publicKeyPem
    The public key in PEM format.
  4. Add a signature to the DID Document by executing the Linked Data Signatures algorithm.
  5. Discover the nodes in the WebDHT that will store the DID document and for each node:
    1. Discover the storageRequest endpoint.
    2. Perform an HTTP POST to the storageRequest endpoint with the DID document as the body of the request.
    3. Execute the Proof of Patience algorithm and re-post the DID document when the proof has been fulfilled.
    4. This algorithm returns successfully when the acceptable number of copies have been written to the WebDHT. The algorithm fails otherwise.

If successful, the result of the algorithm listed above will be an entry in the WebDHT where the key is the decentralized identifier and the value is similar in form to the following example document:

{
  "@context": "https://w3id.org/identity/v1",
  "id": "did:a8ebdaf1-3c47-45d1-addc-26ce643b9a0c",
  "accessControl": {
    "writePermission": [
      {
        "id": "did:a8ebdaf1-3c47-45d1-addc-26ce643b9a0c/keys/1",
        "type": "CryptographicKey"
      },
      {
        "id": "did:780c5356-b4ab-473d-97f6-aeb524794eb9",
        "type": "Identity"
      }
    ]
  },
  "publicKey": [
    {
      "id": "did:a8ebdaf1-3c47-45d1-addc-26ce643b9a0c/keys/1",
      "type": "CryptographicKey",
      "owner": "did:a8ebdaf1-3c47-45d1-addc-26ce643b9a0c",
      "publicKeyPem": "-----BEGIN PUBLIC KEY-----\r\n
      MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmPUHbAM58QX957aRuE1H\r\n
      AN0iYjfjs4I/waRPW/0RiFcVccFh2DYra56oT9IW2XJyxxchm0LMQwOmtb2N/ro+\r\n
      r73gvOqms2RyTHsdcX4aYZKdIdhIN3s9GVoYwREVvpaWH2ulJhujB1hO/XYfAADB\r\n
      cwjxVMQ7a0Cdv1R/eaM0oQk3CHGAPnB8EaDAWzkcJ9FwCf/PPdIf3X6qtGICX4Ei\r\n
      LypDHkVodTL3SxpjMkSIJK87O5/x6HDWtA+tgaYxIJxnCY0P1ssUpmuxuacZfhN9\r\n
      jaT8NUIKYAb+9z+zL0Ba8o4niSQVDt4W3r/LCF7Mj8Ps0nF05lW3Ymwz4C6ENO1L\r\n
      lQIDAQAB\r\n-----END PUBLIC KEY-----\r\n"
    }
  ],
  "signature": {
    "type": "LinkedDataSignature2015",
    "created": "2015-10-23T02:10:21Z",
    "creator": "did:a8ebdaf1-3c47-45d1-addc-26ce643b9a0c/keys/1",
    "signatureValue": "cNJGLFqT/d/90D4GFzvPwaJ66hHKUIgSPcJmm++oiP+wSHjtov8
    4/hI4lVrNmYp9WdXRrCNSIko9wzots1QdKkoleFMUftAclVXfERuvnhsFlMTBO7FKRCM5I
    X6D8Ec+SRKG7C8d3Hy6DBPPRtRrDeZr7YpeggUBaA/IfejaDfCRzBgwcWaXqt21MQXmins
    Rud7g/pYrAwsnGag9B8bwjzyKKpZgrZQ5AVcc40tuIdIsddEuckzEjFpBZs9wHtGlgnybI
    4apZ90waD2SM+oLi19jnUcY4GQSZ/id3MIlr6BYeTv86fzDq4IHT2kp32foVgjidzFL+aK
    WMZOsQyKPiw=="
  }
}
    

The Proof-of-Patience mechanism on its own is insufficient to protect the network from DDoS attacks. More mechanisms need to be employed.

Creating an Alias in the DHT

When creating DID document entries in the DHT, it is useful to also create aliases for those entries to enable human-based lookup of identifiers. For example, enabling the lookup of a decentralized identifier using an email address and passphrase would help people bootstrap the discovery process using information that is easy for them to remember. The actual email address and passphrase are not stored in the WebDHT.

The following algorithm specifies how to register an alias to a decentralized identifier in the WebDHT. The algorithm takes a hash value and stores an associated alias document in the WebDHT.

  1. Create the hash value by using a well known hashing algorithm and running it over a set of provided input text and then prepending the hash algorithm identifier and a colon : to the hashing algorithm output. For example, ask a person for an email address and a passphrase, concatenate the input, and perform a SHA-256 of the input which should result in the following example hash value: sha256:8cd07f3a5ff98f2a78cfc366c13fb123eb8d29c1ca37c79df190425d5b9e424d.
  2. Set the alias document to a JSON-LD document with atleast the following key-value pairs:
    @context
    https://w3id.org/identity/v1
    id
    The value of the decentralized identifier.
  3. Add a signature to the alias document by executing the Linked Data Signatures algorithm.
  4. Discover the nodes in the WebDHT that will store the alias document and for each node:
    1. Discover the storageRequest endpoint.
    2. Perform an HTTP POST to the storageRequest endpoint with the alias document as the body of the request.
    3. Execute the Proof of Patience algorithm and re-post the alias document when the proof has been fulfilled.
    4. This algorithm returns successfully when the acceptable number of copies have been written to the WebDHT. The algorithm fails otherwise.

If successful, the result of the algorithm listed above will be an entry in the WebDHT where the key is the hash value and the value is similar in form to the following example document:

{
  "@context": "https://w3id.org/identity/v1",
  "id": "did:a8ebdaf1-3c47-45d1-addc-26ce643b9a0c",
  "signature": {
    "type": "LinkedDataSignature2015",
    "created": "2015-10-23T02:40:21Z",
    "creator": "did:a8ebdaf1-3c47-45d1-addc-26ce643b9a0c/keys/1",
    "signatureValue": "cNJGLFqT/d/90D4GFzvPwaJ66hHKUIgSPcJmm++oiP+wSHjtov8
    4/hI4lVrNmYp9WdXRrCNSIko9wzots1QdKkoleFMUftAclVXfERuvnhsFlMTBO7FKRCM5I
    X6D8Ec+SRKG7C8d3Hy6DBPPRtRrDeZr7YpeggUBaA/IfejaDfCRzBgwcWaXqt21MQXmins
    Rud7g/pYrAwsnGag9B8bwjzyKKpZgrZQ5AVcc40tuIdIsddEuckzEjFpBZs9wHtGlgnybI
    4apZ90waD2SM+oLi19jnUcY4GQSZ/id3MIlr6BYeTv86fzDq4IHT2kp32foVgjidzFL+aK
    WMZOsQyKPiw=="
  }
}
    

Updating Documents in the DHT

The following algorithm specifies how to update a DID document that has been previously stored in the WebDHT. The algorithm takes a decentralized public keys associated with the identifier and stores a DID document in the WebDHT.

  1. Add a signature to the DID Document by executing the Linked Data Signatures algorithm.
  2. Discover the nodes in the WebDHT that will store the DID document and for each node:
    1. Discover the storageRequest endpoint.
    2. Perform an HTTP POST to the storageRequest endpoint with the DID document as the body of the request.
    3. This algorithm returns successfully if the minimum information exists in the DID document, the signature is valid, and when the acceptable number of copies have been written to the WebDHT. The algorithm fails otherwise.

Updates do not require the execution of the Proof of Patience algorithm as the storage nodes need only check the existing public keys associated with the DID document and verify the signature of the updated DID document to result in a successful write to the WebDHT.

Data Survivability

In order for this technology to be broadly useful to society, it is important that data stored in the WebDHT has excellent survivability characteristics. The data stored on the network must be available as the system scales to billions of devices using it, undergoes nation-state attacks, suffers large failures and disruptions to the underlying communication networks, and is affected by clients with a high network churn rate. A number of data survivability considerations are listed and analyzed below with respect to the algorithms provided in this document.

Replication Requirements

In order for data to survive most of the issues listed above, a high mirroring rate is necessary. The algorithm to calculate the proper mirroring rate is still under development.

Storage Location Control

In order to survive a number of attack scenarios, it is best to have the storage node addresses and storage and mirroring locations be chosen in a way that is not under the control of the storage nodes (or any party), but rather, for example, controlled by an algorithm that must be properly implemented for the network to function. At the same time, good discovery times must be provided. The algorithms to calculate the storage location selection and storage node address locations is still under development.

Security Considerations

In order for this technology to be broadly useful to society, it is important that the protocols and data used have certain security characteristics that don't make it susceptible to attacks that would cripple the communication channels or corrupt the data stored in the system.

Distributed Denial of Service Attacks

It should be assumed that private organizations and nation-states may attack the WebDHT to try and disrupt activity since there are economic and political incentives to do so. Many of the attack preventions rely on slowing down requests using techniques like Proof-of-Patience, or ensuring that all data is digitally signed to provide data protection. More techniques are needed and a thorough analysis on DDoS attacks on each endpoint and system component is still required.

Attacks on Decentralized Identifiers

An attacker may target a particular individual or organization in the WebDHT to prevent that target from interacting with the broader network. Some of the protections to prevent this sort of attack include deterministically selecting storage node and data addresses in a way that makes it infeasible to spoof information on the network. A thorough anaysis on targeted attacks on decentralized identifiers is still needed.

Privacy Considerations

All Stored Data is Public

Acknowledgements

The editors wish to thank the participants of the Credentials Community Group for discussions about and contributions to this document.