March 11, 2021

Document technique – Partie 3

5 MIN READ – TEAM XSL LABS

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

Document Technique – Partie 3

Chaînes de confiance multiples

Pour qu’un propriétaire de portefeuille d’identité puisse obtenir différentes informations vérifiables à son sujet, il est nécessaire qu’un émetteur de confiance ait été préalablement identifié et contacté. La confiance en cet émetteur de “Verifiable Credentials” doit elle-même être liée à des informations vérifiables sur sa propre identité et sa qualification d’émetteur.

A l’instar des Infrastructures de Gestion des Clés Publiques (IGCP / PKI), une chaîne de confiance doit pouvoir être remontée sans cassure pour garantir la fiabilité de l’identité de tous les acteurs de la chaîne et indirectement la fiabilité de l’information transmise.

Sans rentrer tout de suite dans le détail du contenu d’un “Verifiable Credential”, prenons le cas simple d’une information vérifiable (VC) de type “nom de famille”. Cette information peut être validée par un émetteur qualifié de “fournisseur de service de KYC”, mais il faudra avant cela également vérifier la fiabilité de l’identité de l’émetteur lui-même à travers son propre DID.

En remontant cette chaîne de confiance, on trouve le premier maillon de la chaîne. C’est l’identité vérifiée la plus haute : l’autorité racine. Dans le cadre de DIDs interrogeables sur blockchain, il s’agit généralement d’un DID de l’administrateur du Smart Contract. Cependant, il peut aussi y avoir des changements de DID et de blockchain pourvu que le portefeuille ou l’outil qui cherche à vérifier un VC sache remonter la chaîne de confiance des DIDs entre différentes blockchains.

Il est aussi possible de ne pas rendre obligatoire le fait que l’autorité racine possède un véritable DID mais qu’elle possède au moins une identité liée à un certificat délivré par une autorité de certification (comme c’est le cas pour des certificats SSL/TLS), des certificats d’identités publiques d’organismes étatiques, etc.

Ce choix multiple d’autorités racines permet d’augmenter la décentralisation de l’architecture. Il sera néanmoins nécessaire pour XSL Labs de travailler à l’accompagnement de ces différentes « autorités » afin que l’utilisateur puisse juger facilement de la fiabilité des identités de ces autorités.

L’illustration ci-dessous évoque un cas simple où la chaîne de confiance est courte. Il pourrait cependant exister un acteur supplémentaire entre l’administrateur et l’utilisateur par exemple.

Illustration 3-1 : Vérifier un VC implique aussi de remonter la chaîne de confiance pour contrôler les identités impliquées

Illustration 3-1 : Vérifier un VC implique aussi de remonter la chaîne de confiance pour contrôler les identités impliquées

Afin que l’utilisateur obtienne un Verifiable Credential il faut le demander à un fournisseur d’identité (émetteur de Verifiable Credential)… dont il a fallu vérifier la légitimité auparavant. Le schéma ci-dessous détaille les étapes de cette procédure de vérification :

Illustration 3-2 : Comment vérifier qu’un fournisseur d’identité est digne de confiance ? 

Illustration 3-2 : Comment vérifier qu’un fournisseur d’identité est digne de confiance ? 

L’utilisateur peut être dirigé vers un émetteur de VC ou décider de lui-même d’aller vers un prestataire reconnu. La notion même d’informations vérifiables présentables plusieurs fois avec la même fiabilité entraînera certainement des modifications de comportement et de parcours utilisateurs.

Il est à noter aussi que l’utilisateur propriétaire possédant une identité vérifiée pourrait lui aussi à son tour émettre un Verifiable Credential pour un autre utilisateur. Mais avant d’aborder ces cas spéciaux de Verifiable Credentials en pair à pair, nous allons évoquer le cas d’usage simple des fournisseurs d’identité (émetteurs publics de Verifiable Credential au rôle bien identifié, séparés des utilisateurs standard). Dans le billet précédent nous avons détaillé le contenu du DID Document d’un utilisateur, voyons ci-dessous le DID document d’un émetteur public de VC.

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

Illustration 3-3 – DID Document d’un émetteur public de Verifiable Credential

La différence principale se situe dans la mise à disponibilité d’un profil public sur ipfs, ici :

{“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”}

Pour rappel, IPFS est un espace de stockage décentralisé public où les fichiers sont référencés par leur hash. Ainsi le contenu XML du fichier ci-dessus provient du fichier ipfs “QmXV2ZEMMom4Z9ciFzgNnpJ33oPipb3rzbWe4J5GB” que l’on peut retrouver facilement avec un client logiciel ipfs. Les navigateurs web intègrent progressivement la capacité de lecture de ces fichiers sur le réseau ipfs mais pour le moment, il est encore préférable d’utiliser les services de passerelle web comme celle d’infura (infura.io) pour consulter facilement le réseau ipfs, en ajoutant “https://ipfs.infura.io/ipfs/” à la référence ipfs ainsi :

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

Les fichiers stockés sur ipfs ne sont pas supprimables directement, il faut partir du principe qu’ils peuvent rester disponibles longtemps pour tous. Il est donc nécessaire de n’indiquer que des informations neutres et non-nominatives (exemple : site web + mail de contact générique).

Pour vérifier la légitimité d’un émetteur de VC, l’utilisateur peut ensuite (avec l’aide automatique de son portefeuille logiciel) interroger le Smart Contract qui gère son DID pour obtenir une liste de traces de Verifiable Credentials que l’émetteur a précédemment lui-même reçu. Ainsi, le client logiciel vérificateur trouvera la trace d’un Verifiable Credential fourni par l’administrateur pour qualifier son rôle de fournisseur d’identité (et de fournisseur de VC) sous la forme d’une référence ipfs (“ipfs url”) et d’une information d’horodatage fiable liée à la blockchain utilisée. La référence ipfs permet de retrouver le contenu public du Verifiable Credential fourni par l’administrateur à cet émetteur de VC. Le portefeuille client peut alors vérifier la signature de ce VC par l’admin et conclure à la légitimité de l’émetteur.

Demande et réception d’un “Verifiable Credential”

Pour peu que l’émetteur de VC soit jugé de confiance, Voici les étapes nécessaires à la requête puis à l’obtention d’un Verifiable Credential :
– L’utilisateur suit la procédure de KYC et utilise sa clé privée de DID pour signer une requête de demande de VC (ici la simple vérification de nationalité).
– L’émetteur vérifie la signature de cette requête (en consultant le DID Document de l’utilisateur)
– L’émetteur utilise sa propre clé privée pour signer un Verifiable Credential correspondant à l’information vérifiée dans les documents officiels. Cette opération peut être effectuée via une interface web ou API si la clé de l’émetteur est protégée sur un Hardware Security Module. Elle peut aussi être réalisée sur une machine locale à la sécurité renforcée fournie par les administrateurs de la solution XSL Labs et qui comprendra notamment un mini-portefeuille logiciel sous la forme d’une carte à puce réservée aux fournisseurs d’identité. Le but premier de ce type de solution tout-en-un étant de sécuriser et simplifier la vie des émetteurs de VC.

Illustration  3-4 - Station locale pour émetteur de Verifiable Credential avec portefeuille sur carte à puce

Illustration  3-4 – Station locale pour émetteur de Verifiable Credential avec portefeuille sur carte à puce

– L’émetteur crée ‘on-chain’ une trace publique de ce Verifiable Credential en associant le hash de ce VC avec une information d’horodatage (fiable / liée à la blockchain).
– L’émetteur envoie le Verifiable Credential à l’utilisateur qui lui en fait la demande.

Illustration 3-5 - Les étapes de la demande et de la réception d’un Verifiable Credential 

Illustration 3-5 – Les étapes de la demande et de la réception d’un Verifiable Credential 

 

“Verifiable Credential” : création, contenu et vérification

Le “Verifiable Credential” peut être transmis de son auteur à son destinataire par mail, QR code en face à face, transfert de fichier, réseau social, API, etc. Le portefeuille d’identité du demandeur (destinataire initial) interprètera son contenu et effectuera la première vérification complète de ce Credential avant de l’importer.

Illustration 3-6 - Exemple de Verifiable Credential donné par une université à un de ses membres

Illustration 3-6 – Exemple de Verifiable Credential donné par une université à un de ses membres

Le VC contient les informations suivantes :
– Une entête pour indiquer que ce fichier est un Verifiable Credential.
– Des “metadonnées” contenant ici le DID de l’émetteur et la date de création (mais pouvant contenir aussi par exemple une date d’expiration, une image associée, des détails sur un mécanisme de révocation, etc.)
– Les “données affirmées/revendiquées” (Claims)
– Le DID du destinataire / propriétaire
– L’information précédemment vérifiée par l’émetteur (ici le fait d’être membre de l’université)
– La “preuve” sous la forme d’une signature de cet ensemble par la clé privée de l’émetteur

Ce VC est envoyé à son propriétaire qui peut ainsi le vérifier et le représenter à la demande. Quand le VC sera retransmis par l’utilisateur, chaque nouveau destinataire pourra lui aussi effectuer cette vérification du Verifiable Credential.

La vérification consiste donc à remonter et vérifier depuis le Verifiable Credential :
– le DID du propriétaire
– le DID de l’émetteur (Voir Illustration 3-2 précédente pour vérifier sa légitimité)
– la signature du Verifiable Credential

Illustration 3-7 - Étapes de la vérification d’un Verifiable Credential

Illustration 3-7 – Étapes de la vérification d’un Verifiable Credential

 

“Verifiable Presentation” : requête, contenu et vérification

La présentation du Verifiable Credential se fait généralement à travers un autre format de fichier, le “Verifiable Presentation”. Celui-ci reprend le Verifiable Credential et l’associe à une signature liée à un challenge envoyé par celui qui demande le Verifiable Credential, pour éviter toute forme de réutilisation (rejeu).

Illustration 3-8 - Requête et obtention d’une “Verifiable Presentation” (Verifiable Credential signé)

Illustration 3-8 – Requête et obtention d’une “Verifiable Presentation” (Verifiable Credential signé)

Chaque “Verifiable Presentation” est unique et propre au contexte d’une requête et d’un évènement précis. La requête peut être présentée sous la forme d’un QR code directement lisible par l’application de portefeuille DID, ONE.

Illustration 3-9 - Étapes de la vérification d’un Verifiable Credential

Illustration 3-9 – Étapes de la vérification d’un Verifiable Credential

Le propriétaire du wallet et du “Verifiable Credential” est donc informé du contexte avant de le signer pour créer la “Verifiable Presentation”.

La “Verifiable Presentation” peut être renvoyée au demandeur via une adresse spécifiée dans les détails de la requête (ou dans le “domain”) ou de visu via un QR code si le demandeur a effectué la demande en face à face. Le demandeur ou quelqu’un qui intercepterait la “Verifiable Presentation” ne pourrait pas la réutiliser dans un autre contexte.

Le demandeur qui reçoit la “Verifiable Presentation” pourra donc vérifier qu’il a bien affaire au propriétaire du “Verifiable Credential” en vérifiant la signature de la “Verifiable Presentation” en consultant le DID Document de son propriétaire avant de vérifier le “Verifiable Credential”.

Copyright © 2020 XSL Labs – All rights reserved