Police, Loueurs de Véhicules, Employeurs, Assureurs : Pourquoi Ils Ne Doivent Pas Voir les Mêmes Données

La plus grande erreur de conception d’un futur Permis de Conduire International (PCI) serait de traiter chaque vérificateur comme un vérificateur identique. Un agent de police, un comptoir de location de voitures, un employeur et un assureur ne posent pas la même question — ils ne devraient donc pas recevoir la même réponse.

Un seul conducteur. Un seul droit sous-jacent de conduire. Un seul portefeuille numérique. Mais quatre vérificateurs très différents :

• Un agent de police au bord de la route
• Un comptoir de location de voitures au moment de la prise en charge
• Un employeur vérifiant l’éligibilité à la flotte d’entreprise
• Un assureur examinant une déclaration de sinistre

Si le futur PCI affiche les mêmes données aux quatre, le système a déjà échoué. Non pas parce que la credential est non sécurisée, mais parce que le modèle de divulgation est trop simpliste.

La communauté des normes s’éloigne déjà de ce modèle simpliste. Les travaux du W3C sur les justificatifs vérifiables décrivent l’écosystème autour des émetteurs, des détenteurs et des vérificateurs, en utilisant les employeurs et les sites web comme exemples de vérificateurs. Les travaux de l’Union européenne sur le permis de conduire mobile traitent déjà les contrôles routiers et les locations de voitures comme des scénarios de vérification distincts, notamment le partage préalable à distance pour les locations et les contrôles en personne pour la police. L’architecture est déjà conçue pour plusieurs types de vérificateurs. L’erreur serait de concevoir l’expérience utilisateur comme si un seul type existait.

Pourquoi la Carte Physique Nous a Appris à Penser Incorrectement

Un permis de conduire physique nous a habitués à une approche de tout montrer. On tend la carte. L’autre personne voit ce qui est inscrit dessus. C’est toute l’interaction.

Cette approche est acceptable dans un monde papier car il n’y a pas d’alternative. Elle devient inacceptable dans un monde numérique.

Le modèle de données W3C VC 2.0 le stipule directement : un permis de conduire peut contenir un numéro d’identification, la taille, le poids, la date de naissance et l’adresse du domicile — mais cela peut toujours représenter bien plus que nécessaire pour une transaction donnée. Points clés des normes actuelles :

• Bonne pratique W3C : prendre en charge la divulgation sélective et ne demander que ce qui est strictement nécessaire
• Recommandations européennes en matière de protection des données : le traitement doit être limité à des finalités spécifiées, et les données traitées doivent être nécessaires et proportionnées
• Le premier principe d’un futur PCI : une même credential ne signifie pas un même droit d’inspection

Le Bon Modèle Est la Divulgation Basée sur les Politiques

Si vous souhaitez une architecture sérieuse, le bon modèle se rapproche davantage du contrôle d’accès basé sur les attributs que de la présentation d’une carte numérique.

Le NIST SP 800-205 définit les décisions de contrôle d’accès comme des évaluations des attributs associés au sujet, à l’objet, à l’opération demandée et aux conditions environnementales, par rapport à une politique. C’est exactement la bonne structure pour un futur PCI :

• Sujet : le conducteur
• Objet : les champs de données demandés
• Action : non pas « voir le permis » dans l’abstrait, mais quelque chose de précis comme « vérifier le droit de conduire la catégorie B en bord de route » ou « vérifier l’éligibilité à la location pour une réservation »
• Environnement : contrôle routier, comptoir de location, pré-vérification à distance, intégration à la flotte d’entreprise et examen post-sinistre sont des environnements différents et doivent conduire à des décisions différentes

Le NIST souligne également que les systèmes d’attributs nécessitent de la granularité, une gouvernance et des mécanismes de réduction, de regroupement et de minimisation des attributs.

Ainsi, le futur PCI ne devrait pas se demander : Ce vérificateur peut-il lire le permis ? Il devrait se demander : Quelles affirmations ce vérificateur peut-il recevoir, pour quel usage prévu, dans quel environnement, et selon quelles règles de conservation ?

Un Vérificateur Doit S’Identifier Avant de Demander Quoi que ce Soit

Le futur PCI ne devrait pas commencer par l’affichage des données par le portefeuille numérique. Il devrait commencer par la preuve d’identité du vérificateur.

L’architecture EUDI est claire à ce sujet. Les parties de confiance doivent :

• Enregistrer les attributs qu’elles ont l’intention de demander et à quelle fin
• Recevoir des certificats d’accès
• S’authentifier auprès du portefeuille numérique avant toute divulgation
• Être vérifiées par rapport à leur périmètre enregistré, lorsque les informations d’enregistrement sont disponibles

L’utilisateur peut ensuite voir qui demande, ce qui est demandé et si la demande est dans le périmètre enregistré.

Les travaux actuels de l’ETSI sur les certificats des parties de confiance des portefeuilles numériques précisent cela davantage. Un certificat d’enregistrement de partie de confiance de portefeuille numérique peut décrire l’usage prévu par la partie de confiance et les attributs qu’elle a enregistrés pour les demander. Le certificat d’accès associé existe pour s’assurer que la demande provient d’une partie légitime et autorisée. L’ETSI inclut également des métadonnées sur les parties de confiance, telles que :

• Nom commercial
• URI d’assistance
• Usage prévu
• Habilitations
• URI du registre
• Informations sur l’autorité de surveillance

Le deuxième principe d’un futur PCI : sans identification du vérificateur, pas de divulgation.

Pourquoi les Écrans de Consentement Ne Sont Pas Suffisants

Il y a une autre erreur ici : traiter l’approbation de l’utilisateur comme équivalente à la légitimité juridique.

L’architecture EUDI précise explicitement que l’approbation de l’utilisateur pour présenter des attributs ne doit pas être traitée comme un fondement juridique pour le traitement des données personnelles par la partie de confiance. La partie de confiance doit toujours disposer de sa propre base légale. L’EUDI exige également l’approbation de l’utilisateur dans tous les cas d’usage, y compris lorsque la partie de confiance peut appartenir aux forces de l’ordre ou à un autre organisme gouvernemental.

Une bonne interface de portefeuille numérique peut aider, mais elle ne peut pas résoudre à elle seule les abus des vérificateurs. La règle doit exister avant l’interface.

Un futur PCI nécessite donc les deux :

• L’authentification cryptographique du vérificateur pour confirmer qui pose la question
• Des contraintes de politique sur ce que cette catégorie de vérificateur peut demander

Sans les deux, le « choix de l’utilisateur » devient un moyen de reporter les échecs de politique sur l’individu.

1. Police : Vérifier le Droit de Conduire, Pas l’Identité Complète

Le scénario de contrôle routier par la police est le plus ciblé.

Le manuel européen sur le permis de conduire mobile le décrit directement : la police ou d’autres agents vérifient le permis lorsque cela est requis, notamment la validité du permis et les droits relatifs au véhicule. Dans le parcours utilisateur, l’agent vérifie le permis via un flux déclenché par un QR code, Bluetooth, Wi-Fi Aware ou NFC. Il s’agit d’une tâche de vérification ciblée :

• Cette personne est-elle bien le titulaire ?
• La credential est-elle valide ?
• Quels droits et restrictions relatifs au véhicule s’appliquent ?

Autorisé par défaut :

• Nom
• Portrait
• Statut du permis
• Dates d’émission et d’expiration
• Catégories
• Restrictions relatives à la conduite
• Émetteur et juridiction
• Résultat de fraîcheur/statut

Non autorisé par défaut :

• Adresse du domicile
• Identifiants internes non nécessaires pour l’usage en bord de route
• Attributs non liés provenant d’autres attestations
• Journaux historiques de présentation
• Métadonnées commerciales

Les recommandations de mise en œuvre de l’AAMVA renforcent le point concernant le portrait : si le portrait est demandé et qu’un autre élément est divulgué, le portrait doit être partagé afin que le vérificateur puisse relier les données à la personne qui le présente. Le même guide précise également que les parties prenantes ne doivent pas tracer les titulaires de permis de conduire mobile ni leur usage, sauf lorsque la loi l’exige.

Le cas policier ne concerne pas l’accès de l’État à tout. Il s’agit de l’accès de l’État aux données spécifiques à la conduite nécessaires au contrôle routier. C’est une différence importante.

2. Loueurs de Véhicules : Éligibilité, Correspondance d’Identité et Rien de Superflu

Le cas de la location est plus détaillé car il y a vraiment deux moments : la pré-vérification à distance avant l’arrivée, et la prise en charge lorsqu’une personne ou une borne remet les clés.

Le manuel européen sur le permis de conduire mobile modélise déjà les deux situations. Un service de location de voitures peut demander le permis de conduire mobile ainsi qu’une preuve d’identité lors de la réservation, valider les attestations, puis vérifier le client en personne lors de la prise en charge avant de remettre le véhicule. Les utilisateurs peuvent partager leurs permis de conduire mobiles avec les sociétés de location de voitures en personne ou à distance à l’avance.

Un comptoir de location n’a pas principalement besoin d’enquêter sur un incident. Il doit décider : Puis-je louer ce véhicule à ce client dans le cadre de cette réservation et de cette politique ?

La pré-vérification à distance devrait inclure :

• Lien d’identité
• Portrait ou élément équivalent de liaison d’identité
• Catégorie de véhicule concernée
• Dates d’émission et d’expiration
• Validité actuelle
• Éventuellement un seuil d’âge ou une tranche d’âge

La prise en charge devrait confirmer :

• Le titulaire est bien la même personne qui a effectué la pré-vérification
• La validité actuelle
• Les droits pertinents

Non nécessaire par défaut :

• Adresse complète du domicile lorsqu’un profil de réservation contient déjà les coordonnées
• Date de naissance complète lorsqu’un indicateur de majorité ou une tranche d’âge est suffisant
• Attributs d’identité non liés
• Nouvelle présentation répétée de la credential complète si une attestation de réservation existe déjà

L’architecture actuelle du NIST pour les permis de conduire mobiles montre que la partie de confiance utilise DCQL pour ne demander que les attributs nécessaires, et précise explicitement que cela prend en charge la minimisation des données et le consentement du titulaire en structurant la demande plutôt qu’en traitant la credential comme une unité unique. L’AAMVA ajoute que l’application doit clairement indiquer quelles données ont été demandées et si le vérificateur a l’intention de les conserver.

3. Employeurs : Une Catégorie de Vérificateur, Pas une Ouverture sur l’Identité Complète

L’aperçu du W3C utilise le système numérique d’un employeur vérifiant un diplôme universitaire comme exemple de vérificateur. Cela nous rappelle que la vérification par l’employeur est déjà un schéma reconnu dans les écosystèmes de credentials.

Un employeur ou un gestionnaire de flotte peut légitimement avoir besoin de savoir :

• Si un travailleur est actuellement habilité à conduire certaines catégories de véhicules
• Si des restrictions importantes existent
• Si l’habilitation reste valide

C’est un besoin commercial réel. Mais cela ne justifie pas automatiquement un accès permanent à l’intégralité de la credential de conduite, à toutes les données d’identité, ni à un flux continu de présentations répétées.

Le NIST avertit que la transmission fréquente d’un identifiant réutilisable et le fait de conditionner les utilisateurs à présenter répétitivement une credential contenant des données d’identité sont indésirables, et précise que l’authentification au quotidien devrait reposer sur des technologies conçues à cet effet, telles que les clés d’accès. Le NIST préfère l’authentification locale sur l’appareil à la correspondance biométrique côté serveur car elle préserve mieux la confidentialité.

Un futur PCI ne devrait pas devenir un badge d’accès au lieu de travail.

Pour les usages employeur et flotte, le bon schéma est généralement :

• Une vérification des habilitations pertinentes au poste
• Éventuellement une attestation périodique de conformité
• Éventuellement une affirmation que le titulaire reste valide pour les catégories spécifiées
• Mais pas un transfert par défaut de toutes les données du permis à chaque fois que l’employé se connecte à un système ou commence un quart de travail

La conformité de la flotte est une catégorie distincte de partie de confiance, avec un usage prévu distinct et un profil de divulgation distinct.

4. Assureurs : Les Sinistres Ne Sont Pas une Permission d’Accès Permanent

Le cas de l’assurance est souvent réel. Dans le matériel relatif aux cas d’usage du permis de conduire mobile européen, les assureurs apparaissent indirectement dans le scénario de location : les compagnies d’assurance exigent des sociétés de location de voitures qu’elles vérifient si la personne qui loue le véhicule a le droit de conduire. L’assurance influence déjà le flux de vérification de la conduite.

Mais cela ne signifie pas qu’un assureur devrait recevoir les mêmes données que la police, ni avoir un droit d’accès permanent à la credential.

Un futur PCI devrait traiter les assureurs comme une catégorie de vérificateur distincte avec des usages prévus distincts :

• Souscription
• Vérification du risque locatif
• Gestion des sinistres post-perte
• Examen des fraudes

Ces finalités ne sont pas identiques. Selon les principes européens de protection des données, les données personnelles doivent être collectées pour des finalités spécifiées et limitées à ce qui est nécessaire et proportionné à cette finalité. Les recommandations VC du W3C parviennent à la même conclusion sur le plan technique : les vérificateurs ne devraient demander que ce qui est strictement nécessaire.

Exemples légitimes et spécifiques à un événement :

• Preuve que le permis était valide au moment concerné
• Preuve du droit sur le véhicule concerné
• Preuve du lien d’identité lorsque cela est nécessaire pour un sinistre
• Divulgation spécifique au sinistre

Non autorisé par défaut :

• Accès persistant à la credential sous-jacente
• Vérification générique répétée à chaque interaction du client avec l’assureur
• Utilisation de la credential de conduite comme jeton de connexion
• Collecte d’attributs non liés

Une credential de conduite n’est pas un abonnement de surveillance. Et elle ne devrait pas le devenir discrètement.

Pourquoi les Intermédiaires Doivent Être Visibles

Les marchés réels impliquent des intermédiaires. Les plateformes de location, les prestataires de flotte, les systèmes RH des employeurs et les gestionnaires de sinistres d’assurance agissent souvent via des tiers.

L’architecture EUDI gère cela en :

• Traitant les intermédiaires comme des parties de confiance
• Exigeant leur enregistrement
• Exigeant que les attributs demandés pour la partie de confiance intermédiée soient enregistrés
• Affichant à l’utilisateur à la fois l’intermédiaire et la partie de confiance finale
• Interdisant aux intermédiaires de stocker des données sur le contenu de la transaction

Un futur PCI ne devrait jamais permettre un schéma où l’utilisateur croit divulguer ses données à la société de location, alors qu’en réalité il les divulgue à une chaîne invisible comprenant un courtier de vérification, un processeur d’analyses et un prestataire de sinistres.

L’ETSI contribue ici. Son modèle de certificat de partie de confiance de portefeuille numérique inclut des URI d’assistance, l’usage prévu, des URI de registre et des métadonnées sur les autorités de surveillance. C’est le type d’infrastructure lisible par machine nécessaire pour que les utilisateurs comprennent qui se trouve réellement à l’autre bout de la demande et où s’adresser lorsqu’ils souhaitent une suppression ou une correction.

La Conservation Fait Partie du Contrôle d’Accès

La plupart des discussions sur la divulgation sélective s’arrêtent trop tôt. Elles se concentrent sur ce qui est divulgué. Elles ne s’attardent pas suffisamment sur la durée pendant laquelle les données sont conservées ensuite.

Les recommandations actuelles convergent déjà :

• AAMVA : le portefeuille numérique doit clairement informer le titulaire des données demandées et de l’intention du vérificateur de les conserver ; les parties prenantes ne doivent pas tracer les titulaires ou l’usage du permis de conduire mobile sauf lorsque la loi l’exige
• W3C : le logiciel du titulaire devrait fournir des journaux des informations partagées avec les vérificateurs, afin que les demandes excessives puissent être identifiées
• EUDI : les utilisateurs devraient pouvoir accéder aux journaux de transactions, signaler des demandes suspectes et demander l’effacement

La classe de conservation devrait faire partie de la politique de divulgation elle-même :

• Contrôle routier par la police : aucune conservation par défaut au-delà du registre opérationnel légalement requis
• Pré-vérification de location : enregistrement de transaction lié à la réservation, et non une copie d’identité réutilisable
• Conformité de la flotte employeur : enregistrement de conformité ou résultat d’attestation, et non les données brutes de la credential
• Sinistre assureur : dossier de sinistre limité au sinistre concerné, et non un accès permanent

Un futur PCI qui ignore la conservation ne préserve que partiellement la confidentialité.

Ce que le Portefeuille Numérique Devrait Réellement Décider

Si je devais réduire l’ensemble de cet article à une seule règle d’implémentation, ce serait celle-ci :

Le portefeuille numérique ne devrait pas répondre à « Puis-je présenter cette credential ? » Il devrait répondre à « Puis-je présenter cet ensemble d’affirmations à ce vérificateur authentifié, pour cet usage prévu, dans ce contexte, selon cette classe de conservation ? »

Cette décision devrait être guidée par au moins ces paramètres :

• Identité du vérificateur
• Catégorie du vérificateur
• Usage prévu
• Périmètre d’attributs enregistré
• Politique de divulgation de l’émetteur, si disponible
• Environnement (bord de route, prise en charge, à distance, flotte, sinistre)
• Approbation du titulaire
• Politique de conservation applicable

Les normes contiennent déjà une grande partie des mécanismes nécessaires : divulgation sélective, authentification des parties de confiance, usage prévu enregistré, certificats d’accès, évaluation des politiques de divulgation et demandes liées à une finalité. Ce qui manque encore, c’est la rigueur nécessaire pour traiter ces éléments comme une architecture de divulgation cohérente.

L’Argument Central

Le futur PCI ne devrait pas se demander si des données peuvent être divulguées. Il devrait se demander :

• Qui demande ?
• Dans quel but ?
• Selon quelle autorité ?
• Dans quel contexte ?
• Avec quelles conséquences en matière de conservation ?

La police, les loueurs de véhicules, les employeurs et les assureurs ne sont pas quatre logos à l’autre bout d’une demande. Ce sont quatre modèles de risque différents, quatre contextes juridiques différents, quatre raisons de demander différentes — et ils devraient produire quatre ensembles de divulgation différents.

Ce n’est pas une complexité inutile. C’est à quoi ressemble une credential de conduite moderne lorsqu’elle cesse de traiter chaque vérificateur comme un vérificateur identique.