December 30, 2020

What is a DID? (2/3)


What is a DID? (2/3)

In the previous article, we presented different cases of possible uses of DIDs. In this article we will discuss the basic technical characteristics that allow DIDs to solve the problems mentioned in the first article. We will thus introduce the reader to the notions of Verifiable Credentials, public-key cryptography and cryptographic signatures.

Introduction to the DIDs technology

DIDs are a special type of URI (Uniform Resource Identifier) that allows each user to be assigned a sequence of characters that will constitute an anonymous identifier for him. An example of did using syl method would be: “did:syl:6fb56ca533abb42”.
This identifier will be linked to all the claims that are made by Credentials issuers about him and will be stored on the user’s Wallet ID or on an IPFS distributed server.

Verifiable Credentials and Public-Key Cryptography

These documents are called Verifiable Credentials and will allow all entities requiring verification of claims about the DID subject, that is to say the holder of a DID, to verify that they are accurate. Claims about a DID Subject may indeed be made by a trusted third party constituting a Credential.

This can be seen as a chain of trust of the information. From the base of this chain, it will be possible to draw up a list of trusted information issuers such as state institutions, schools, hospitals, companies, etc.

The first DIDs that will be created will have to be theirs. They will then be able to issue Verifiable Credentials containing information about themselves to all other DID users. DID users who have received these Verifiable Credentials can then present the information they contain as trustworthy information, verified and verifiable by all other DID users.

A Credential issued by one of these issuers will be made Verifiable through the apposition of a cryptographic signature by this trusted third party, involving a system of public and private keys. These keys will allow the encryption of information through a one-way cryptographic function. Such a function makes it very easy to encrypt information thanks to the mathematical function contained in one of the two keys but impossible to decrypt it without the knowledge of the other key.

In the case of DIDs, each entity with a DID will possess a set of public keys that can be consulted by all in a Smart Contract called a “DID document”, and a private key that will remain the exclusive possession of the DID subject.

Cryptographic hash functions

To sign a Credential, two processes are at work to guarantee its authenticity: the use of public-key cryptography (process described in the previous paragraph) and cryptographic hash functions.

A hash function is a one-way mathematical function used to obtain a sequence of bytes (a hash) characterizing a set of data. For any initial data set, the resulting hash is always the same. In the context of digital signatures, we will be particularly interested in cryptographic hash functions. These ensure that it is extremely unlikely to create a source data set that gives the same hash as another set. We can therefore use these functions to ensure the integrity of a document.

The combination of cryptographic hash functions and asymmetric public-key cryptography makes it possible to obtain the 5 characteristics of a signature (authentic, forgery-proof, non-reusable, unalterable, irrevocable).

Example of a cryptographic signature

For example, an entity “A” wishes to guarantee by affixing its cryptographic signature that it is the author and issuer of a Credential issued to a DID subject “B”.

Entity “A” generates the hash of the document containing the Credential using a hash function and then encrypts this hash using its private key, which it alone holds.

Entity “A” obtains the signature of its document, which it affixes at the end of the document, and then sends it to DID Subject “B”.

In order to verify the validity of the document, “B” must decrypt the signature using the public key of “A”. If this does not work, the document has not been sent by “A”.

If it works, “B” must generate the hash of the document it received, which now contains the signature of “A” in clear text, using the same hash function as “A” used. It then compares the generated hash with the hash from the signature.

If the two hashes are identical, the signature is validated, ensuring that “A” sent the document and that it has not been modified since it was signed.

This cryptographic signature will then have the same legal value of authenticating a document as its paper equivalent.

With this new knowledge on DIDs technology, we will discuss in the following article how DIDs will be used to avoid the dispersion of its users’ data and why they will constitute a strong counter-power against the big Internet companies.

For more information about XSL Labs’ SDI, you can explore the website where you will find a series of videos and texts presenting the ecosystem developed by XSL Labs as well as the White Paper of the project.

Copyright © 2020 XSL Labs – All rights reserved