Dans la foulée des échanges de la journée du 8 avril, je partage quelques réflexions complémentaires sur le cas d’usage paiement des portefeuilles/wallets européens d’identité numérique (wallets eIDAS) orientées autour de trois idées principales :
- Mais réconcilier l’environnement eIDAS et celui de la DSP2 reste un chantier à ouvrir
- Et les spécifications techniques et le modèle français de wallet eIDAS sont encore à construire
- Le nouveau règlement eIDAS annonce le futur des paiements numériques
C’est sans doute la donnée fondamentale, celle qui fixe le cap général et part du double constat de la convergence des attributs d’identité, de statut et de paiement dans les wallets mais aussi de la capacité des wallets eIDAS de gérer de façon autonome et sécurisée l’authentification forte lorsqu’elle est requise par la loi.
Car l’arrivée des wallets eIDAS est un événement majeur pour les interactions numériques des citoyens européens, qui sera évidemment renforcé par l’arrivée des wallets d’entreprise annoncée en janvier 2025 et la généralisation des attestations d’attributs pour les personnes morales (cette généralisation étant notamment prévue par la directive 2025/25 concernant la numérisation du droit des sociétés). De fait, les wallets de particuliers et d’entreprise sont au cœur de l’infrastructure digitale publique européenne en cours de construction.
Ne nous y trompons pas, les attestations d’attributs disponibles au sein des wallets d’identité numérique vont s’étendre à tous les domaines car elles répondent à des besoins évidents des prestataires de services. Que l’on pense aux attestations de majorité, de statut spécifique (étudiant, salarié, retraité, marié/pacsé, etc) ou de résidence (de pays, de région ou de ville), de très nombreux cas d’usage bénéficieront de leur déploiement sécurisé. Certains d’entre eux sont expressément au menu des travaux des futurs LSP Aptitude et WeBuild.
C’est aussi un changement de paradigme résultant de l’adoption d’un schéma d’interactions digitales à vocation décentralisée et basé sur des attestations vérifiables (verifiable credentials) individualisées. C’est toute la logique du passage du protocole OpenID Connect (schéma centralisé – notamment utilisé par France Connect ou, dans un domaine voisin, par B-Connect) à OID4VP (schéma décentralisé de présentation d’attestations inscrit dans la norme ISO 18013-7, elle-même actée comme standard unique des interactions en ligne des wallets eIDAS dans le règlement d’application eIDAS dédié). Ce changement mettant en œuvre la minimisation des données est respectueux de la privacy et doit être encouragé.
En résumé, la possibilité pour les wallets eIDAS d’assurer de façon autonome l’authentification forte lorsque celle-ci est requise par la loi, en mode embarqué (embedded) sans redirection vers le teneur de compte du payeur et la mise à disposition au sein des wallets eIDAS d’attestations sécurisées et individualisées définit clairement un nouveau cadre de référence pour les paiements offrant à la fois plus de sécurité (et donc une meilleure lutte contre la fraude) mais aussi, et c’est peut-être encore plus structurant, de meilleurs services pour les commerçants et autres fournisseurs de services. Certes, de nombreux challenges restent à surmonter avant la généralisation de ce nouvel environnement, mais on ne saurait méconnaître l’intérêt véritablement stratégique que représente dans des interactions uniques la présentation combinée d’attributs d’identité, de statut et de moyens de paiement. C’est le monde de demain qu’il convient de préparer dès aujourd’hui.
- Le challenge de la réconciliation eIDAS/DSP2
Si l’arrivée des wallets eIDAS annonce une nouvelle ère des paiements numériques, force est de constater que celle-ci ne s’intègre qu’imparfaitement dans le cadre réglementaire des paiements actuel – celui de la DSP2, ce qui ne saurait étonner pour un texte réglementaire bien antérieur au règlement eIDAS actuel – mais également celui du futur règlement sur les services de paiement en préparation, ce qui est par contre plus problématique.
Une première raison structurelle explique ce décalage. Elle tient au fait que la réglementation européenne des paiements est basée sur le principe cardinal de l’approche par les risques, également au cœur de la règlementation sur la lutte anti-blanchiment, qui veut qu’à situation plus risquée corresponde un mécanisme d’authentification plus rigoureux et, à situation moins risquée, un mécanisme d’authentification plus fluide. Cette notion centrale dans les mécanismes d’authentification des paiements est étrangère à l’environnement eIDAS des wallets d’identité numérique, lesquels sont conçus pour offrir à leurs titulaires un schéma offrant un niveau de garantie élevé, imposant de fait des contraintes et frictions d’utilisation qui risquent d’affecter l’expérience client et s’avérer même rédhibitoires pour des paiements quotidiens. Faudrait-il en effet, pour autoriser un paiement, trois utilisations de la touche biométrique de son smartphone, une première fois pour déverrouiller l’application, une deuxième fois pour mettre en œuvre l’authentification mutuelle avec le bénéficiaire du paiement et une troisième fois pour valider le paiement proprement dit ? La comparaison avec les paiements sans contact qui de plus gèrent sans difficulté le mode hors ligne (alors que celui-ci n’est pas pris en compte actuellement pour les wallets eIDAS) risque d’être sévère pour les wallets eIDAS, et décourager les utilisateurs, ce qui serait évidemment très préjudiciable au déploiement à grande échelle d’un schéma qui repose sur une adhésion volontaire des utilisateurs.
Il serait certes envisageable que les wallets eIDAS soient autorisés à fonctionner sur un mode moins contraignant que celui requis par le niveau de garantie élevé lorsque le cas d’usage ne justifie pas d’un tel mode – et on rappellera à cet égard que le règlement LCB-FT européen du 31 mai 2024 définit, comme aujourd’hui en France, le niveau eIDAS Substantiel (évidemment moins contraignant que le niveau Elevé) comme niveau de référence. Ceci dit, la possibilité pour les wallets eIDAS de fonctionner autrement qu’en mode eIDAS Elevé fait débat et n’est pas aujourd’hui officiellement arrêtée. On pourrait également imaginer que l’initiative d’activer l’authentification forte des wallets eIDAS pour les paiements revienne non plus au titulaire du wallet (le payeur) mais à sa banque, à l’instar de ce qui se passe en Belgique avec ITSME, ce qui permettrait de limiter l’utilisation des wallets eIDAS aux situations réellement atypiques justifiant des précautions supplémentaires. C’est sans doute possible mais risque de beaucoup limiter l’intérêt des wallets eIDAS en les cantonnant à un simple rôle de moyen d’authentification par redirection. Bref, les jeux ne sont pas faits et les incertitudes demeurent.
Il y a aussi le malencontreux enregistrement obligatoire des parties utilisatrices de wallets eIDAS, qu’on ne retrouve nulle part ailleurs (tous les autres schémas d’identité numérique eIDAS en sont exemptés !) et qui met en place un régime encore plus contraignant que celui issu du RGPD avec enregistrement et notification préalable aux autorités des attributs demandés et de l’usage qui en sera fait. Disons-le franchement, une telle exigence mettant en place un régime de protection des données personnelles aussi dérogatoire risque de peser lourd dans les décisions d’acceptation des wallets eIDAS par les commerçants, dont l’immense majorité, à la différence des banques, n’a aucune obligation de les accepter.
Ajoutons que les textes eIDAS et DSP2/projet de RSP ne sont pas en cohérence sur des points clés. A titre d’exemple, on citera le fait que le règlement eIDAS indique que l’authentification forte est une fonctionnalité du wallet eIDAS qui s’impose aux banques alors que la DSP2 et le projet de RSP indique que c’est justement la banque du payeur (du titulaire du wallet eIDAS) qui définit la procédure d’autorisation du paiement par le payeur. On voit mal comment en pratique séparer les deux sujets et la logique voudrait que, puisque le wallet eIDAS doit assurer l’authentification forte des paiements, il définisse également les modalités de consentement au paiement et en fournisse la preuve vérifiable, laquelle sera évidemment communiquée au prestataire de services de paiement chargé de valider le paiement et d’assurer le transfert des fonds correspondants. Enfin, l’articulation des règles de responsabilité eIDAS et de la DSP2/RSP en cas de défaillance du mécanisme d’authentification forte du wallet eIDAS reste à définir.
On objectera que cette réconciliation devrait être assurée par l’autorité bancaire européenne dans le cadre de la préparation des futures normes techniques d’application du futur règlement sur les services de paiement – l’ABE a en effet pour mandat de tenir compte des wallets eIDAS dans leur préparation, mais celle-ci ne viendra que tardivement – sans doute pas avant 2027 – et ne pourra sans doute pas complètement remédier au décalage structurel entre les normes de premier niveau (règlement eIDAS et futur RSP) si celui-ci devait perdurer.
- Des spécifications techniques non stabilisées et un modèle français de wallet eIDAS encore à construire
On l’a dit, les wallets eIDAS feront utilisation du futur standard OID4VP (OpenID for Verifiable Presentations) pour les interactions digitales en ligne – les interactions de proximité feront de leur coté usage du standard ISO 18013-5 conçu pour les permis de conduire et dont l’application pour les interactions de paiement pose des problèmes aujourd’hui non résolus.
Ce standard OID4VP est encore en projet aujourd’hui mais représente clairement l’avenir lorsqu’il s’agit pour un titulaire de wallet eIDAS de présenter des attestations sécurisées en provenance de tiers qui peuvent ensuite être directement vérifiées par les parties utilisatrices auxquelles elles sont communiquées (en pratiques des Verifiable Credentials) . La logique de ces attestations est qu’elles concernent bien sûr le titulaire du wallet mais ne peuvent être modifiées par ce dernier (lequel, pour prendre un exemple parlant, n’a pas la faculté de se rajouter une mention à un diplôme d’université !).
Ce standard est de fait bien adapté à la présentation à des tiers d’attestations de moyens de paiement (IBAN ou cartes) émis par les établissements payeurs et qui seraient logées dans des wallets eIDAS. De telles attestations présentées par les bénéficiaires des paiements permettraient également de considérablement simplifier la vérification des bénéficiaires de paiements, exigence réglementaire issue du règlement sur les virements instantanés et qui sera étendue dans le cadre de la mise en place du prochain règlement sur les services de paiement.
Il présente toutefois deux difficultés distinctes dans une utilisation dans le cadre des paiements :
- La première concerne son incompatibilité avec les spécifications EMVCo qui régissent les interactions des paiements par cartes et sont très largement diffusées au sein des terminaux de paiement des commerçants, incompatibilité qui résulte de l’utilisation de procédés cryptographiques inhérents aux verifiable credentials – positive en elle-même mais nécessitant la gestion de données de taille nettement plus importante que celles gérées par les terminaux de paiement. Il y a donc un chantier significatif d’adaptation des infrastructures à mener ;
- La seconde concerne la gestion de l’authentification forte des paiements (dont on a vu qu’elle est indissociable de l’autorisation du paiement et suppose la création et mise en disponibilité d’un fichier de preuve vérifiable notamment par les prestataires de services de paiement). Il s’agit là de caractériser une action du titulaire du wallet lui-même – la décision d’autoriser un paiement sur la base d’informations de paiement intégrant le montant et le nom du bénéficiaire – et non plus de présenter une attestation d’un tiers concernant ledit titulaire. Force est toutefois de constater que ce sujet reste périphérique dans les spécifications des OID4VP. Il n’est pas complétement ignoré – les spécifications OID4VP prévoient bien de gérer des « données de transaction » liées aux présentations d’attestations vérifiables – mais sans vraiment spécifier les caractéristiques de ces données, alors que pour la mise en œuvre de l’authentification forte avec lien dynamique, la nécessité d’un cadre opérationnel très strict apparait nécessaire compte tenu des lourds enjeux de responsabilité qui en résultent.
Il serait pourtant techniquement adapté de sécuriser de telles données au moyen de signatures électroniques eIDAS car c’est justement la raison d’être de ces signatures que d’enregistrer des engagements à force probante, avec un fichier de preuve indiquant « qui a fait quoi à quel moment» et présentable lors de procédures judiciaires. Ce moyen est d’autant plus adapté que les wallets eIDAS doivent offrir à leur titulaire une fonctionnalité de signature électronique qualifiée assurant un niveau de sécurité élevé et une équivalence juridique à la signature manuscrite. Pourtant, tout indique qu’elles ne seront pas retenues pour la mise en œuvre du cas d’usage paiement dans le cadre du futur Payments Rulebook du document d’achitecture et de référence eIDAS (ARF document) en cours de préparation.
A ces interrogations déjà importantes s’ajoute, en France, l’incertitude liée à la mise en œuvre de la déclinaison française du wallet eIDAS. En effet, alors que l’architecture même des wallets eIDAS est d’assurer la gestion combinée dans une application unique des Personal Identification Data (PID) issus du secteur public (en clair, les données officielles d’identité émises par les pouvoirs publics) et des attestations électroniques d’attributs émises par des prestataires de services relevant du secteur privé, les responsables de France Titres en charge du projet ont exprimé le souhait assez net de limiter ces dernières au strict minimum, ce qui pourrait conduire à empêcher la gestion d’attestations vérifiables représentant des moyens de paiement du titulaire du wallet, et par extension, la mise en œuvre du cas d’usage paiement. Le contraste est saisissant avec l’approche poursuivie en Allemagne, basée sur une pluralité de wallets eIDAS publics et privés reconnus par le gouvernement allemand et un processus d’élaboration des spécifications techniques ouvert et compétitif.
En conclusion, si la promesse de l’identité numérique dans les paiements est à la fois réelle et très significative car elle ouvre vers un univers d’interactions numériques plus sécurisées et des services enrichis répondant mieux aux besoins des acteurs économiques, les difficultés et challenges pour y arriver ne manquent vraiment pas et conduisent à une vraie perplexité face à certain des choix opérés et des options retenues.
Dans ce contexte marqué par des incertitudes majeures, une approche plus spécifique aux paiements aurait été préférable et une chose apparaît clairement : l’échéance de mise en œuvre du cas d’usage paiement, fixée par le règlement eIDAS à décembre 2027 semble d’ores et déjà hors de portée.