March 11, 2021

Technical Document – Part 3

5 MIN READ – TEAM XSL LABS

Share on facebook
Share on twitter
Share on linkedin
Share on telegram
Share on whatsapp

Technical Document – Part 3

Multiple chains of trust

In order for an identity wallet owner to obtain various verifiable information about himself, it is necessary that a trusted issuer has been previously identified and contacted. Confidence in this ” Verifiable Credentials ” issuer must itself be linked to verifiable information about its own identity and its qualification as an issuer.

Following the example of Public Key Infrastructures (PKI), a chain of trust must be able to be traced without breaking to guarantee the reliability of the identity of all the players in the chain and indirectly the reliability of the transmitted information.

Without going into detail about the content of a “Verifiable Credential”, let’s take the simple case of a Verifiable Credential (VC) of the “surname” type. This information can be validated by an issuer qualified as a “KYC service provider”, but before this, the reliability of the identity of the issuer itself must also be verified through its own DID.

By going up this chain of trust, we find the first link in the chain. This is the highest verified identity: the root authority. In the context of blockchain queryable DIDs, it generally consists of a DID of the Smart Contract administrator. However, DIDs and blockchains can also be changed provided that the wallet or tool that seeks to verify a VC can trace the chain of trust of DIDs between different blockchains.

It is also possible to not make it mandatory for the root authority to have a real DID, but instead to have at least one identity linked to a certificate issued by a certification authority (as is the case for SSL/TLS certificates), public identity certificates from government agencies, etc.

This multiple choice of root authorities makes it possible to increase the decentralization of the architecture. However, it requires that work be done by XSL Labs to technically help these different “authorities” to establish themselves as the root authorities in the ecosystem so that the user can easily judge the reliability of the identities of these “authorities”.

The illustration below evokes a simple case where the chain of trust is short. However, there could be an additional player between the administrator and the user, for example.

Figure 3-1: Verifying a VC also involves going up the chain of trust to check the identities involved.

Figure 3-1: Verifying a VC also involves going up the chain of trust to check the identities involved.

In order for the user to obtain a Verifiable Credential, it is necessary to request it from an identity provider (Verifiable Credential issuer)… whose legitimacy has been previously verified. The diagram below details the steps of this verification procedure:

Figure 3-2: How to verify that an Identity Provider is trustworthy?

Figure 3-2: How to verify that an Identity Provider is trustworthy?

The user can be directed to a VC issuer or decide on his own to go to a recognized provider. The very notion of verifiable information that can be presented several times with the same reliability will certainly lead to changes in user behavior and journey.

It should also be noted that the proprietary user with a verified identity could in turn issue a Verifiable Credential for another user. But before addressing these special cases of peer-to-peer Verifiable Credentials, we will discuss the simple use case of identity providers (public issuers of Verifiable Credentials with a well-identified role, separate from standard users). In the previous post we have detailed the content of a user’s DID Document, let’s see below the DID document of a public issuer of VC.

Figure 3-3 - DID Document of a public issuer of Verifiable Credential

Figure 3-3 – DID Document of a public issuer of Verifiable Credential

The main difference is in the availability of a public profile on ipfs, here :

{“type”: “Profile”,
“id”: “IPFS”,
“name”: “XSL Labs”,
“image”:
“https://ipfs.infura.io/ipfs/QmXV2ZEMMom4Z9ciFzgNnpJ33oPipb3rzbWe4J5GBfFDSb”,
“url”: “https://www.xsl-labs.io/en/”,
“email”: “contact@xsl-labs.io”}

As a reminder, IPFS is a public decentralized storage space where files are referenced by their hash. Thus the XML content of the above file comes from the ipfs file “QmXV2ZEMMom4Z9ciFzgNnpJ33oPipb3rzbWe4J5GB” that can be easily found with an ipfs software client. Web browsers are progressively integrating the ability to read these files on the ipfs network but for the moment, it is still preferable to use web gateway services like the one of infura (infura.io) to easily consult the ipfs network, adding “https://ipfs.infura.io/ipfs/” to the ipfs reference like this :

https://ipfs.infura.io/ipfs/QmXV2ZEMMom4Z9ciFzgNnpJ33oPipb3rzbWe4J5GB

The files stored on ipfs are not directly deletable, it must be assumed that they can remain available for a long time for everyone. It is therefore necessary to indicate only neutral and non-nominative information (example: website + generic contact email).

To verify the legitimacy of a VC issuer, the user can then (with the automatic help of his wallet app) query the Smart Contract that manages his DID to obtain a list of Verifiable Credentials traces that the issuer has previously received himself. In this way, the verifier software client will find the trace of a Verifiable Credential provided by the administrator to qualify its role as Identity Provider (and VC Provider) in the form of an ipfs reference (“ipfs url”) and reliable timestamp information linked to the blockchain in use. The ipfs reference enables the public content of the Verifiable Credential provided by the administrator to this VC issuer to be retrieved. The client wallet can then verify the signature of this VC by the admin and conclude that the issuer is legitimate.

Request and receipt of a “Verifiable Credential”.

If the VC issuer is deemed to be trustworthy, here are the steps required to request and obtain a Verifiable Credential:

– The user follows the KYC procedure and uses his DID private key to sign a request for a VC (here a simple nationality verification).

– The issuer verifies the signature of this request (by consulting the user’s DID Document).

– The issuer uses its own private key to sign a Verifiable Credential corresponding to the information verified in the official documents. This operation can be performed via a web interface or API if the issuer’s key is protected on a Hardware Security Module. It can also be performed on a local machine with enhanced security provided by the administrators of the XSL Labs solution, which will include a mini software wallet in the form of a smart card reserved for identity providers. The primary goal of this type of all-in-one solution is to secure and simplify the life of VC issuers.

Figure 3-4 - Local station for Verifiable Credential issuer with smart card wallet

Figure 3-4 – Local station for Verifiable Credential issuer with smart card wallet

– The issuer creates an on-chain public trace of this Verifiable Credential by associating the hash of this VC with a time stamp information (reliable / linked to the blockchain).

– The issuer sends the Verifiable Credential to the user who requests it.

Figure 3-5 - Steps in requesting and receiving a Verifiable Credential

Figure 3-5 – Steps in requesting and receiving a Verifiable Credential

 

“Verifiable Credential”: creation, content and verification

The “Verifiable Credential” can be transmitted from its author to its receiver by email, face-to-face via QR code, by file transfer, social network, API, etc. The identity wallet of the requester (initial receiver) will interpret its content and perform the first complete verification of this Credential before importing it.

Figure 3-6 - Example of a Verifiable Credential given by a university to one of its members

Figure 3-6 – Example of a Verifiable Credential given by a university to one of its members

The VC contains the following information :

– A header to indicate that this file is a Verifiable Credential.

– Metadata” containing here the issuer’s DID and the creation date (but which may also contain for example an expiration date, an associated image, details on a revocation mechanism, etc.).

– The “claimed data” (Claims)

– The DID of the receiver / owner

– Information previously verified by the issuer (in this case being a member of the university)

– The “proof” in the form of a signature of this set by the issuer’s private key

This VC is sent to its owner, who can check it and present it on request. When the VC is retransmitted by the user, each new receiver will also be able to perform this Verifiable Credential verification.

The verification therefore consists of going back and checking from the Verifiable Credential:

– the owner’s DID

– the issuer’s DID (See Figure 3-2 above to verify its legitimacy)

– the Verifiable Credential signature

Figure 3-7 - Steps in Verifying a Verifiable Credential

Figure 3-7 – Steps in Verifying a Verifiable Credential

 

“Verifiable Presentation”: request, content and verification

The presentation of Verifiable Credential is usually done through another file format, the “Verifiable Presentation”. This format takes the Verifiable Credential and associates it with a signature linked to a challenge sent by the person requesting the Verifiable Credential, to avoid any form of replay.

Figure 3-8 - Requesting and obtaining a "Verifiable Presentation" (signed Verifiable Credential)

Figure 3-8 – Requesting and obtaining a “Verifiable Presentation” (signed Verifiable Credential)

Each “Verifiable Presentation” is unique and specific to the context of a specific request and event. The request can be presented in the form of a QR code directly readable by the DID wallet app: ONE.

Figure 3-9 - Steps in Verifying a Verifiable Credential

Figure 3-9 – Steps in Verifying a Verifiable Credential

The owner of the wallet and the “Verifiable Credential” is therefore informed of the context before signing it to create the “Verifiable Presentation”.

The “Verifiable Presentation” can be sent back to the requester via an address specified in the request details (or in the “domain”) or via a QR code if the requester has made the request face to face. The requester or someone intercepting the Verifiable Presentation could not reuse it in another context.

The requester who receives the Verifiable Presentation will therefore be able to verify that he is dealing with the owner of the Verifiable Credential by verifying the signature of the Verifiable Presentation and consulting the owner’s DID Document before verifying the Verifiable Credential.

Copyright © 2020 XSL Labs – All rights reserved