DID, l’identité numérique décentralisée

le 26/08/2021 par Tristan ALLAIRE
Tags: Cloud & Platform

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.

Qu'est-ce qu'un DID ?

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 :

  • did : préfixe de tout DID.
  • <DID-Method> : définition de l'implémentation du DID. Chaque DID est lié à une méthode qui spécifie le protocole gérant le DID étudié. Par exemple, un DID géré sur la blockchain Ethereum possédera "ethr" ici, “tz” s’il est géré sur Tezos ou encore “ion” sur Bitcoin. Une liste des différentes méthodes peut être consultée sur le DID Specification Registries du W3C. On parle également de "Resolver".
  • <UNIQUE_IDENTIFIER> : Identifiant unique.

Pour couvrir plusieurs exemples, nous dirons que notre histoire de location inclut pour l'instant quatre DID différents :

  • Un pour vous, futur locataire
  • Un pour votre agence immobilière
  • Un pour l'agent s'occupant de votre dossier. Nous dirons qu’il est aux commandes de son agence
  • Un pour votre potentiel futur appartement.

À quoi sert-il ?

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 :

  • “id” : fait référence au DID auquel ce document se rattache, son sujet, la personne, morale ou physique, désignée par le document.
  • “authentication” : fait référence aux clés publiques référencées dans ce document. Nous verrons une de leurs utilités plus tard dans cet article.
  • Par défaut, chaque document possède une clé publique,spécifiant le “contrôleur” du document, personne, morale ou physique, possédant le document. Elle est formée de la sorte :
    • “id” : identifiant de la clé, c’est cette valeur à laquelle nous ferons référence quand nous voudrons accéder à une clé. Elle est la concaténation du DID du sujet et du suffixe “#<NOM-CLE>”.
    • “type” : type de clé.
    • “controller” : DID de la personne contrôlant le document.
    • “publickKeyMultibase” : clé publique en question.

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 :

  • “id” : fait référence au DID de l’agence.
  • “controller” : fait référence au DID de l’agent. Quand ce champ est absent, le DID spécifié dans le champ “id” prend le contrôle. Ce champ peut également prendre la forme d’un tableau spécifiant tous les DID ayant le contrôle du document. Si le DID spécifié dans “id” est absent de ce champ, alors ce DID ne peut contrôler le 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 :

  • Des ajouts ou suppressions de clés publiques ;
  • Des transferts de contrôleur pour le document ;
  • ...

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.

Verifiable Credentials et Verifiable Presentations, deux extensions au DID

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 :

  • L'Issuer : entité donnant et signant la VC. Dans notre cas, l’agent de l’agence immobilière.
  • Le Subject : sujet concerné par la VC. Ici, vous, futur locataire.
  • Le Holder : entité recevant la VC et ayant comme fonction de la stocker.

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 :

  • L'appartement situé X Rue de Y est votre location.
  • La place de parking numéro 24 située sous votre immeuble vous est réservée.

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.

    • “id” : DID du sujet de la VC.
    • “tenantOf” : traduisez par “locataire de”. C’est la première assertion faite sur le sujet. Elle contient l’adresse de l’appartement ainsi que son DID.
    • “parking” : Seconde assertion faite sur le sujet. Elle contient le DID du parking ainsi que l’emplacement réservé.

  • “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.

    • “verificationMethod” : contient la clé publique permettant de vérifier la véracité de cette preuve. L’URL présent ici fait référence à une clé située dans le DID Document de l’issuer.
    • “jws” : ici fait référence à la “JSON Web Signature” et garantit l’intégrité des informations contenues dans le JWT. On peut alors parler de “JWT signé”. La présence de ce champ prouve que l’issuer a validé et signé le contenu de la VC.

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.

Conclusion

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 :

  • DID Document : document donnant des informations publiques sur un sujet.
  • Verifiable Credential : ensemble d’assertions faites sur un sujet concaténées en un document signé par une entité.
  • Verifiable Presentation : document généré par le détenteur d’une ou plusieurs VC regroupant des informations à présenter à un Verifier.

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.