Technical Document – Part 2
DID is only an identifier
In the first article, we saw that a DID (Decentralized IDentifier) was a unique address that could be resolved, in the same way as a web page. The difference is that the DID is an address that allows access to a document, the “DID Document” (sometimes also called “DDO”).
The DID used in the XSL Labs project is the SDI (Secure Digital Identity). In other words, the SDI is a decentralized identifier used to obtain a “DID Document” here named “SDI Document” from a public blockchain.
The DID is associated with a “DID Document”
This DID Document is the elementary public profile of the user. It is not intended to contain a lot of data and since it is public and available on a public blockchain, it should not contain any personal information, such as name, date of birth, etc.
We will see later that it is quite easy to add new types of data to the DID Document, particularly thanks to the ongoing standardization efforts defining the possible contents of such documents, as its syntax, structure, etc.
An innovative sector and recent standardization efforts
Research on decentralized identities is all very recent and linked to the concept of “Self-Sovereign Identity” (SSI), which describes the ability for users to directly control their personal data, to be able to store, present and make them verifiable without having to ask a trusted intermediary for each presentation.
The first decentralized identities using a blockchain date back to 2017 and 2018 with Sovrin and Ontology’s public blockchains, Microsoft’s experiments on Bitcoin and the publication of the uPort contract on Ethereum.
These solutions are the culmination of many previous works (non-exhaustive list):
– The “Web of Trust” concept by Phil Zimmerman, inventor of PGP, mentioned as early as the 1990s,
– Carl Ellison’s publications on identities without certification authorities at the same period,
– Kim Cameron’s “The Laws of Identity” (2005),
– Audun Jøsang and Simon Pope’s work on User Centric Identity Management (UCI) also in 2005,
– In 2006, the first works on W3C Verifiable Credentials which first spoke of “Verifiable Claims” before using the term “Verifiable Credentials”,
– Moxie Marlinspike’s (inventor of Signal messaging) thoughts on these subjects from 2012 onwards,
– Articles by Christopher Allen (co-inventor of the SSL / TLS standard and well known in the crypto community for being the main architect of Blockstream) on the concepts of personal and contextual privacy in 2015, then on the description steps to take to achieve a true Self-Sovereign Identity in 2016.
– The White Paper published during the first workshops of “Rebooting the Web of Trust” in 2015 which described the need for a decentralized public key infrastructure (PKI)/(DPKI), written by Vitalik Buterin and Christopher Allen, among others.
In 2017, alongside the first public experiments on decentralized identities, the Decentralized Identity Foundation (DIF / https://identity.foundation) began to list the methods for resolving DIDs to constitute a “Universal Resolver” (https://github.com/decentralized-identity/universal-resolver/). The Universal Resolver is a correspondence table that allows every service provider wishing to interact with a DID presented by a user, to find the DID Document associated with it.
It is this correspondence table that will later be referenced in the first document of the W3C working group on DIDs: https://w3c.github.io/did-core/
Finalized in 2019, the publication of this document on DIDs was a major step forward since its author, the World Wide Web Consortium (W3C), is the main body for Internet technologies standardization (they were behind the creation of the HTML, DOM, PNG, XML standards…).
XSL Labs will soon join the Decentralized Identity Foundation (DIF) in order to have its own DID method listed in the official DID resolution table. There will thus be a public, accessible and referenced information about how to resolve the SDI (DID) into an SDI document (DID Document).
The DID Document (DDO)
Now that we know that a DID is always associated with a DID Document and that this document does not directly contain personal information, let’s see what this document may essentially contain:
– sub-identifiers to localize information in the DID Document,
– public keys,
– information on the services and uses of the public keys,
– information on the issuer of the DID Document with creation and modification dates,
– a signature.
Reminder: Public keys (and indirectly public crypto addresses) are mathematically linked to private keys which must remain in their owner’s wallet, under his exclusive control. Private keys are used to sign data (documents, transactions, proofs, etc.) and public keys are used to verify the validity of these signatures.
We will take an example in which a DID and a DID Document are linked to an individual. But keep in mind that a DID can also be associated with a legal person, an object, an organization…
Here is an example of a DID Document, in standard JSON / JSON-LD format:
Illustration 2-1: the DID Document corresponding to the DID “did:syl:aea42randn1awa3xzhjkbvc33”
This document is the resolution of the DID “did: syl: aea42randn1awa3xzhjkbvc33”. To find this document, one has to interpret the different parts between “:”. “did” indicates a decentralized identity protocol, just as “http” indicates a server / client communication protocol for browsing the World Wide Web. “syl” corresponds to the DID method used and to further interpret, one must consult the official list of DID methods (https://w3c.github.io/did-spec-registries/#did-methods) to know what it corresponds to.
Once the method is found, all one has to do is use the end of the identifier to find the final DID Document. In this example, we call the smart contract with the identifier “aea42randn1awa3xzhjkbvc33” (this is generally a random identifier assigned when the DID is created, we will discuss this initial phase in another article). Whether directly via a main/parent smart contract or through several individual smart contracts, the DID method allows to obtain the DID Document, the resolution of the DID.
The rudimentary content of the DID Document given as an example (illustration above) can be much more diverse and detailed. But this example allows us to have a simple overview of this type of document in order to explain its different parts.
“@context”: « https://www.w3.org/ns/did/v1″
This line indicates that this is a DID Document.
This first “id” indicates the address of the DID associated with this DID Document (the DID that is resolved by this DID Document).
This first “controller” mention specifies who controls this DID and therefore can make changes to it. This example represents the simplest case, where the identity of the controller is the same as the identity which is described in the “DID Document”.
This is not the only possibility. Many other cases are conceivable and can be useful in the following situations (non-exhaustive list):
– A person uses several different wallets to control the same identity,
– A person uses a single wallet to control several identities,
– An adult manages certain parts of a child’s decentralized identity,
– A person delegates certain rights over all or part of his identity to a trusted third party,
This section describes how to authenticate (by default) this DID’s owner by directly inserting an authentication public key.
The new “id” which ends with #authkey allows direct reference to this section. In this example, the DID is “did:syl:aea42randn1awa3xzhjkbvc33” but if we want to directly indicate the key which serves as authentication we can write “did:syl:aea42randn1awa3xzhjkbvc33#authkey”. It’s just as when pointing directly on an anchor in an html page in order to directly reach a section of this page.
The “type” gives the public key digital signature algorithm used for authentication. In this example it is the DSA variant using elliptic-curve cryptography.
The “controller” refers to the DID responsible for this section. In this example, again we are faced with the simplest case since the reference is identical to the owner of the identity.
“publicKeyBase58” is followed by the value of the public key base 58 encoded.
Let’s continue studying the contents of this DID Document. We will see now how an external web service can authenticate a new user presenting himself with his DID.
We will discuss Verifiable Credentials in detail in a future post, but for the moment keep in mind that these Credentials are verifiable data available inside user wallets but to become a Verifiable Credential these credentials have to be verified by a trusted third party.
This is how Verifiable Credentials are shared between users. Users will be able to test the validity a Verifiable Credential linked to this DID by going to the address indicated, in this example “https://example.com/vcheck”, by copy-pasting it or by directly checking the Verifiable Credential in the DID Document.
At the end of the DID Document, we usually find a digital signature to authenticate the person who created it. The first date refers to the document’s date of creation in the smart contract and is followed by details of the signature which serves as proof, often containing a slightly earlier date.
Again, the simplest case is shown in this example, where the creator is the owner of the identity. But this is not necessarily the most frequent case. Indeed, the creation of a DID Document on a blockchain often requires the payment of data creation fees and the user is not necessarily the one who performs this transaction.
For example, a user downloads a wallet to create and manage his decentralized identity. He will need to create a DID Document on a smart contract on Ethereum but does not possess ETH to pay the necessary gas fees when creating this DID Document. He needs an intermediary to help him create and put the DID Document on the smart contract’s blockchain. This intermediary will pay the fees associated with the creation of the DID Document on behalf of the user.
The creator of the DID Document can therefore be different from the user. However, even in this case:
– the creator’s DID makes it possible to find and verify the identity of this intermediary to ensure that he is a trusted intermediary (this DID can redirect to the DID Document of a referenced administrator for example),
– this does not necessarily mean that this creator can modify the data in the DID Document without the consent of the user of the DID. Only the user of the DID has control over his DID and thus is the sole person that can make future changes to his DID Document or can choose to share its control with a third party, etc.
Example of use case: a web service wishes to authenticate a DID owner
The abcd.com web service wishes to authenticate SDI (DID) owners. We will demonstrate the possibility of authenticating from a third-party app in a future post, but for now we will limit ourselves to study the fairly common case of authentication on a website displayed in the browser of a desktop computer.
The server login page displays a QR Code that contains the address of the web service and a unique random string, also called a “challenge”.
Illustration 2-2 : Authenticate the DID’s owner on a web server
The user scans the QR Code with the DID’s wallet. The wallet asks the user if he agrees to use a key linked to his DID to authenticate on this server and then, after confirmation, uses the private authentication key to sign the challenge contained in the QR Code. The wallet then sends the signed challenge and its DID back to the server.
The web service receives the DID (acting as “username”) and automatically follows the steps described above to obtain the associated “DID Document”. The service reads the section on authentication and finds the public key linked to the DID that can be used for authentication by default. The server must now ensure that the owner of the DID has the private key corresponding to this public key. All he has to do is check the validity of the signature he has just received. If the signature is valid, the server confirms the authentication and provides access to the desired service.
Note: it is possible, in a “DID Document”, to assign several authentication keys to different web services and contexts. It is also possible to assign different keys to different uses such as for example message encryption, signing contracts, etc.
Using a DID to authenticate oneself is a simple use case that is important to understand before moving on to the description of Verifiable Credentials which will be the main subject of our next article.