Avez-vous déjà oublié vos identifiants de connexion à un site ? Attendu de longues heures en faisant la queue à un guichet pour refaire vos papiers, papiers que vous avez de nouveau égarés le lendemain ? En avez-vous assez d'oublier votre carte de transport et de vous faire verbaliser alors que vous payez bien votre abonnement tous les mois ?
Et si votre identité, vos droits et vos biens étaient rassemblés en une chaîne de caractères ? Et si vous pouviez choisir, de manière atomique, les informations à partager à un tiers sans jamais avoir à justifier de votre identité ?
Cet article aura pour but de vous présenter la Decentralized Identity, son fonctionnement et ses usages. Nous aborderons également le sujet des Verifiable Credentials, très lié à la Decentralized Identity, et utiliserons tout cela par le biais d'un cas d'utilisation auquel vous avez pu faire face : la location d'un appartement.
Une Decentralized Identity (ou “Identité Décentralisée”), est un terme utilisé pour définir l’identité d’un sujet (personne, entreprise, animal, objet etc.). Elle est identifiée par un DID, ou Decentralized Identifier (Decentralized ID) qui est en réalité un URI. Chaque DID est représenté sous une forme similaire. En voici un exemple :
did:ethr:0xb9c5714089478a327f09197987f16f9e5d936e8a
L'URI d'un DID se compose sous la forme suivante :
Pour couvrir plusieurs exemples, nous dirons que notre histoire de location inclut pour l'instant quatre DID différents :
En plus de servir d'identifiant, un DID a pour fonction de faire le lien entre un sujet et un document appelé le DID Document. Un DID Document est un fichier au format JSON comprenant toutes les informations publiques d'un sujet (ses clés pour l'authentification, etc.). Chaque DID Document, dans sa version la plus simple, prend cette forme:
Dans ce document :
De manière générale, le sujet et le contrôleur sont les mêmes personnes, mais il arrive que les deux puissent différer. Par exemple, notre agent 100% indépendant possède un Document DID le concernant mais contrôle également celui de son agence. Il peut donc effectuer diverses opérations au nom de cette dernière. Cette notion induit également le fait qu'un DID peut contrôler plusieurs documents. Le Document DID de l’agence, ci-dessous, illustre ce cas.
Dans ce document :
Vous rappelez-vous de la notion de DID-Method abordée lors de la présentation de la composition d’un DID ? Un DID Document est public et accessible à tous. Les implémentations actuelles de DID nous montrent que les DID Documents sont constitués d’événements sur Blockchain (comme par exemple sur Ethereum). Chaque modification effectuée sur un document DID situé sur Ethereum sera enregistrée dans une transaction. Les événements découlent d’actions de modification du document par son contrôleur. Nous pouvons par exemple retrouver :
Par nature, ce qui est inscrit dans une Blockchain ne peut pas être altéré, alors que les DID Document sont voués à évoluer. Ainsi, pour constituer l’état actuel d’un document, nous nous basons sur la DID-Method renseignée et nous faisons appel à une méthode de “reconstitution” d’un Document. Dans le cas d’Ethereum, cette méthode “ethr” (stockée dans un Smart Contract) regroupe les événements associés à un DID pour en constituer son document à jour. Ce type de méthode se base sur un DID, récupère et ordonne tous les événements le concernant dans le but de dresser le document qui lui est rattaché. C’est par cette méthode que nous arrivons à lire des documents DID à jour, stockés sur Blockchain.
La norme DID est actuellement en Candidate Recommendation auprès de la W3C et l’ensemble des informations la concernant peut être retrouvée ici.
Nous avons vu précédemment qu'un DID Document contenait des informations publiques concernant une personne. Mais qu'en est-il de ses informations privées ?
Un possesseur de DID peut être le sujet de plusieurs assertions (claims) stockées au sein de Verificable Credentials (ou VC). Les VCs ont pour but d’être établies et signées par des entités de confiance (entreprise, gouvernement etc.). Elles ne doivent pas nécessairement contenir d’informations confidentielles concernant leur sujet. Par exemple, pour justifier qu’un adolescent vient d’atteindre ses 18 ans, l’assertion stockée dans la VC délivrée par le gouvernement pourra juste mentionner “Mr.X est majeur”, sans dévoiler sa date de naissance ni son âge. Le fait que cette VC soit signée par le gouvernement certifiera que l’information qu’elle contient est vraie. Notez que les VCs ne sont pas forcément permanentes et que leur validité peut être révoquée par l’entité émettrice.
Les VCs répertorient un ensemble d’assertions faites sur un sujet et font intervenir plusieurs acteurs tous identifiés par des DID :
Dans la majorité des cas, le sujet est également holder de la VC. Cependant, dans certains cas, les deux DIDs peuvent différer. Par exemple, si une personne malade n'est pas en capacité de montrer sa VC, elle peut déléguer la détention de cette dernière à un autre DID qui s'occupera de l'administrer à sa place. Dans notre exemple, vous serez détenteur de cette VC, que vous stockerez sur votre portefeuille VC préféré (sur smartphone, par exemple). Attention cependant, les VCs doivent rester privées, elles peuvent contenir des informations importantes vous concernant. Libre à vous de choisir de quelle manière vous souhaitez les stocker. Par exemple, une solution étudiée du nom de uPort, récemment rebaptisée Veramo, optait pour un stockage entièrement décentralisé : les VCs étaient chiffrés avec un mot de passe et stockés sur IPFS (Interplanetary File-System, une base de données décentralisée).
Pour revenir à notre histoire de location, les deux assertions seront :
Les VC sont sous la forme JWT. Un JWT (ou JSON Web Token), est un jeton d’accès permettant l’échange de données sécurisées entre deux parties. Il contient toutes les informations d’une entité et est principalement utilisé lors de processus d’identification. Dans notre cas, la VC aurait cette forme :
Etudions cette VC plus en détail par le biais de plusieurs champs importants :
“id” : ID de la claim. Ici, elle est répertoriée à l’indice 1997 de toutes les claims fournies par l’agence.
“issuer” : Issuer de la claim. Ici, l’agent, possédant l’ID 0203 sera issuer de cette claim. Notez que son DID n’est pas référencé ici mais il pourrait bien l’être. Établissons que l’URL noté pointe vers le DID de l’agent.
“issuanceDate” : Date à laquelle la VC a été délivrée.
“credentialSubject” : Contient les assertions faites sur le Subject.
“nonTransferable” : “True” si VC ne peut pas être affichée dans une VP n’ayant pas été signée par le sujet de la VC. “False” sinon. Nous étudions le concept de VP juste après.
“proof” : preuve digitale rendant la VC valide.
Les VC ne sont pas directement rattachées à un DID Document et il n'est ainsi aucunement fait mention de leur existence au sein du Document. Le DID Document de l’émetteur de la VC joue cependant un rôle important étant donné qu’il contient la clé publique permettant de vérifier la véracité de la VC.
Si le possesseur d’une ou plusieurs VC veut partager les informations qu’elles contiennent avec quelqu’un d’autre, il doit regrouper les informations à partager sous la forme d’une Verifiable Presentation (VP) à la place.
Une VP est également de la forme JWT et contient des informations d’une ou plusieurs VC.
En utilisant votre portefeuille virtuel, vous serez en mesure de générer une VP de votre toute nouvelle VC remise par l’agence. Cette VP pourra alors être présentée en guise de justificatif d’habitation à un organisme tel que la CAF lors de la constitution de votre dossier.
Elle aura cette forme :
En étudiant cette VP, nous remarquons que le contenu entier de la VC précédente est stocké au sein d’un tableau pouvant contenir plusieurs VC. Ainsi, une VP peut contenir plusieurs VC. La partie “proof” située en bas de la VP est cette fois signée par le détenteur de cette VC, son sujet. La clé permettant de vérifier la validité de cette VP est la clé publique “keys-1” située dans le DID Document du signataire.
Les VP sont destinées à être présentées à une entité appelée Verifier. La relation entre Issuer, Holder et Verifier est présentée comme telle :
Votre dossier terminé, vos clés d’appartement dans la poche et votre Verifiable Credential dans votre portefeuille, vous voilà prêt à emménager !
Vous n’oublierez bien sûr pas de voir si vous êtes éligibles pour quelconques aides en présentant la Verifiable Presentation découlant de votre Verifiable Credential.
Dans cet article, nous avons pu suivre le déroulement d’un cas d’utilisation décrivant l’utilisation de trois ressources liées au concept de DID :
Si vous souhaitez en savoir plus sur les notions étudiées, je vous invite à consulter les articles du W3C faisant mention de chacun d’entre eux.
Le concept de DID est très récent (2019), il n’a donc pas encore atteint son stade de maturité. Mis à part les documents officiels du W3C, il est encore difficile de se documenter convenablement sur la technologie ou de présenter quelconques proof-of-concepts.
En soit, l’implémentation des DID s’appuie sur des technologies existantes bien que relativement récentes autour de la Blockchain principalement.
La Blockchain identifie déjà ses comptes par le biais d’identifiants uniques. Réutiliser ces identifiants dans le but de démocratiser l’utilisation des DID le plus rapidement possible est une stratégie bien pensée. Ainsi, vous aurez pu remarquer que le DID “ethr” présenté au début de cet article possède, en guise d’identifiant unique, une clé publique Ethereum. Tous les possesseurs de comptes Ethereum possèdent déjà, sans forcément le savoir, un DID valide. Il en va de même pour les Blockchain possédant déjà leurs propres DID-Method (ou Resolver). DID est déjà là, reste à savoir comment bien l’utiliser, faciliter le stockage des VC et l'implémentation des ressources qui lui sont liées (VC, VP…). Cette technologie n’en est qu’à ses débuts mais n’en reste pas moins prometteuse.