Aller au contenu

Enregistrer les vérificateurs d'identité : empêcher qu'on demande plus que nécessaire

Enregistrer les vérificateurs d’identité : empêcher qu’on demande plus que nécessaire

Section intitulée « Enregistrer les vérificateurs d’identité : empêcher qu’on demande plus que nécessaire »

Dans la fédération d’identité telle qu’on la pratique, c’est l’utilisateur qui arbitre : un écran de consentement liste ce que le service demande, et il clique. On sait ce que vaut ce rituel. Le cadre du portefeuille européen d’identité numérique prend le problème autrement : avant de pouvoir demander quoi que ce soit, un vérificateur doit s’être inscrit dans un registre national en déclarant précisément les attributs qu’il demandera et pourquoi, et le portefeuille peut constater qu’une demande dépasse cette déclaration. La minimisation cesse d’être une clause contractuelle pour devenir un contrôle exécutable.

→ Lire l’explication complète de la marmotte

Le règlement d’exécution (UE) 2025/848 du 6 mai 2025 impose aux États membres d’établir et de tenir à jour au moins un registre national des parties utilisatrices de portefeuille établies sur leur territoire, de désigner au moins un bureau d’enregistrement chargé de l’exploiter, et de publier les politiques d’enregistrement applicables. L’objectif, dit le texte, est « de renforcer la confiance dans l’utilisation des portefeuilles ».

Le contenu obligatoire du registre tient dans l’annexe I, et deux de ses quinze points font tout l’intérêt du dispositif. Le point 9 exige, pour chaque utilisation prévue, « une liste des données, comprenant les attestations et attributs, que la partie utilisatrice a l’intention de demander », avec un pseudonyme commode, une dénomination technique, le type d’attestation et la syntaxe de groupement, « dans un format lisible par la machine aux fins d’un traitement automatisé ». Le point 10 exige, pour chaque utilisation prévue, une description de l’usage que le vérificateur fera de ces données. Lisible par la machine : c’est ce qui sépare un engagement de principe d’une contrainte opérationnelle.

Le reste de l’annexe I est de l’état civil d’entreprise : nom tel qu’il figure dans un registre officiel, identifiants parmi une liste fermée qui va du numéro de TVA à l’identifiant d’entité juridique en passant par l’identifiant unique européen, adresse physique d’établissement, coordonnées de contact, description du type de services, mention indiquant s’il s’agit d’un organisme du secteur public. Le point 12 ajoute une liste d’habilitations à valeurs imposées, de Service_Provider pour un simple prestataire à PID_Provider pour un fournisseur de données d’identification personnelle, en passant par les différentes catégories de prestataires de services de confiance. Et l’annexe III précise sur quelles sources ces habilitations se vérifient : les listes nationales de confiance publiées au titre du règlement eIDAS, ou les listes publiées par la Commission, et non la parole du demandeur.

Le registre est public et interrogeable par programme. L’annexe II exige une interface de programmation commune unique, de style REST, au format JSON, signée selon la RFC 7515 dont le mécanisme est décrit dans JWS, publiée sous forme d’OpenAPI version 3, et qui permet « à tout demandeur, sans authentification préalable, d’effectuer des recherches et de demander des listes complètes ». Les réponses comprennent les informations de l’annexe I et les certificats d’accès et d’enregistrement, actuels et historiques, mais excluent les coordonnées de contact. Un registre ouvert, signé et historisé : il faudra s’en souvenir en fin de page, parce que cette ouverture a un coût.

Le règlement distingue deux objets dont les noms se ressemblent et les fonctions pas du tout.

Le certificat d’accès de partie utilisatrice de portefeuille sert à s’identifier auprès du portefeuille. Le considérant 8 en explique la raison : il incombe aux États membres de veiller à ce que les portefeuilles soient « capables d’authentifier les parties utilisatrices de portefeuille, quel que soit le lieu où elles sont établies dans l’Union », et c’est ce certificat qui le permet. Il est délivré par un fournisseur mandaté par un État membre, et il doit respecter des exigences communes pour que n’importe quel portefeuille de l’Union puisse le valider, selon la mécanique de chaînage de confiance décrite dans relier une clé à une identité. Sa fonction est donc de répondre à « qui me parle ».

Le certificat d’enregistrement de partie utilisatrice de portefeuille est un objet de données « qui décrit l’utilisation prévue » du vérificateur. Sa fonction est de répondre à une autre question : « a-t-il le droit de me demander cela ? ». Le considérant 9 est explicite sur la finalité : les États membres peuvent en exiger la délivrance « afin de permettre aux utilisateurs de portefeuille de vérifier que les attributs demandés par la partie utilisatrice de portefeuille entrent dans le cadre des attributs faisant l’objet d’un enregistrement par celle-ci ». Le vérificateur apporte donc, avec sa demande, une déclaration signée de ce qu’il a le droit de demander, et le portefeuille compare.

La différence est celle qui sépare l’authentification de l’autorisation, et il vaut la peine de noter que le cadre européen a pris soin de les porter dans deux objets distincts. Un seul certificat portant les deux informations aurait obligé à le réémettre à chaque changement de périmètre de service, et aurait rendu la comparaison moins lisible. Deux certificats, deux cycles de vie, deux questions.

Vient le cœur du dispositif, et il repose sur trois obligations qui s’emboîtent.

La première est une interdiction de fond, que le considérant 9 reprend du règlement eIDAS modifié : les parties utilisatrices « doivent s’abstenir de demander aux utilisateurs de fournir d’autres données que celles relatives à l’utilisation prévue des portefeuilles renseignées au cours de la procédure d’enregistrement ». Ce n’est pas la minimisation du règlement général sur la protection des données, qui demande de ne collecter que ce qui est adéquat et nécessaire au regard des finalités, et qui s’apprécie après coup, souvent par une autorité, parfois des années plus tard. C’est une minimisation par rapport à une déclaration préalable, publique et lisible par machine. Les deux se cumulent, et la seconde est exécutable. Le principe général et sa version française sont traités dans la minimisation de la collecte et dans les exigences d’architecture du RGPD.

La deuxième est une obligation d’alerte, posée par le considérant 10 : « afin de protéger les utilisateurs contre le partage excessif d’informations avec les parties utilisatrices de portefeuille et de les avertir en pareille circonstance, les États membres devraient prévoir, dans leurs politiques en matière de certificats, des politiques d’accès communes qui permettraient à une solution de portefeuille d’informer l’utilisateur de portefeuille lorsqu’une partie utilisatrice de portefeuille demande davantage d’informations que celles auxquelles son enregistrement ou son autorisation lui permettent d’accéder ». Le portefeuille ne se contente donc pas de transmettre une demande : il l’évalue et prévient. C’est le même renversement que celui des politiques de divulgation intégrées exposées dans la divulgation sélective, où l’attestation elle-même porte les conditions de son usage.

La troisième est un droit de l’utilisateur à ne pas être identifié quand rien ne l’exige : les parties utilisatrices « ne devraient pas refuser l’utilisation de pseudonymes lorsque l’identification de l’utilisateur n’est pas requise par le droit de l’Union ou le droit national ». Combinée à la capacité du portefeuille de générer un pseudonyme spécifique et exclusif par vérificateur, cette règle attaque l’habitude la plus répandue du commerce en ligne, qui consiste à demander une identité civile pour un service qui n’en a aucun besoin. Les vérificateurs doivent en outre déclarer, à des fins de transparence, s’ils ont l’intention de recourir à l’identification électronique des personnes physiques pour satisfaire l’une des bases légales de l’article 6 du règlement général sur la protection des données.

La sanction : suspension sans préavis, et sa proportionnalité

Section intitulée « La sanction : suspension sans préavis, et sa proportionnalité »

Une déclaration ne sert à rien sans conséquence, et le considérant 11 en prévoit une qui a des dents. Les bureaux d’enregistrement « devraient pouvoir suspendre ou annuler sans préavis l’enregistrement de toute partie utilisatrice de portefeuille » dans trois cas : lorsque l’enregistrement contient des informations « inexactes, obsolètes ou trompeuses » ; lorsque le vérificateur ne respecte pas la politique d’enregistrement ; ou lorsqu’il agit en violation du droit de l’Union, du droit national ou de la déclaration européenne sur les droits et principes numériques, et le texte donne l’exemple qui nous intéresse : « par exemple en ne réduisant pas dûment au minimum le jeu d’attributs auquel elle demande l’accès ».

Demander trop est donc un motif explicite de retrait du droit d’utiliser le portefeuille. Pour un service en ligne, cela signifie perdre un canal d’identification, ce qui est une sanction d’une nature différente des amendes administratives habituelles : elle ne se provisionne pas, elle s’applique immédiatement. Le règlement tempère cependant, et ce contrepoids est intéressant à lire : la décision de suspendre ou d’annuler « devrait être proportionnée à l’interruption de service causée par la suspension ou l’annulation et aux coûts et désagréments qui s’ensuivent pour le prestataire de services et l’utilisateur », au nom de la stabilité de l’écosystème. Autrement dit, le bureau d’enregistrement ne coupe pas un grand service public aussi facilement qu’une boutique, ce qui est à la fois raisonnable et une invitation assez claire à être gros.

Deux dispositions complètent le tableau. Les organes de contrôle institués par le règlement eIDAS sont également habilités à suspendre et annuler un enregistrement, ce qui évite que la sanction ne dépende du seul bureau d’enregistrement. Et le considérant 12 impose la conservation pendant dix ans de toutes les informations fournies par les vérificateurs inscrits, « aux fins des contrôles a posteriori, des enquêtes menées par les autorités répressives et du traitement des litiges ». Une déclaration d’attributs faite en 2027 sera donc opposable en 2037, ce qui change la nature de l’exercice : on ne déclare pas un périmètre large « pour voir ».

Ce que ce modèle apporte, et ce qu’il ne règle pas

Section intitulée « Ce que ce modèle apporte, et ce qu’il ne règle pas »

Comparons franchement avec ce que le monde OAuth fait aujourd’hui. L’enregistrement dynamique de client, décrit dans la découverte et l’enregistrement dynamique, permet à un client de s’inscrire tout seul auprès d’un fournisseur d’identité, en déclarant ses propres métadonnées, sans contrôle sur le demandeur ni sur ce qu’il demandera. Le modèle du portefeuille inverse les trois paramètres : l’enregistrement est préalable, il est vérifié sur des sources officielles, et il est public. Le prix est évidemment la lourdeur, et le règlement en est conscient puisqu’il demande des procédures d’enregistrement « en ligne commodes et, le cas échéant, automatisées », vérifiées « dans les meilleurs délais », pour que la procédure reste « rentable et proportionnée au risque ».

Trois limites, en revanche, méritent d’être nommées. La première est que le registre déclare une intention, pas un comportement : rien dans ce mécanisme n’empêche un vérificateur de demander exactement ce qu’il a déclaré et d’en faire autre chose. La description de l’utilisation prévue est un texte libre, et sa confrontation à l’usage réel reste du ressort des autorités de protection des données, avec les délais que l’on connaît.

La deuxième est que l’interface publique interrogeable sans authentification est aussi une surface d’énumération. Toute personne peut obtenir la liste complète des services d’un pays qui s’appuient sur le portefeuille, leurs identifiants d’entreprise, leurs habilitations, et surtout la liste exacte des attributs que chacun demande. C’est précisément ce qu’il faut pour que l’utilisateur vérifie, et précisément ce qu’il faut pour préparer un hameçonnage crédible qui imite la demande d’un service légitime. Le règlement exclut les coordonnées de contact de ces réponses, ce qui est une précaution mince ; la défense repose entièrement sur l’authentification du vérificateur par son certificat d’accès, et donc sur le fait que le portefeuille la vérifie réellement.

La troisième est structurelle : ce dispositif crée un point de passage obligé par État membre, dont la disponibilité conditionne l’usage du portefeuille. L’annexe II exige d’ailleurs des fonctions de sécurité garantissant « la disponibilité et l’intégrité » de l’interface, ce qui est la reconnaissance polie du fait qu’un registre indisponible bloque la vérification. Un registre dont les données seraient altérées serait pire : il autoriserait des demandes qui n’ont jamais été déclarées. La signature électronique de chaque réponse est la contre-mesure prévue, et c’est la bonne ; elle suppose seulement que les portefeuilles la vérifient, ce qui, l’histoire du web l’a montré, n’est jamais acquis.

Sans déclaration préalable des attributs demandés dans un format lisible par machine, la minimisation reste une appréciation a posteriori, et le seul arbitre est un écran de consentement que l’utilisateur accepte sans le lire. Sans séparation entre certificat d’accès et certificat d’enregistrement, l’identité du vérificateur et l’étendue de ses droits voyagent dans le même objet, qu’il faut réémettre à chaque changement de périmètre. Sans politique d’accès commune permettant au portefeuille d’alerter, une demande excessive passe exactement comme une demande légitime, et l’utilisateur n’a aucun moyen de faire la différence. Sans possibilité de suspendre l’enregistrement, demander trop n’a aucune conséquence autre qu’une procédure administrative de plusieurs années. Sans vérification des habilitations sur des listes de confiance officielles, un demandeur se déclare fournisseur de données d’identification personnelle et personne ne le contredit. Et sans vérification par le portefeuille de la signature des réponses du registre, un registre altéré autorise des demandes qui n’ont jamais été déclarées.

Quand un site demande de prouver son identité, il reçoit aujourd’hui ce que l’utilisateur accepte de donner, et l’utilisateur accepte presque toujours. Le cadre européen du portefeuille d’identité numérique change l’ordre des opérations. Avant même de pouvoir demander quelque chose, un service doit s’inscrire dans un registre tenu par son pays, et y déclarer, usage par usage, la liste exacte des informations qu’il demandera et ce qu’il en fera. Cette liste est publique et rédigée dans un format que les logiciels savent lire.

Ensuite, à chaque demande, le service présente deux choses. Un premier certificat dit qui il est, et permet au portefeuille de l’authentifier. Un second décrit ce qu’il a déclaré avoir le droit de demander. Le portefeuille compare la demande à cette déclaration, et si la demande dépasse, il prévient la personne. C’est donc le logiciel qui fait la vérification, et non l’utilisateur qui lirait une page de conditions.

Trois règles complètent l’édifice. Un service ne peut pas demander autre chose que ce qu’il a déclaré. Un service ne peut pas refuser un pseudonyme quand la loi ne l’oblige pas à connaître l’identité réelle. Et un service qui demande trop peut voir son inscription suspendue sans préavis, donc perdre la possibilité d’utiliser le portefeuille, ce qui est une sanction immédiate et non une amende lointaine. Les déclarations sont conservées dix ans, de sorte qu’on ne déclare pas un périmètre large au cas où.

Il faut connaître les limites. Le registre dit ce qu’un service a l’intention de demander, pas ce qu’il fera des données obtenues : cette seconde question reste du ressort des autorités de protection des données. Le registre est ouvert à tous, sans compte, ce qui permet à chacun de vérifier mais fournit aussi à un escroc le modèle exact d’une demande crédible. Et comme tout point de passage unique, il doit rester disponible et intègre, sinon il bloque les vérifications ou, pire, en autorise de fausses.

À lire aussi

Pages voisines

: les deux pages se citent l’une l’autre.