Pas de vérification par rappel à l'émetteur : pourquoi le futur PDI numérique ne doit pas contacter l'émetteur à chaque utilisation

La révocation est le problème le plus difficile dans tout futur Permis de Conduire International (PDI) numérique. La solution la plus simple est aussi la plus dangereuse : faire de l’émetteur un participant à chaque présentation. Un titre de conduite transfrontalier moderne doit refuser ce raccourci par défaut.

Presque toutes les propositions d’identité numérique contiennent la même phrase rassurante :

« Le titre peut être vérifié instantanément. »

Parfois, cette phrase décrit un véritable progrès. Parfois, elle décrit une surveillance dotée d’une interface utilisateur plus conviviale.

Les normes publiées aujourd’hui indiquent déjà clairement qu’un vérificateur n’a pas besoin de contacter l’émetteur à chaque présentation d’un titre :

• L’architecture mDL actuelle du NIST indique qu’un vérificateur peut valider l’authenticité et l’intégrité en se fiant à la signature et aux clés publiques de l’émetteur, sans aucun contact direct avec celui-ci.
• L’AAMVA confirme que la norme ISO/IEC 18013-5 exige la prise en charge de la récupération sur l’appareil et n’autorise la récupération sur serveur qu’à titre facultatif.
• L’AAMVA avertit également que, dans le cadre de la récupération sur serveur, l’autorité émettrice est impliquée en temps réel à chaque utilisation — ce qui signifie qu’elle peut techniquement enregistrer quand le titre est utilisé, quelles données sont partagées, et même déduire la localisation par analyse des adresses IP.

Il ne s’agit pas d’une note de bas de page anodine. C’est la question de conception centrale pour la prochaine génération de titres de conduite transfrontaliers numériques.

Le raccourci dangereux : regrouper quatre questions en un seul appel réseau

Les architectures défaillantes regroupent quatre questions très différentes dans un seul appel en direct à l’émetteur :

1. Ce titre est-il authentique ?
2. La personne qui le présente est-elle le titulaire légitime ?
3. Le titre lui-même est-il encore valide ?
4. Le droit de conduire national sous-jacent est-il toujours en vigueur ?

Un système mal conçu répond aux quatre questions en rappelant l’émetteur en temps réel. Un système bien conçu les sépare — car elles ne constituent pas le même problème et ne doivent pas partager le même mécanisme.

L’authenticité doit être vérifiée localement, pas sur le réseau

Un titre peut être cryptographiquement authentique sans que l’émetteur n’observe jamais la transaction.

• Le modèle de confiance mDL du NIST indique que l’authenticité et l’intégrité sont validées à partir de la signature et des clés publiques de l’émetteur — aucun contact en direct avec l’émetteur n’est requis.
• Le Service de Confiance Numérique de l’AAMVA existe précisément pour donner aux vérificateurs accès aux clés publiques valides des émetteurs, sans rappel par transaction.

Principe de conception 1 : Ne pas utiliser la connectivité en direct pour résoudre un problème que les signatures résolvent déjà.

Si un vérificateur détient des clés d’émetteur de confiance et reçoit une présentation conforme aux normes, l’authenticité est une vérification cryptographique locale, et non une dépendance réseau.

La liaison au titulaire doit être prouvée localement, pas signalée globalement

La deuxième question — s’agit-il du titulaire légitime ? — dispose également d’une réponse sans recours au réseau.

L’architecture EUDI actuelle rend obligatoire la liaison à l’appareil pour les DIPs et les attestations ISO/IEC 18013-5. Le vérificateur demande au portefeuille de signer un défi fraîchement émis à l’aide de la clé privée correspondant à la clé publique intégrée dans le titre :

• Dans la norme ISO/IEC 18013-5, cela s’appelle l’authentification mdoc.
• Dans le SD-JWT VC, cela s’appelle la liaison de clé.

Dans les deux cas, la possession est prouvée localement et cryptographiquement. Aucune donnée personnelle n’a jamais besoin d’atteindre l’émetteur.

Principe de conception 2 : Prouver la possession localement. Ne pas prouver l’identité globalement.

Un futur PDI devrait épuiser la liaison à l’appareil, l’authentification locale du titulaire et le défi-réponse du vérificateur avant d’envisager tout mécanisme côté émetteur.

Le statut du titre et le statut du droit de conduire sont deux choses distinctes

De nombreuses conceptions d’identité numérique brouillent cette distinction, et c’est là qu’elles se trompent.

La spécification Bitstring Status List du W3C l’indique clairement : les informations de statut attachées à un titre vérifiable s’appliquent au titre vérifiable lui-même — et pas nécessairement au droit réel sous-jacent. Un titre numérique peut être révoqué parce que son mécanisme de signature a été compromis, tandis que le droit de conduire sous-jacent reste parfaitement valide.

Un futur PDI nécessite donc deux couches de statut distinctes :

• Couche de statut du titre — pour le titre numérique ou le canal de présentation lui-même.
• Couche du droit de conduire — pour le droit national sous-jacent de conduire.

Parfois, ces deux couches évoluent ensemble. Souvent, elles ne le font pas. Un système qui les confond réagira de manière excessive, exposera plus de données que nécessaire, ou les deux à la fois.

La compromission du portefeuille doit se propager via le statut — et non déclencher des rappels auprès des vérificateurs

Un futur PDI a également besoin d’une réponse claire à ce qui se passe lorsqu’un portefeuille est compromis.

L’architecture EUDI en fournit une :

• Le fournisseur de portefeuille émet des Attestations d’Unité de Portefeuille contenant des informations de révocation.
• L’intégrité du portefeuille est revérifiée régulièrement ; si un portefeuille n’est plus sécurisé, son attestation est révoquée.
• Les fournisseurs de DIP doivent vérifier régulièrement si le portefeuille a été révoqué. Si c’est le cas, ils révoquent le DIP.
• En vérifiant le statut du DIP, la partie de confiance vérifie implicitement le statut du portefeuille.

C’est la structuration en couches qu’un futur PDI devrait adopter. Ne pas demander à chaque vérificateur de vérifier indépendamment le fournisseur de portefeuille. Laisser la compromission du portefeuille se propager via le pipeline de statut de titre existant, et laisser les vérificateurs consulter ce canal unique respectueux de la vie privée.

Trois modèles de révocation fonctionnels (sans rappels requis)

L’EUDI impose aux fournisseurs d’utiliser l’une des trois méthodes de révocation suivantes :

• Attestations de courte durée — valides 24 heures ou moins, rendant la révocation inutile.
• Liste de statut des attestations — une liste publiée que les vérificateurs peuvent consulter.
• Liste de révocation des attestations — une liste explicite des titres révoqués.

Pour les attestations valides plus de 24 heures, l’EUDI exige d’intégrer des informations de révocation comprenant :

• Une URL où les parties de confiance peuvent récupérer la liste de statut.
• Un identifiant localisant le titre dans cette liste.

Si des informations de révocation fiables sont indisponibles — par exemple, lorsque la partie de confiance est hors ligne — l’EUDI demande à la partie de confiance d’effectuer une analyse des risques avant d’accepter ou de refuser le titre.

La conclusion : la révocation n’est pas un mécanisme unique, et certainement pas une justification pour des rappels obligatoires à l’émetteur.

Courte durée par défaut, longue durée uniquement si nécessaire

L’une des mesures de protection de la vie privée les plus efficaces de toute la pile est aussi la plus simple : maintenir une courte durée de vie de ce qui est présenté.

• L’EUDI indique que les attestations valides 24 heures ou moins ne nécessitent pas d’infrastructure de révocation — elles expirent avant que la révocation ne soit pertinente.
• Le W3C indique que les présentations vérifiables sont généralement de courte durée et non conçues pour un stockage à long terme.
• Le NIST met explicitement en garde contre la transmission répétée d’identifiants réutilisables pour un usage quotidien. L’authentification au quotidien doit reposer sur des technologies conçues à cet effet, comme les clés d’accès, et non sur la présentation répétée d’un titre riche en données d’identité.
• Le NIST a également choisi l’authentification locale sur l’appareil plutôt que la correspondance biométrique côté serveur, précisément parce que l’authentification locale préserve la vie privée et est plus efficace sur le plan opérationnel.

Principe de conception 3 : Le titre de base peut avoir une période de validité moyenne, mais la présentation elle-même doit être de courte durée, spécifique au vérificateur et non réutilisable.

Les listes de statut sont le mécanisme par défaut approprié

Lorsqu’il n’est pas possible de tout rendre éphémère, une infrastructure de statut est nécessaire — et la liste de statut est le bon choix par défaut.

La Bitstring Status List v1.0 du W3C décrit un mécanisme respectueux de la vie privée, économe en espace et très performant pour publier des données de statut telles que la suspension ou la révocation. Ses principales caractéristiques sont les suivantes :

• Chaque émetteur gère une liste pour les titres qu’il a émis.
• Le format se compresse bien, car la plupart des titres restent non révoqués.
• La taille de liste par défaut est de 131 072 entrées, ce qui, selon le W3C, assure une confidentialité de groupe adéquate dans le cas moyen.
• Des listes plus grandes peuvent être utilisées lorsqu’une confidentialité de groupe plus forte est nécessaire.

Cela fait passer la question de :

« Puis-je interroger l’émetteur sur cet utilisateur maintenant ? »

à :

« Ai-je déjà une liste de statut respectueuse de la vie privée suffisamment récente pour décider localement ? »

C’est une bien meilleure question — tant sur le plan technique que politique.

« Pas de rappel à l’émetteur » est un modèle de téléchargement, pas un slogan

La règle la plus importante des recommandations de confidentialité de l’EUDI est procédurale, et non philosophique.

Les parties de confiance ne doivent pas demander la liste de statut à chaque présentation d’un titre. Elles doivent plutôt :

• Télécharger chaque nouvelle version de la liste une seule fois.
• Le faire à un moment et depuis un emplacement sans lien avec aucune présentation d’utilisateur.
• Distribuer la liste en interne au sein de l’organisation de la partie de confiance.
• Récupérer la liste sans authentifier la partie de confiance.

C’est le cœur opérationnel de la vérification sans rappel à l’émetteur : actualiser le statut séparément des présentations d’utilisateurs — jamais par personne, jamais par transaction.

Ce seul choix de conception empêche l’émetteur ou le fournisseur de statut de savoir quel vérificateur a contrôlé quel titre à quel moment.

Confidentialité de groupe : l’exigence que la plupart des conceptions oublient

De nombreux systèmes vantent la divulgation sélective au sein de la présentation elle-même, puis ignorent discrètement la confidentialité des consultations de statut. Il s’agit d’une lacune importante.

Les exigences de confidentialité de l’EUDI précisent que :

• Les indices dans les listes de statut doivent être attribués de manière aléatoire, afin que l’indice lui-même ne devienne jamais un signal de traçage.
• Chaque liste doit couvrir un nombre suffisamment grand de titres pour garantir la confidentialité de groupe.
• Si une liste risque d’être trop petite, les fournisseurs doivent ajouter des entrées inutilisées pour masquer le nombre réel de titres.

Un futur PDI ne peut pas prétendre respecter la vie privée grâce à la seule divulgation sélective. Si le mécanisme de révocation révèle l’événement de présentation, la conception en matière de confidentialité est incomplète.

Le fonctionnement hors ligne n’est pas un cas marginal — c’est une exigence fondamentale

Tout système de voyage supposant une connectivité parfaite est mal conçu.

• L’AAMVA confirme que la récupération sur l’appareil fonctionne sans connectivité extérieure pour l’appareil du titulaire comme pour le lecteur, et que la norme ISO/IEC 18013-5 exige que les mDL prennent en charge la récupération sur l’appareil.
• L’EUDI accepte que les parties de confiance puissent être hors ligne et ne disposent pas d’une liste de statut mise en cache, auquel cas elle recommande une analyse des risques avant de prendre une décision.

Il faut accepter ce compromis dès le départ :

Il est impossible d’avoir simultanément un fonctionnement hors ligne parfait et une fraîcheur en temps réel parfaite.

Toute architecture promettant les deux sans compromis est soit imprécise, soit en train de réintroduire discrètement la surveillance. La bonne réponse est de faire de la fraîcheur une entrée de politique, et non une dépendance réseau universelle.

Les journaux sont l’endroit où la confidentialité échoue silencieusement

Même une excellente architecture de statut peut être compromise par une journalisation négligente.

• L’EUDI exige que les instances de parties de confiance suppriment les éléments uniques et les horodatages dès qu’ils ne sont plus nécessaires, et interdit de les transmettre.
• L’AAMVA interdit aux parties prenantes de tracer les titulaires de mDL ou l’utilisation des mDL, sauf si la loi l’exige, demande aux autorités émettrices de minimiser le partage de métadonnées statiques ou de longue durée, et limite l’accès aux journaux d’activité au seul titulaire.
• L’AAMVA exige également que la suppression sur l’appareil efface les informations de journal et les métadonnées pouvant révéler l’historique d’utilisation — et que cette suppression soit possible hors ligne.

Il s’agit d’un comportement de protocole, et non d’une simple gestion administrative. Un futur PDI doit traiter les identifiants de longue durée, les horodatages et les journaux comme des outils de traçage potentiels, sauf preuve explicite du contraire.

Une architecture concrète sans rappel à l’émetteur pour le futur PDI

En rassemblant ces principes, voici ce que le système devrait concrètement faire :

1. Émettre un titre de base lié à l’appareil. Lier le titre aux clés protégées dans l’environnement sécurisé du portefeuille — obligatoire sous EUDI pour les DIP et les attestations ISO/IEC 18013-5.
2. Ne demander que ce qui est nécessaire, avec un défi fraîchement émis. Dans une transaction OpenID4VP, une requête DCQL permet au portefeuille d’indiquer au titulaire quels attributs sont demandés, et le vérificateur émet un défi pour empêcher la rejouabilité (conformément à l’architecture mDL actuelle du NIST).
3. Générer une présentation de courte durée, et non un identifiant réutilisable. Chaque présentation doit être spécifique au vérificateur, à la demande et au moment.
4. Vérifier l’authenticité localement. Valider les signatures et les clés publiques de l’émetteur hors ligne ; le service de confiance de l’AAMVA est conçu exactement à cet effet.
5. Vérifier le statut à partir de listes mises en cache et actualisées séparément. Lorsque les titres ont une durée de vie trop longue pour se passer de révocation, utiliser des listes de statut mises en cache localement et actualisées selon un calendrier sans lien avec les présentations d’utilisateurs.
6. Appliquer une politique de risque lorsque la fraîcheur est indisponible. Rendre les décisions hors ligne explicitement conformes à la politique du vérificateur, et non à des suppositions non structurées.
7. Supprimer agressivement les données de traçage. Éliminer les éléments uniques de transaction et les horodatages lorsqu’ils ne sont plus nécessaires ; ne pas conserver les journaux pouvant reconstituer l’historique de déplacement.

Voilà à quoi ressemble une architecture sérieuse sans rappel à l’émetteur — en couches, respectueuse de la vie privée, cryptographiquement locale, et honnête sur le plan opérationnel quant à la réalité hors ligne.

Trois modèles qui devraient être interdits par conception

Un écosystème PDI futur mature devrait considérer ceci comme des défauts d’architecture, et non comme des choix d’optimisation :

• Rappels obligatoires à l’émetteur à chaque présentation. Les propres recommandations de confidentialité de l’AAMVA expliquent pourquoi cela est préjudiciable.
• Utiliser le titre de conduire comme moyen de connexion habituel. Le NIST met explicitement en garde contre la présentation répétée de titres porteurs d’identité pour l’authentification quotidienne.
• Conserver les identifiants, horodatages et journaux pouvant reconstituer l’historique des présentations. L’EUDI et l’AAMVA exigent le contraire.

L’argument central en une phrase

La vérification instantanée ne doit pas devenir une autorisation de surveillance côté émetteur.

Un futur PDI doit pouvoir :

• Prouver l’authenticité localement.
• Prouver la possession localement.
• Vérifier la fraîcheur de manière privée.
• Tolérer la réalité hors ligne.
• Fonctionner correctement lorsque l’information parfaite est indisponible.

Rien de tout cela ne rend le système plus faible. Cela le rend digne d’être déployé à grande échelle.

Dès lors qu’un titre de conduire devient un outil permettant d’enregistrer qui a présenté quoi, où et quand, il cesse d’être une version plus sûre du papier. Il devient une infrastructure d’observation.

C’est précisément ce que le futur PDI doit refuser de devenir.

Foire aux questions

Qu’est-ce que la « vérification par rappel à l’émetteur » ?
Il s’agit de toute conception dans laquelle un vérificateur contacte l’émetteur en temps réel pour valider un titre. Si elle résout simultanément les problèmes d’authenticité et de révocation, elle permet également à l’émetteur d’observer chaque événement de présentation.

La norme ISO/IEC 18013-5 exige-t-elle un contact en ligne avec l’émetteur ?
Non. L’AAMVA confirme que la norme ISO/IEC 18013-5 exige la prise en charge de la récupération sur l’appareil et n’autorise la récupération sur serveur qu’à titre facultatif.

Comment la révocation peut-elle fonctionner sans contacter l’émetteur ?
Via des titres de courte durée, des listes de statut des attestations ou des listes de révocation des attestations — idéalement avec le téléchargement par la partie de confiance des données de statut séparément des présentations d’utilisateurs.

Pourquoi la « confidentialité de groupe » est-elle importante pour les listes de statut ?
Si une liste de statut est trop petite ou si ses indices sont prévisibles, une demande de statut peut révéler quel titre spécifique vient d’être présenté. Des indices aléatoires et des listes de grande taille permettent d’éviter cela.

La vérification hors ligne est-elle vraiment pratique ?
Oui — et les organismes de normalisation, dont l’AAMVA et l’EUDI, l’exigent explicitement. Le compromis est que la fraîcheur parfaite en temps réel est incompatible avec un fonctionnement hors ligne parfait ; la fraîcheur doit donc devenir une décision de politique, et non une dépendance contraignante.