Que sont les justificatifs vérifiables ?

Il existe un document que presque tout le monde porte avec soi et qui résout un problème que nous avons collectivement échoué à résoudre numériquement depuis plus de trois décennies. Votre passeport. Présentez-le à un agent de la douane à Zurich, Tokyo ou São Paulo. L’agent l’inspecte, vérifie la photographie, contrôle les éléments de sécurité de l’autorité émettrice et vous le remet. Pas d’appel à votre gouvernement. Pas de requête en temps réel dans une base de données. Le document lui-même porte la preuve.

Essayez maintenant de faire la même chose en ligne.

Vous vous connectez à un site web. Ce site web confirme que vous connaissez un mot de passe, ou que vous contrôlez une adresse e-mail particulière. Mais il ne peut pas confirmer que vous êtes médecin agréé. Ou conseiller financier certifié. Ou représentant autorisé d’une institution spécifique. Pour cela, il doit appeler un service externe, consulter un registre central, ou vous demander de télécharger un document qu’une personne examinera trois jours plus tard.

Les justificatifs vérifiables sont le passeport numérique. Une affirmation structurée, signée cryptographiquement, concernant votre identité ou vos autorisations : émise par une autorité en laquelle vous et le vérificateur avez confiance, et vérifiable sans appeler quiconque.

Le concept n’est pas nouveau. Ce qui est nouveau, c’est que nous disposons enfin de l’infrastructure cryptographique pour le faire fonctionner à grande échelle institutionnelle sans recréer les dépendances que le concept était censé éliminer.

Trois rôles, un triangle

Le modèle repose sur trois acteurs : la relation entre eux est ce qui fait fonctionner l’ensemble.

L’émetteur crée le justificatif. Un ordre des médecins certifie un médecin. Une université confère un diplôme. Un employeur confirme un rôle institutionnel. L’émetteur signe le justificatif avec une clé cryptographique. Cette signature est l’équivalent numérique du timbre gaufré sur votre passeport : elle peut être vérifiée par quiconque connaît la clé publique de l’émetteur, et elle ne peut pas être falsifiée.

Le détenteur est la personne ou l’organisation que le justificatif décrit. Les détenteurs stockent les justificatifs dans un portefeuille, une application ou une infrastructure institutionnelle. La différence critique par rapport aux systèmes traditionnels : le détenteur décide quand et avec qui partager. Dans un modèle de base de données, l’émetteur contrôle l’accès. Dans un modèle de justificatif, c’est le sujet qui le fait. Il s’agit d’un choix architectural ayant des implications directes sur la minimisation des données, la réglementation sur la protection des données et l’indépendance opérationnelle.

Le vérificateur est celui qui a besoin de vérifier. Un système d’admission hospitalière. Une pharmacie. Une plateforme de conformité financière. Une application de contrôle des frontières. Le vérificateur ne contacte pas l’émetteur. Il vérifie la signature cryptographique par rapport à la clé publique de l’émetteur : un processus qui prend quelques millisecondes, fonctionne hors ligne et ne révèle rien à l’émetteur sur le moment ou le lieu de présentation du justificatif.

Ce triangle est une relation de confiance, et la distinction avec une authentification est structurelle, non sémantique.

Pourquoi cela importe bien plus que de meilleurs mots de passe

Les systèmes d’authentification standard : OAuth, SAML et les protocoles qui s’y superposent : sont des mécanismes de session. Ils confirment que vous avez le droit d’accéder à un système particulier à un moment particulier. Ils ne sont pas conçus pour porter des affirmations durables concernant votre identité au-delà des frontières institutionnelles.

OAuth fonctionne bien au sein d’un seul domaine. Un utilisateur s’authentifie auprès d’un fournisseur d’identité, obtient un jeton, accède aux services. Mais dès que vous franchissez les frontières d’une institution à l’autre, OAuth rencontre une limitation structurelle : il suppose que la partie émettant le jeton est la partie qui l’utilise. Les jetons de l’Institution A n’ont aucun sens pour l’Institution B à moins qu’elles n’aient d’abord négocié un accord de fédération. Quand vous avez besoin de dix institutions pour interopérer, vous avez besoin de jusqu’à 45 accords de confiance bilatéraux. Avec cent institutions, cela devient 4 950.

Alors que se passe-t-il réellement ? Tout le monde converge vers un fournisseur d’identité central : Google, Microsoft, Okta : et la « fédération » devient une dépendance en étoile. La décentralisation était théorique. La centralisation est réelle.

Les systèmes basés sur les certificats font face à une version différente du même problème. L’infrastructure à clé publique traditionnelle peut confirmer qu’un serveur est authentique. Elle peut même confirmer qu’un individu détient un certificat spécifique. Mais la faiblesse structurelle n’est pas l’échelle : les magasins de certificats racine fournis par le système d’exploitation gèrent cela raisonnablement bien. La faiblesse structurelle est la délégation de confiance. Chaque autorité de certification est un tiers qui peut être compromis, contraint par un gouvernement ou simplement défaillir. DigiNotar l’a prouvé en 2011. Et aujourd’hui, Let’s Encrypt seul détient environ 60 % de la part de marché pour les certificats TLS : une seule institution américaine qui est un point de défaillance structurel unique pour la sécurité du transport Internet.

Les justificatifs vérifiables résolvent ce problème différemment. Au lieu d’acheminer la confiance par une autorité centrale, chaque entité maintient sa propre identité cryptographique. La vérification est directe : le vérificateur lit le matériel de clé publique de l’émetteur et vérifie la signature. Pas d’intermédiaire, pas de négociation bilatérale, pas de point de défaillance unique dont la compromission invaliderait tout ce qu’il a jamais signé.

Divulgation sélective : montrer uniquement ce qui est nécessaire

Un justificatif est émis une fois et présenté plusieurs fois. Mais présenter un justificatif ne signifie pas partager tout ce qu’il contient.

Une pharmacie doit savoir qu’un prescripteur détient une inscription valide à titre de praticien. Elle n’a pas besoin de connaître l’employeur du prescripteur, la date de sa graduation ou son dossier de formation continue. La divulgation sélective signifie que le détenteur partage uniquement les attributs que le vérificateur demande : et le vérificateur confirme uniquement ce qu’il a demandé.

Il s’agit d’une propriété architecturale du format de justificatif lui-même, et non d’une fonction de protection des données ajoutée après coup. Les implications pour la conformité sont importantes : dans toute juridiction avec des exigences de minimisation des données : RGPD, Loi fédérale sur la protection des données, HIPAA : le modèle de justificatif est structurellement aligné avec la loi plutôt que d’y s’opposer.

De la spécification à la production

Les justificatifs vérifiables sont en production aujourd’hui.

En Suisse dans le secteur de la santé, SEAL : le point de départ de la couche de communication de Vereign : gère plus de 800 000 livraisons vérifiées par mois entre plus de 30 000 cabinets médicaux dans le réseau HIN, où la passerelle Verimesh et l’autorité de certification centrale gèrent maintenant la gestion décentralisée des clés en production. Chaque message traité par cette infrastructure porte des affirmations vérifiables concernant l’identité de l’expéditeur et son autorisation professionnelle. La partie réceptrice : un système de dossiers médicaux, une clinique de spécialité, une pharmacie : vérifie ces affirmations indépendamment. Pas de registre central interrogé. Pas d’intermédiaire de confiance consulté.

L’architecture de confiance qui soutient cela utilise la gestion décentralisée des clés (DKMS) : un principe de conception où chaque entité maintient son propre identifiant cryptographique ancré à un journal d’événements de clé immuable. Pensez à placer l’Autorité de certification en périphérie : chaque organisation devient son propre point d’ancrage de confiance, et tout tiers peut vérifier cette confiance en lisant directement l’enregistrement cryptographique. Pas d’Autorité de certification partagée requise. Pas de négociation bilatérale. Pas de point de défaillance unique.

La gestion des clés est conçue pour la résilience opérationnelle : si une clé est compromise, l’entité bascule vers des clés de remplacement préengagées sans modifier son identifiant. La relation de confiance survit à la compromission d’une clé : quelque chose que les systèmes de certificats traditionnels ne peuvent pas faire sans rééditer chaque justificatif à partir de zéro.

Ce qui rend un justificatif « vérifiable »

Le mot fait un travail technique spécifique. Un justificatif est vérifiable quand trois conditions sont remplies :

1. Vérification de la signature. La signature cryptographique de l’émetteur peut être confirmée par rapport à une clé publique que le vérificateur fait confiance ou peut découvrir par un processus de résolution de confiance
2. Évidence de falsification. Toute modification du justificatif après son émission casse la signature : le vérificateur la détecte immédiatement
3. Vérification de la révocation. L’émetteur peut publier des informations de révocation sans révéler quels justificatifs spécifiques ont été révoqués, protégeant la vie privée du détenteur même dans le processus de révocation

Ces trois propriétés sont ce qui distingue un justificatif vérifiable d’une affirmation auto-proclamée. N’importe qui peut mettre un titre de poste dans une signature de courrier électronique. Seul un émetteur de confiance peut produire un justificatif signé et irrécusable qu’un tiers peut confirmer indépendamment : et que le détenteur contrôle.

La véritable question

Le modèle hérité de l’identité numérique : un fournisseur détient vos données, vous vous authentifiez auprès de ce fournisseur : convenait adéquatement à Internet au début. Il ne convient pas aux environnements où plusieurs institutions doivent se faire confiance mutuellement concernant les affirmations portant sur les personnes, les rôles et les autorisations sans céder le contrôle à un intermédiaire partagé.

Les justificatifs vérifiables représentent une architecture différente. Les affirmations d’identité sont détenues par le sujet. Émises par les autorités appropriées. Vérifiables par toute partie qui fait confiance à ces autorités. Sans intermédiaires. Sans goulots d’étranglement centraux. Sans les implications en matière de protection des données des magasins de données centralisés.

La technologie est déployée. Les normes arrivent à maturité. Les chiffres de production augmentent. La question pour toute organisation réglementée n’est plus de savoir si les justificatifs vérifiables fonctionnent : mais ce qui arrive à ceux qui attendent pendant que leurs pairs construisent une infrastructure de confiance qui fournit réellement une preuve cryptographique au lieu de demander à tout le monde de simplement les croire sur parole.