Pourquoi la Blockchain est Optionnelle pour le Futur Permis de Conduire International (PCI)

Un futur Permis de Conduire International (PCI) a besoin de transparence, d’ancres de confiance et de responsabilité publique. Ce dont il n’a pas besoin — par défaut — c’est d’inscrire les conducteurs eux-mêmes sur un registre distribué.

Toute discussion sérieuse sur un PCI numérique et transfrontalier finit par attirer la même proposition : « Il suffit de le mettre sur la blockchain. » L’attrait est compréhensible. Les blockchains offrent une preuve d’inviolabilité, une visibilité partagée et un historique en ajout seul. Ce sont de vraies propriétés. Mais dans le contexte de l’identité transfrontalière des conducteurs, elles sont très souvent appliquées à la mauvaise couche.

Cet article explique pourquoi, passe en revue ce que disent réellement les normes et propose un meilleur modèle architectural.

Ce que Disent Réellement les Normes sur la Blockchain

Le modèle de données des Verifiable Credentials du W3C précise explicitement qu’un registre de données vérifiables peut prendre de nombreuses formes, notamment :

• Des bases de données de confiance
• Des bases de données décentralisées
• Des bases de données d’identité gouvernementales
• Des registres distribués

Le DID Core est tout aussi clair : de nombreuses méthodes DID utilisent la technologie des registres distribués, mais pas toutes. Autrement dit, les normes rejettent déjà l’idée que la blockchain soit un fondement obligatoire pour les identifiants numériques.

C’est le bon point de départ pour un futur PCI. La question utile n’est pas « blockchain ou pas blockchain ? » C’est :

Quelle couche a réellement besoin de transparence, et quelle couche ne devrait absolument pas devenir une infrastructure publique par défaut ?

La Blockchain est un Ensemble de Propriétés, Pas une Exigence

La première erreur consiste à traiter la « blockchain » comme une exigence unique. Ce n’en est pas une. C’est un ensemble de propriétés possibles, notamment :

• Publication partagée
• Historique en ajout seul
• Fonctionnement distribué
• Génération de reçus
• Résistance aux modifications unilatérales

Certaines de ces propriétés sont utiles pour un futur PCI. D’autres sont sans pertinence. Et certaines sont activement dangereuses lorsqu’elles sont appliquées à des sujets d’identifiants humains. Le modèle de registre du W3C autorise délibérément plusieurs implémentations, car différents écosystèmes nécessitent différents compromis.

Trois Problèmes qui ne Doivent pas être Combinés

La deuxième erreur consiste à fusionner trois problèmes distincts en un seul système. Pour un futur PCI, ces éléments doivent rester séparés :

1. Où réside la vérité juridique. Le droit de conduire appartient aux registres nationaux de permis faisant autorité.
2. Comment le matériel de confiance est distribué. Les clés des émetteurs et les certificats des vérificateurs appartiennent à des registres de confiance contrôlés.
3. Comment l’écosystème audite les changements. Cela appartient à une couche de transparence.

Les écosystèmes réels fonctionnent déjà ainsi. Le Digital Trust Service de l’AAMVA distribue les clés publiques des émetteurs dans une liste téléchargeable avant qu’un vérificateur n’interagisse avec un mDL. Le manuel européen sur le permis de conduire mobile précise que les États membres notifient à la Commission les émetteurs de mDL autorisés, et la Commission publie une liste de vérification de ces autorités. C’est de la distribution de confiance sans blockchain.

Ce que la Transparence des Certificats nous Enseigne

Le modèle de transparence le plus efficace sur l’internet public n’est pas une blockchain grand public. C’est la Transparence des Certificats (CT).

La RFC 9162 décrit la CT comme un protocole permettant de journaliser publiquement les certificats de serveur TLS afin que chacun puisse :

• Auditer l’activité des autorités de certification
• Détecter les certificats problématiques ou mal émis
• Auditer les journaux eux-mêmes

La leçon de conception clé de la CT : la transparence est la plus précieuse lorsqu’elle enregistre le comportement des émetteurs et le matériel de confiance — et non l’activité des utilisateurs finaux.

Appliqué à un futur PCI, cela signifie journaliser des éléments tels que :

• L’émission et la rotation des clés des émetteurs
• La publication des ancres de confiance
• L’enregistrement des catégories de vérificateurs
• Les changements de politique
• Les déclarations de conformité
• Les événements liés à la sécurité

Ce que cela ne signifie pas, c’est créer un registre public ou semi-public des titulaires, des identifiants d’identifiants ou des événements de présentation. Ce n’est pas de la transparence. C’est une collecte excessive de données.

SCITT : Pourquoi la Transparence n’est pas Synonyme de Vérité

L’architecture SCITT de l’IETF prolonge cette réflexion. SCITT définit un Service de Transparence qui maintient une structure de données vérifiable et émet des reçus cryptographiques prouvant l’inclusion d’instructions signées. L’identité du Service de Transparence est capturée par une clé publique connue des parties utilisatrices, et les ancres de confiance ainsi que les politiques d’enregistrement sont elles-mêmes rendues transparentes.

C’est un modèle puissant pour l’infrastructure d’un PCI, car il transforme la transparence en un service auditable autour du matériel de confiance et des politiques — et non autour des événements de voyage personnels.

SCITT est également clair sur les limites de la transparence :

• Une déclaration enregistrée prouve uniquement qu’un émetteur l’a produite et enregistrée — pas que la déclaration est correcte indéfiniment.
• Une déclaration signée ultérieure peut remplacer une déclaration antérieure.
• La transparence n’empêche pas les émetteurs malhonnêtes ou compromis ; elle les rend responsables.

Pour l’identité des conducteurs, cette distinction est d’une importance capitale : un journal de transparence est une preuve et un historique d’audit, pas l’état juridique faisant autorité du droit de conduire d’une personne.

SCITT note également qu’un service de transparence peut protéger sa séquence en ajout seul en combinant du matériel de confiance, des protocoles de consensus et des preuves cryptographiques. Même la couche de transparence ne nécessite pas une conception spécifique de blockchain. Le consensus est une option, pas la seule.

La Séparation Architecturale Correcte pour un Futur PCI

Un futur PCI devrait séparer les préoccupations en quatre couches distinctes :

1. Les registres faisant autorité sur qui peut conduire (autorités nationales de délivrance des permis)
2. Les registres de confiance pour les clés des émetteurs et des vérificateurs
3. L’infrastructure de statut pour la fraîcheur et la révocation
4. Une couche de transparence optionnelle pour l’audit public des politiques, des ancres de confiance, des reçus et des déclarations de conformité

Une fois ces couches séparées, la question de la blockchain devient bien plus précise. Ce n’est plus « le futur PCI devrait-il être sur une blockchain ? » Cela devient :

Quelle couche, le cas échéant, bénéficie réellement d’un audit public en ajout seul ?

Cinq Raisons pour Lesquelles l’Identité du Conducteur sur la Chaîne est le Mauvais Choix par Défaut

1. Elle Crée des Signaux de Suivi Durables

Les travaux sur la confidentialité de l’EUDI expliquent que les présentations d’attestations peuvent contenir des valeurs uniques telles que :

• Des sels
• Des valeurs de hachage
• Des identifiants de révocation
• Des clés publiques liées à l’appareil
• Des signatures
• Des horodatages

Comme ces valeurs sont fixes pour la même attestation, elles permettent aux parties utilisatrices de relier différentes transactions et de constituer un profil comportemental de l’utilisateur. L’EUDI avertit explicitement que cela viole l’attente raisonnable que des activités de portefeuille distinctes ne seront pas combinées.

Si vous publiez des identifiants de titulaires stables, des identifiants d’identifiants stables, des hachages réutilisables ou des événements de révocation individuellement traçables sur un registre public, vous ne résolvez pas le problème de suivi — vous le rendez permanent.

2. Elle Expose les Événements de Révocation et de Fraîcheur

La Recommandation Bitstring Status List du W3C décrit clairement le problème : s’il existe une correspondance univoque entre un identifiant et l’URL où son statut est publié, l’éditeur peut relier le titulaire, le vérificateur et l’heure de la vérification. La spécification utilise un exemple de permis de conduire pour illustrer pourquoi être suivi par l’émetteur lors de l’entrée dans un établissement viole une attente de confidentialité courante.

Le meilleur choix par défaut que propose Bitstring Status List :

• Des listes de statuts larges et compressibles où de nombreux identifiants partagent une ressource de statut unique
• Une longueur de liste par défaut de 131 072 entrées
• Les parties utilisatrices téléchargeant de nouvelles versions séparément, sans s’authentifier
• Des indices aléatoires et des garanties de confidentialité de groupe

C’est le contraire des traces de révocation individualisées sur la chaîne.

3. Elle Confond le Statut de l’Identifiant avec le Statut Juridique de Conduite

Un identifiant numérique peut être révoqué parce que son mécanisme de signature a été compromis — même si le droit de conduire dans le monde réel reste valide. Un registre public des événements liés aux identifiants ne se substitue pas proprement à l’état faisant autorité d’un dossier de conduite national.

SCITT renforce ce point : une déclaration enregistrée peut être remplacée ultérieurement par une nouvelle, et les parties utilisatrices décident de ce à quoi faire confiance en fonction de la politique et de l’historique. Le journal n’est pas une vérité permanente. C’est une preuve de qui a dit quoi, quand, sous quelle politique. L’autorité nationale de délivrance des permis reste la source de la vérité juridique.

4. Elle Cible le Mauvais Problème de Gouvernance

L’identité transfrontalière des conducteurs n’est pas principalement un problème de consensus. C’est un problème de gouvernance :

• Qui est autorisé à émettre ?
• Quelles clés publiques sont actuelles ?
• Quels vérificateurs sont autorisés ?
• Quelles demandes de données correspondent à leur finalité déclarée ?
• Quelle version de politique était en vigueur au moment des faits ?

Les écosystèmes réels répondent déjà à ces questions par une infrastructure de confiance gouvernée, et non par un consensus décentralisé :

• Le Digital Trust Service de l’AAMVA publie les clés publiques des autorités émettrices dans une liste téléchargeable.
• Le manuel européen sur le permis de conduire mobile indique que la Commission publie la liste des émetteurs de mDL autorisés.
• Les travaux de l’ETSI sur les certificats des parties utilisatrices de portefeuille fournissent une authentification lisible par machine des vérificateurs, avec l’usage prévu et les attributs demandés enregistrés.

C’est une administration de confiance publique explicite — et non une gouvernance décentralisée.

5. Elle ne Résout pas la Réalité du Bord de Route

De nombreuses propositions de blockchain supposent discrètement qu’un accès réseau en direct est un avantage. Pour les identifiants de conducteurs — particulièrement au bord de la route ou lors de déplacements — ce n’est souvent pas le cas.

Les recommandations de mise en œuvre de l’AAMVA précisent que :

• La récupération sur l’appareil fonctionne sans connectivité externe, tant pour le titulaire que pour le lecteur au moment de la transaction.
• La norme ISO/IEC 18013-5 exige la prise en charge de la récupération sur l’appareil.
• L’accès du vérificateur aux clés publiques de l’émetteur n’a pas besoin de se faire au moment de la transaction. Les clés peuvent être téléchargées à l’avance.

Si un vérificateur peut déjà valider localement à l’aide d’un matériel de confiance mis en cache, une dépendance en direct à la blockchain n’est pas essentielle. Au mieux, c’est un choix d’implémentation pour une fonction d’audit en arrière-plan.

Ce qui Doit être Transparent dans un Futur PCI

Un futur PCI a absolument besoin de transparence — au bon endroit.

Rendre ces éléments transparents par défaut :

• Les clés publiques des émetteurs et les événements de rotation des clés
• Les ancres de confiance et les listes d’émetteurs autorisés
• Les certificats d’accès des vérificateurs et les métadonnées de finalité enregistrée
• Les versions de politique et les règles d’enregistrement
• Les déclarations de conformité et les revendications de publication de logiciels liées à la sécurité
• Les reçus auditables prouvant que ces déclarations ont été enregistrées

Ne pas rendre ces éléments publics par défaut :

• Les identifiants de titulaires sur un registre public
• Les identifiants d’identifiants stables réutilisés auprès de plusieurs vérificateurs
• Les événements par présentation
• Les entrées de révocation brutes qui isolent une seule personne
• Les déclarations signées complètes contenant des données personnelles lorsque des hachages ou des métadonnées suffiraient

SCITT avertit explicitement les émetteurs de vérifier l’inclusion d’informations privées, confidentielles ou personnellement identifiables avant de soumettre des déclarations à un service de transparence. Il note également que les services de transparence peuvent ne conserver que des métadonnées cryptographiques telles que des hachages — et non des déclarations signées complètes.

Un Meilleur Modèle : La Transparence Autour de l’Écosystème, Pas à Travers la Personne

Une architecture propre pour un futur PCI ressemble à ceci :

• Registre national faisant autorité — reste la source juridique de vérité pour le droit de conduire.
• Couche d’identifiants — achemine les droits de conduite vérifiables par machine vers le portefeuille du titulaire.
• Couche de registre de confiance — distribue les clés des émetteurs, les certificats des vérificateurs et les listes d’émetteurs autorisés.
• Couche de statut — utilise des attestations de courte durée ou des listes de statuts respectueuses de la vie privée, actualisées séparément.
• Couche de transparence — peut ou non utiliser le consensus en interne, et journalise les ancres de confiance, les changements de clés, les mises à jour de politiques, les reçus et les déclarations de l’écosystème qui bénéficient d’un audit public en ajout seul.

Cette architecture capture les parties utiles de la pensée blockchain — auditabilité en ajout seul, examen public, preuve d’inviolabilité, reçus — sans faire du conducteur le sujet public du système. Elle correspond également à ce que les normes décrivent déjà : les registres peuvent prendre différentes formes, les DID ne nécessitent pas de registres distribués, les registres de confiance existent déjà et les mécanismes de statut respectueux de la vie privée sont déjà normalisés.

L’Argument Central

Le futur PCI devrait adopter la meilleure idée de la blockchain — la responsabilité publique pour l’infrastructure — sans en adopter le pire défaut pour les individus : un suivi durable et globalement visible.

En pratique, cela signifie :

• La transparence pour les émetteurs, pas l’exposition des titulaires
• Des ancres de confiance auditables, pas des archives publiques de déplacements
• Des reçus pour les politiques et les enregistrements, pas des chronologies permanentes d’utilisation des identifiants
• Des preuves en ajout seul pour la gouvernance de l’écosystème, pas l’identité du conducteur sur la chaîne comme choix par défaut

Ce n’est pas un argument contre la blockchain. C’est un argument contre l’application de la blockchain à la mauvaise couche.

Un futur PCI pourra très bien utiliser des services de transparence adossés au consensus quelque part dans l’écosystème. Mais si la conception commence par placer le conducteur, l’identifiant ou la piste de présentation sur un registre, elle a déjà choisi le mauvais choix par défaut.