Un monde de portefeuille électronique
Pour creuser la partie jetons, vous pourriez être intéressé-e par Verifiable Credentials et les Verifiable Claims, la spec du W3C sur le sujet. Le document le plus important selon moi, c’est Verifiable Credentials Use Cases : ce n’est pas un document normatif, mais il explique ce que les gens qui conçoivent le truc ont derrière la tête.
Voilà une explication de haut niveau pourquoi ils pensent que c’est nécessaire :
Entities (people, organizations, devices) need to make many kinds of claims as part of their everyday activities. As more and more of these important activities move to the Internet, entities need to be able to transmit instantly verifiable claims (e.g., about their location, accomplishments, value, what-have-you). From educational records to payment account access, the next generation of web applications will authorize entities to perform actions based on rich sets of credentials issued by trusted parties. Human- and machine-mediated decisions about job applications, account access, collaboration, and professional development will depend on filtering and analyzing growing amounts of data. It is essential that data be verifiable. Standardization of digital claim technologies makes it possible for many stakeholders to issue, earn, and trust these essential records about their counterparties, without being locked into proprietary platforms.
Et si ça vous parait abscons ou que vous n’aimez pas l’anglais, en image ça donne ça selon Thalès : https://www.youtube.com/watch?v=YSb0nLRte_A
Tout ça connecte bien aussi avec le projet Trust over IP : https://trustoverip.org/
Verifiable Credentials, la norme sous-jacente
Et une fois que vous êtes bien motivé-es, vous pouvez vous attaquer au corps du truc pour comprendre comment ça marche, dans la spec Verifiable Credentials Data Model v1.1.
En fait faut comprendre que chaque personne aura un « portefeuille électronique » sur son téléphone, soit une application qui stocke des petits bouts de données qu’on appelle « Credentials ».
Dans mon exemple, notre claim, notre « affirmation », c’est donc de prouver qu’on est bien un ancien élève diplomé de l’université Example University, en gros un JSON avec un format spécifique. Cette information est signée par la clef privée de notre université, ce qui en constitue la preuve.
Mais ce n’est pas le credential qu’on envoie aux sites webs, c’est ce qu’on appelle une Presentation. La présentation contient le verifiable credentials, ou une représentation cryptographique, est une preuve qu’on a bien généré la présentation nous-même, suite à la demande du site web. Pour ça, le site web aura généré un challenge (aka nonce) avec lequel on devra signé le credential approprié (ici le fait qu’on soit diplomé de l’université) avec notre clé privée qui nous identifie, et lui renvoyer le tout.
Si on met le tout ensemble, ça donne ça :
La promesse du zero-knowledge
Si on revient à notre cas de montrer qu’on a plus de 18 ans, ou plus de 15 ans, et qu’on essaie de l’appliquer à notre Verifiable Credentials, ça veut dire qu’il faut se baser sur un Credential type Carte d’Identité, signé par un certificat de votre préfecture local. Ce dernier est stocké dans votre téléphone, le site web vous envoie un challenge, et vous allez devoir générer une présentation avec les infos de votre carte d’identité.
Hélas, vous ne voulez pas tout donner, même pas votre date de naissance en entier, juste un booléen que vous avez plus de 18 ans. À partir du credential que vous avez, et grâce à de la crypto zero knowledge, vous pouvez générer un blob qui prouve qu’une autorité de confiance a certifié votre date de naissance qui fait qu’aujourd’hui vous avez plus de 18 ans. Me demandez pas comment ça marche mais c’est expliqué ici : Zero-Knowledge - Verifiable Credentials
Mais alors me direz-vous, comment s’assurer que mon enfant n’utilise pas le certificat de ses parents ? ou de quelqu’un d’autre ? Plus largement, comment vérifier que la personne physique corresponde bien à l’utilisateur du certificat ? Aaaah ça, c’est pas précisé, mon avis c’est que les wallet seront implémentés dans la secure enclave des téléphones Android, par du code géré par les GAFAM, et que pour déverrouiller notre wallet, il faudra des checks biométriques (comme la femme qui se prend en photo dans la vidéo de Thales). Et à mon avis, vous n’aurez probablement pas le choix d’utiliser ce système et seulement ce système, car sinon votre autorité de certification refusera de signer votre Credential.
Une autre critique, c’est que vous devez montrer ce qu’on vous demande de montrer. Ainsi si un site web vous demande votre identité en plus d’une preuve d’age, vous n’aurez pas le choix que de lui donner ces deux informations. Donc zero-knowledge que si il y a coopération avec le site web que vous visitez, si il vous demande plus, vous devrez donner plus. Et si on imagine un déploiement différencié : pour les opérations critiques, forcément une enclave verrouillée comme au dessus. Pour les opérations moins critique, un fonctionnement qui peut marcher en logiciel pur, et donc où il est facile de faire circuler les credentials entre devices. Pour limiter cette circulation, les sites pourraient être tenté de vous demander plus que simplement une preuve d’age, mais aussi un numéro de sécu ou un couple nom+prénom pour ban les credentials qui reviennent trop souvent.
Si les algos ZKP vous intéresse, la norme W3C mentionne A signature with efficient protocols aka Camenisch-Lysyanskaya Zero-Knowledge Proofs et cite une ressource de leur crue où un second algo BBS+ est identifié.
A signature with efficient protocols | Wikipedia | Linked Data Cryptographic Suite Registry | BBS Signatures
Perte du téléphone et synchro multi device : les identity hub à la rescousse
Alors vous allez me dire qu’on peut perdre notre téléphone, qu’on peut en avoir plusieurs, qu’on en aura besoin sur notre ordinateur, et encore bien d’autres questions. Mais ne vous inquiétez pas, on a pensé à vous, enfin surtout Microsoft, avec ses identity hub. Et si plutôt que de stocker vos credentials (uniquement) sur vos téléphones, vous ne les stockiez pas chez Microsoft, sur un Identity Hub ?
Et en plus vous pourrez choisir votre identity hub ! Enfin, sauf dans la théorie de la secure enclave gérée par les GAFAM. Pour protéger votre identité, cette dernière ne va probablement pas communiquer vos credentials à n’importe qui, seulement des tiers de confiance sélectionnés par nos GAFAM sur une base de critères tout à fait objective, avec des audits et normes à la portée de tous les CHATONS, sans aucun doute.
ID Hub: the easy guide | DIF Identity Hub | EBSI Verifiable Credentials
Pas réaliste : verifiable credentials est déjà là !
Vous vous dites que c’est probablement fantasmé tout ce que je raconte. En effet, tout ne vas pas se déployer en un jour, les briques vont s’installer graduellement. Maintenant qu’on a toutes et tous déployés un SSO qui supporte OIDC, on est plus qu’à un pas de pouvoir utiliser Verifiable Credentials, en effet on a déjà des specs pour intégrer les deux.
OpenID for Verifiable Credentials | EBSI Verifiable Credentials | Chapter 6 | Verifiable Credential based Authentication via OpenID Connect
Quelle base pour les certificats : entre old-school et blockchain, mon cœur balance…
Reste probablement la question de quels seront les certificats autorisés à signer tel ou tel document, comment maintenir cette base, etc. ? Et bien une première façon, old-school, c’est via une racine de certificats, comme sur le web. Dans le cas du web, c’est le fournisseur du logiciel qui le maintient : pour Windows c’est Microsoft, pour Firefox c’est Mozilla, etc. Là ce serait l’État qui maintiendrait cette liste, et les entreprises qui ont obligation de vérifier l’age/l’identité devraient vérifier à travers cette liste.
Mais parce qu’on arrête pas le progrès, plein de solutions ont été imaginées avec des blockchains, où les certificats, et leurs révocations, seraient publier dessus. Les entreprises seraient alors connectées à cette blockchain/smart contract/whatever et maintiendraient en permanence la liste des certificats valides à travers ce truc.
Quel rapport avec les réseaux sociaux/le porn/le schmilblick
Le tout c’est d’arriver à mettre en circulation cette techno qui est dans les cartons depuis 2019 via un cas d’usage qui fasse le plus consensus possible auprès des gens. Il s’agit donc de créer de l’émotion sur les enfants, sur les moeurs, sur tout ce que la société considère de plus monstrueux possible, pour ensuite mettre en place la solution technique dans ce cas particulier et ensuite graduellement l’étendre à tous les secteurs, car c’est pratique et déjà là.
Le passe sanitaire a été une première incursion dans ce milieu du porte feuille électronique (rappelez-vous les gens qui disséquaient les QR-Codes, pour montrer que la donnée était en claire mais signée par un certificat lui géré par le gouvernement ?). Maintenant il s’agit de trouver quel sujet permettra de faire un pas de plus vers ce futur.
Que vont faire les CHATONS ?
Ce qu’ils et elles ont envie, ce qu’ils et elles décideront de faire. Mais rassurez-vous, il y aura un logiciel libre pour ça. DIDKit avance à grand pas et fournit une bibliothèque qui implémente déjà une grande partie de la spec en libre et en Rust : https://www.spruceid.dev/didkit/didkit. En cherchant, vous devriez même pouvoir retrouver une démo de portfeuille électronique pour smartphone.
Je ne serais pas surpris que dans les mois ou années à venir, les providers OIDC ne commencent pas à avoir des connecteurs avec DID/Verifiable Credentials, par exemple Keycloack. En fait le travail est déjà en cours. Et du coup du côté des specs on a Self-Issued OpenID Provider v2 (SIOPv2), OpenID for Verificable Credentials Issuance (OID4VCI), OpenID for Verifiable Presentations (OID4VP) ou encore OpenID for Identity Assurance (OID4IA), le dernier je ne sais pas à quoi il sert…
Verifiable Credential based Authentication via OpenID Connect |
Create a Red Hat Keycloak Identity Provider (IdP) capable of processing Verifiable Credentials… | Verifiable Credential Based Authentication over OpenID Connect | MATTR - A new world of digital trust | SIOPv2 | OID4VCI | OID4VP | OID4IA | Support for OIDC extensions: OIDC4IA / OIDC4VP #15725
En plus la norme est chapeautée par le W3C, et ils ont de jolis diagrammes en SVG.
Ah et sinon, peut-être que certains penseront que le libre n’est pas un horizon indépassable, et qu’une technologie est porteuse d’intentions, et que celle là, même en étant ouverte, transparente, etc. n’a pour vocation à ce qu’un petit nombre contrôle le plus grand nombre. De ce fait, ils et elles s’opposeront en n’implémentant pas ces solutions, ou de la manière la plus inefficace possible, en cherchant des alternatives, en titillant le système, etc.
C’est bien ou c’est mal ?
J’ai été surpris de voir que le CCC soutenait à fond, et qu’il y a pas mal de relais dans le monde du libre. Pour ma part, je laisse ce message pour dans 10 ans afin de faire le malin avec un « je vous l’avais bien dit ».
https://media.ccc.de/v/mch2022-166-irma-and-verifiable-credentials