February 1, 2021

Document technique – Partie 2

5 MIN READ – TEAM XSL LABS

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

Document Technique – Partie 2

Le DID n’est qu’un identifiant

Dans le premier article de ce document technique nous avons vu qu’un “DID” (Decentralized IDentifier) était un identifiant unique, une adresse que l’on pouvait résoudre, de la même façon que l’adresse d’une page web. Seulement le DID est une adresse qui permet d’accéder à un document, le “DID Document” (parfois aussi appelé “DDO”).

En ce qui concerne le projet de XSL Labs, le SDI (Secure Digital Identity) est un donc “DID”. Autrement dit, le SDI est un identifiant permettant d’obtenir un “DID Document” présent sur une blockchain publique, que l’on peut aussi nommer ici “SDI Document”.

L’identifiant DID référence un “DID Document”

Ce DID Document constitue le profil public essentiel de l’utilisateur. Il n’a pas vocation à contenir beaucoup d’informations, et puisqu’il est public et disponible sur une blockchain publique, il ne doit pas contenir d’informations d’identité personnelles, telles que nom, date de naissance, etc.

Nous verrons qu’il est assez aisé d’étendre à de nouveaux types les informations qu’il est possible d’ajouter dans un DID Document, notamment grâce aux travaux de standardisation en cours d’élaboration qui définissent les contenus possibles pour un tel document, sa syntaxe, son organisation, etc.

Un secteur innovant et des efforts récents de standardisation

Les recherches concernant les identités décentralisées sont toutes très récentes et liées au concept de “Self-Sovereign Identity” (SSI) ou Identité Souveraine en français qui décrit la capacité pour les utilisateurs à maîtriser directement leurs données personnelles, à pouvoir les stocker, les présenter et les rendre vérifiables sans avoir à solliciter un intermédiaire de confiance lors de chaque présentation.

Les premières identités décentralisées utilisant une blockchain datent des années 2017 et 2018 avec les blockchains publiques de Sovrin et d’Ontology, les expérimentations de Microsoft sur Bitcoin et la publication du contrat uPort sur Ethereum.

Ces solutions sont l’aboutissement de nombreux travaux antérieurs (liste non-exhaustive) :
– la “toile de confiance” (Web of Trust) de Phil Zimmerman, inventeur de PGP, évoquée dès les années 90,
– les publication de Carl Ellison sur les identités sans autorités de certification à la même période,
– les lois de l’identité (The Laws of Identity) de Kim Cameron en 2005,
– les travaux d’Audun Jøsang et de Simon Pope sur la gestion des identités par l’utilisateur (User centric identity management) aussi en 2005,
– les premiers travaux en 2006 sur les références vérifiables du W3C qui parlaient d’abord de “Verifiable Claims” avant d’utiliser le terme de “Verifiable Credentials”,
– les réflexions de Moxie Marlinspike (inventeur de la messagerie Signal) sur ces sujets dès 2012,
– les articles de Christopher Allen (co-inventeur du standard SSL/TLS et bien connu aujourd’hui dans l’univers “crypto” pour être l’architecte principal de Blockstream) sur les notions de vie privée, autour d’identités fractionnées et maîtrisées (“personal and contextual privacy”) en 2015, puis sur le étapes à franchir afin de réaliser l’idéal d’une véritable “Self-Sovereign Identity” en 2016.
– le White Paper publié lors des premiers ateliers du “Rebooting the Web of Trust” de 2015 qui décrivait la nécessité d’une infrastructure à clés publiques (ICP) décentralisée (DPKI), dont Vitalik Buterin est l’un des nombreux co-auteurs avec Christopher Allen.

En 2017, avec les premières expérimentations publiques sur les identités décentralisés, la Decentralized Identity Foundation (DIF / https://identity.foundation) a commencé à lister les méthodes de résolution des DIDs pour constituer un “Universal Resolver” (https://github.com/decentralized-identity/universal-resolver/) qui permet à chaque fournisseur de service souhaitant interagir avec un DID présenté par un utilisateur de retrouver le DID Document qui lui est associé. 

C’est ce tableau de correspondance que l’on retrouvera plus tard référencé dans le premier document du groupe de travail du W3C sur les DIDs :  https://w3c.github.io/did-core/

La sortie de ce document sur les DIDs, finalisé en 2019, a été une avancée majeure puisque le World Wide Web Consortium (W3C) est le principal organisme de standardisation des technologies d’Internet (on lui doit déjà entre autres les standards HTML, DOM, PNG, XML…).

XSL Labs rejoindra prochainement la Decentralized Identity Foundation (DIF) afin de faire lister sa propre méthode DID dans le tableau officiel de résolution des DID. Quelle que soit la technologie de blockchain retenue, il y aura ainsi dans tous les cas une information publique standardisée pour résoudre le SDI (DID) en un document SDI (DID Document).

Le DID Document (DDO)

Maintenant que nous savons qu’un identifiant DID est toujours associé à un DID Document et que ce document ne contient pas directement d’informations personnelles, voyons ce que ce document peut contenir principalement :
– des sous identifiants pour se repérer dans le DID Document,
– des clés publiques,
– des informations associées à ces clés publiques à propos des services et des usages concernés,
– des informations sur le créateur du DID Document avec des dates de création / de mise à jour,
– une signature.

Rappel : Les clés publiques (et indirectement les adresses “crypto” publiques) sont liées de façon mathématique à des clés privées qui doivent demeurer dans le wallet de leur propriétaire, sous son contrôle exclusif. Les clés privées servent à signer des données (documents, transactions, preuves, etc.) et les clés publiques permettent de vérifier la validité de ces signatures. 

Nous prendrons ici l’exemple d’un DID et un DID Document liés à un individu, mais gardons à l’esprit qu’un DID peut également être associé à une personne morale, à un objet, à une organisation…

Voici un exemple de DID Document (au format standard JSON / JSON-LD):

DID Document correspondant au DID “did:syl:aea42randn1awa3xzhjkbvc33”Illustration 2-1 : le DID Document correspondant au DID “did:syl:aea42randn1awa3xzhjkbvc33” 

Pour rappel, ce document est la résolution du DID “did:syl:aea42randn1awa3xzhjkbvc33”. Pour trouver ce document, il faut suivre la piste des différentes parties entre “:”. Ainsi, “did” indique un protocole d’identité décentralisée, tout comme “http” indique un protocole de communication serveur/client pour naviguer sur le World Wide Web. “syl” correspond à la méthode DID utilisée et il faut alors consulter la liste officielle des méthodes DID (https://w3c.github.io/did-spec-registries/#did-methods) pour savoir à quoi elle correspond. 

Une fois la méthode trouvée (exemple : il s’agit du smart contrat 0xb9c15…98e246504 sur Ethereum), il suffit d’utiliser la fin de l’identifiant pour trouver le DID Document final, ici on interroge donc le smart contract avec l’identifiant “aea42randn1awa3xzhjkbvc33” (il s’agit généralement d’un identifiant aléatoire attribué à la création du DID, nous reviendrons dans un autre article sur cette phase initiale). Que ce soit directement via un smart contract principal ou bien à travers des smart contracts individuels, la documentation de la méthode DID permet d’obtenir le DID Document, la “résolution” du DID.

Le contenu rudimentaire du DID Document donné en exemple / illustration plus haut peut être bien plus divers et détaillé mais cet exemple nous permet d’avoir une vision d’ensemble simple de ce type de documents afin d’en expliquer les différentes parties.

“@context”: “https://www.w3.org/ns/did/v1”
Cette ligne indique qu’il s’agit d’un DID Document.

“id”: “did:syl:aea42randn1awa3xzhjkbvc33”
Ce premier “id” indique l’adresse du DID que ce DID Document résout (qui lui est associé).

“controller”: “did:syl:aea42randn1awa3xzhjkbvc33”
Cette première indication de “controller” spécifie qui contrôle ce DID et peut y effectuer des modifications. Ici nous sommes en présence du cas le plus simple, l’identité du contrôleur est la même que l’identité qui est décrite dans le “DID Document”.

De prime abord, cela peut sembler être la seule possibilité. Cependant, bien d’autres cas de figure sont envisageables qui ont une utilité dans les situations suivantes (liste non-exhaustive) :
– Une personne utilise plusieurs wallets différents pour contrôler une même identité,
– Une personne utilise un seul wallet pour contrôler plusieurs identités,
– Une personne adulte gère certaines parties de l’identité décentralisée d’un enfant,
– Une personne délègue à un tiers de confiance certains droits sur la totalité ou sur une partie de son identité,
– etc.

“authentication”: [{
    “id”: “did:syl:aea42randn1awa3xzhjkbvc33#authkey”,
    “type”: “EcdsaSecp256k1KeyFID2021”,
    “controller”: “did:syl:aea42randn1awa3xzhjkbvc33”,
    “publicKeyBase58”:
    “mM3wnZ3wXmC2AVvLNakc6zjZpfm3uJCwDMv6gVAnHqPV”
  }]

Cette section décrit comment authentifier (par défaut) le propriétaire de ce DID en insérant directement une clé publique d’authentification. 

Le nouvel “id” qui se termine par #authkey permet de renvoyer directement à cette section. Ainsi, ici, le DID est “did:syl:aea42randn1awa3xzhjkbvc33” mais si on souhaite indiquer directement la clé qui sert d’authentification on peut écrire “did:syl:aea42randn1awa3xzhjkbvc33#authkey”, un peu comme lorsque que l’on pointe directement sur une ancre dans une page html afin d’atteindre directement une section en bas de page.

Le “type” donne l’algorithme de signature numérique à clé publique utilisée pour l’authentification, ici la variante de DSA utilisant la cryptographie sur courbes elliptiques.

Le “controller” redonne le DID responsable de cette section. Ici encore nous sommes devant le cas le plus simple puisque que la référence est identique au propriétaire de l’identité.

“publicKeyBase58” est suivi de la valeur de la clé publique encodée en base 58.

Poursuivons l’étude du contenu de ce DID Document. Vous verrez un peu plus loin comment un service web externe peut concrètement utiliser cette section pour authentifier un nouvel utilisateur se présentant avec son DID.

“service”: [
    “id”:”did:syl:aea42randn1awa3xzhjkbvc33#webvc”,
    “type”: “VerifiableCredentialService”,
    “serviceEndpoint”: “https://example.com/vcheck”
  }]

Nous reviendrons dans le détail sur les Verifiable Credentials dans un prochain billet mais pour le moment retenons que ces Credentials sont des données généralement vérifiables, disponibles à l’intérieur des wallets des utilisateurs mais qu’il est parfois utile et nécessaire de spécifier un service en ligne centralisé qui peut également effectuer ce type de vérification. 

C’est un moyen utilisé pour partager plus simplement un Verifiable Credential avec quelqu’un qui n’est pas lui-même dans l’écosystème. Concrètement, cette personne pourra vérifier un Verifiable Credential lié à ce DID en se rendant à l’adresse indiquée, ici “https://example.com/vcheck” et en effectuant un simple copier-coller ou en passant les informations du Verifiable Credentials en paramètres.

“created”: “2021-01-01T14:22:21Z”,
    “proof”: {
      “type”: “LinkedDataSignature2020”,
      “created”: “2021-01-01T14:21:14Z”,
      “creator”: “did:syl:admin42randn1awa3xzhjkbvc33”,
      “signatureValue”: “NRB43Y42Q21…1tndsf45sw==”
    }

En fin de “DID Document”, on trouve généralement une signature numérique permettant d’authentifier celui qui l’a créé. La première date fait référence à la date effective de création du document dans le smart contract puis donne des détails sur la signature qui sert de preuve, contenant souvent une date légèrement antérieure. 

Là encore, c’est le cas le plus simple qui est affiché, le créateur est le propriétaire de l’identité mais ce n’est pas forcément le cas le plus fréquent. En effet, la création d’un DID Document sur une blockchain nécessite souvent le paiement de frais de création de données et l’utilisateur n’est pas forcément celui qui effectue cette transaction. 

Par exemple, si un DID Document doit être créé sur un smart contract sur Ethereum, un utilisateur qui télécharge un wallet pour créer et gérer son identité décentralisée n’est pas forcément immédiatement en possession d’ETH pour payer les frais de “gaz” nécessaires à la création de ce DID Document. Le propriétaire de l’identité peut donc se trouver dans une situation où il sait fournir tous les détails pour créer le contenu de son DID Document mais passe par un intermédiaire pour le mettre “en ligne” sur le smart contract de la blockchain. Cet intermédiaire ne fera donc que payer la transaction associée à la création du DID Document, pour le compte du véritable utilisateur/propriétaire. 

Le créateur du DID Document peut donc être différent du propriétaire mais même dans ce cas :
– le DID du créateur permet de retrouver et de vérifier l’identité de cet intermédiaire pour assurer qu’il est bien un intermédiaire de confiance (ce DID peut ainsi pointer sur le DID Document d’un administrateur référencé),
– cela ne signifie pas forcément que ce créateur peut modifier les informations du DID Document dans le dos du propriétaire de l’identité. Celui-ci peut indiquer qu’il reste seul autorisé à effectuer de futures modifications sur son DID Document ou à partager son contrôle avec un tiers, etc.

Exemple d’utilisation : un service web souhaite authentifier un possesseur de DID

Le service web abcd.com souhaite authentifier les possesseurs de SDI (DID) via une page web dédiée. Nous aborderons dans un autre billet la possibilité de s’authentifier depuis une application tierce mais nous nous contenterons ici d’étudier le cas assez commun d’une authentification sur un site web initialement affiché dans le navigateur d’un ordinateur de bureau. 

La page de login du serveur affiche un QR Code qui contient l’adresse du service web et une  chaine de caractère aléatoire unique (aussi appelée un “challenge”).

Authentifier le propriétaire d’un DID sur un serveur webIllustration 2-2 : Authentifier le propriétaire d’un DID sur un serveur web

L’utilisateur du wallet de DID scanne le QR Code présent sur la page. Le wallet demande à l’utilisateur s’il accepte d’utiliser une clé liée à son DID pour s’authentifier sur ce serveur puis, après confirmation, utilise la clé privée d’authentification pour signer le challenge contenu dans le QR Code. Le wallet renvoie ensuite au serveur le challenge signé et son (identifiant) DID.

Le service web reçoit le DID (faisant office de “nom d’utilisateur”) et suit automatiquement les étapes décrites plus haut pour obtenir le “DID Document” associé. Le service lit la section relative à l’authentification et trouve la clé publique liée au DID utilisable pour l’authentification par défaut. Le serveur doit maintenant s’assurer que le propriétaire du DID possède bien la clé privée correspondant à cette clé publique. Il lui suffit pour cela de vérifier la validité de la signature qu’il vient de recevoir. Si la signature est valide, le serveur confirme l’authentification et fournit l’accès souhaité.

Note : il est possible, dans un “DID Document”, d’affecter plusieurs clés d’authentification à des services web et contextes différents, mais également d’affecter d’autres clés à d’autres usages comme par exemple le chiffrement de messages, la signature de contrats, etc.

L’utilisation d’un DID pour effectuer une authentification est un cas d’utilisation simple qu’il est important d’avoir compris avant de passer à la description des Verifiable Credentials qui seront au cœur de notre prochain article.

Copyright © 2020 XSL Labs – All rights reserved