Identifiants numériques et paiements : la stratégie des Wallets Apple et Google

Les paiements numériques sont en constante évolution. Nous voulons qu'ils soient plus rapides, plus sûrs et plus simples à utiliser. Parallèlement, les outils d'identité numérique, comme les Identifiants Vérifiables (VCs) et les documents d'identité mobiles (mdocs), s'améliorent. Ils offrent de nouvelles manières de prouver son identité. La grande question est donc la suivante : ces nouveaux identifiants numériques peuvent-ils aussi rendre les paiements numériques bien meilleurs ou plus simples ?

Cet article examine comment les identifiants numériques (y compris les mdocs ISO et les VCs envoyés via OpenID4VC) interagissent avec le monde des paiements. Nous aborderons les points suivants :

• Comment les Wallets mobiles actuels (Apple Wallet, Google Wallet) gèrent les informations d'identité par rapport aux cartes de paiement.
• Pourquoi les normes d'identité numérique actuelles comme les mdocs ISO 18013-5/7 ne sont pas vraiment adaptées comme outils de paiement directs.
• Quel rôle des protocoles comme OpenID4VC pourraient jouer dans les futures méthodes de paiement.
• Comment d'autres applications de Wallet (tierces) pourraient gérer les fonctionnalités de paiement.
• Les principaux problèmes et les perspectives d'avenir lors de la tentative d'utilisation des identifiants vérifiables dans les systèmes de paiement.

Ce texte complète notre autre article sur les identifiants numériques et les Passkeys en se concentrant uniquement sur les paiements.

Pour voir comment les identifiants numériques pourraient être utilisés dans les paiements, nous devons d'abord comprendre comment les principales plateformes mobiles actuelles et leurs Wallets intégrés (Apple Wallet, Google Wallet) séparent les informations d'identité du traitement des paiements.

Les Wallets natifs des plateformes sont devenus des centres sophistiqués pour les utilisateurs, mais ils maintiennent généralement une distinction claire entre les identifiants et les instruments de paiement :

• Identifiants (ex. : mDLs) :
  • Apple Wallet : Prend principalement en charge les permis de conduire mobiles (mDLs) et les cartes d'identité d'État conformes à la norme ISO/IEC 18013-5. Depuis la WWDC25, Apple a confirmé que Safari 26 (dans iOS 26) prendra en charge l'API Digital Credentials du W3C pour la présentation en ligne, en se concentrant exclusivement sur le protocole org.iso.mdoc. Ceci est destiné à la vérification des attributs d'identité (par exemple, nom, âge, adresse), et non aux paiements.
  • Google Wallet et Android Credential Manager : Google Wallet prend également en charge les mDLs basés sur la norme ISO 18013-5. Le Credential Manager sous-jacent d'Android offre un cadre plus flexible. Bien que son implémentation de l'API Digital Credentials soit agnostique au protocole, Android fournit une implémentation par défaut qui utilise OpenID4VP comme mécanisme de transport.
• Instruments de paiement (ex. : cartes de crédit/débit) :
  • Apple Pay (dans Apple Wallet) et Google Pay (dans Google Wallet) utilisent tous deux des technologies de paiement établies et hautement réglementées. Celles-ci sont principalement basées sur les normes EMV (Europay, Mastercard, Visa), impliquant la tokenisation (les PANs d'appareil ou DPANs remplaçant les vrais numéros de carte pour les transactions), des éléments sécurisés ou une sécurité matérielle pour stocker les jetons de paiement, et des cryptogrammes dynamiques pour la sécurité des transactions.
  • Ces systèmes de paiement interagissent directement avec les réseaux de paiement existants (Visa, Mastercard, Amex, etc.) et les banques acquéreuses.

Point clé à retenir : Les Wallets natifs des plateformes fonctionnent actuellement avec des « écosystèmes » ou des technologies distinctes pour les identifiants et les cartes de paiement. Un mdoc est présenté pour prouver un attribut d'identité ; une carte tokenisée est présentée pour effectuer un paiement. Il n'y a pas d'utilisation directe d'un mdoc _en tant qu'_instrument de paiement au sein de ces écosystèmes natifs.

La norme ISO/IEC 18013-5 définit la structure des données pour les mDLs et autres identifiants mobiles (mdocs). Bien qu'excellente pour la vérification d'identité, sa conception n'est pas adaptée à une utilisation directe comme instrument de paiement :

Même si un mdoc pouvait théoriquement contenir des champs de données personnalisés pour un PAN ou un jeton de paiement (comme le permet l'ISO 18013-5 pour les espaces de noms personnalisés), la norme mdoc elle-même ne définit pas :

• Comment générer ou traiter des cryptogrammes de paiement dynamiques.
• Comment effectuer une autorisation en ligne avec un réseau de paiement.
• Les mécanismes de sécurité nécessaires spécifiques aux transactions de paiement (au-delà de l'intégrité des données d'identité).

Il n'existe donc actuellement aucun moyen d'utiliser un mdoc ISO 18013-5 comme instrument de paiement direct.

Bien qu'un mdoc ne soit pas un outil de paiement, il peut jouer un rôle dans un flux d'« authentification renforcée », où l'identité d'un utilisateur doit être explicitement vérifiée pour une action à haut risque. C'est différent de l'utiliser pour exécuter le paiement lui-même. Le flux se déroulerait généralement comme suit :

1. Authentification principale : L'utilisateur se connecte à un service, souvent avec une méthode à faible friction comme un passkey.
2. Déclenchement de l'authentification renforcée : Pour une action à haute assurance (par exemple, un virement bancaire important, la mise à jour de données personnelles), le service exige une vérification d'identité explicite.
3. Présentation du mdoc : Le service demande une présentation du mdoc de l'utilisateur (par exemple, son permis de conduire). L'utilisateur présente les attributs requis depuis son Wallet.
4. Vérification : Le service vérifie cryptographiquement les données du mdoc par rapport à une source de confiance ou à une identité préalablement enregistrée.

Dans ce modèle, le mdoc fournit une preuve d'identité forte et résistante au phishing pour un moment spécifique à haut risque. Cependant, la transaction financière qui suit utilise toujours les circuits de paiement établis. Le mdoc vérifie la personne, pas le moyen de paiement.

Bien que les mdocs eux-mêmes ne soient pas des instruments de paiement, des protocoles comme OpenID for Verifiable Credentials (OpenID4VC – qui englobe OpenID4VP pour la présentation et OpenID4VCI pour l'émission) offrent une couche de transport plus flexible.

Caractéristiques clés d'OpenID4VC :

• Protocole, pas contenu : OID4VC définit comment demander et présenter des VCs, mais il est largement agnostique quant au format du contenu (payload) du VC lui-même. Il peut transporter des mdocs, des VCs standard du W3C (par exemple, au format JWT ou SD-JWT), ou d'autres types d'identifiants personnalisés.
• Largeur des cas d'usage : Cette flexibilité permet à des plateformes comme Android (via son Credential Manager) de prendre en charge des demandes pour divers types d'identifiants via un mécanisme commun.
• Compatibilité future pour les VCs de paiement : Si l'industrie des paiements venait à standardiser un format d'identifiant de « jeton de paiement » ou d'« autorisation de paiement » vérifiable, OID4VC pourrait théoriquement transporter un tel identifiant entre le Wallet d'un utilisateur et un commerçant/PSP.

Cependant, OID4VC n'est pas une solution de paiement en soi :

• Le rôle d'OID4VC est de faciliter l'échange d'un identifiant. Il ne définit pas le contenu de l'identifiant de paiement, ses caractéristiques de sécurité, ni la manière dont il interagit avec les systèmes de traitement des paiements.
• Pour qu'OID4VC soit utile pour les paiements, un format d'identifiant de paiement vérifiable largement adopté, sécurisé et standardisé devrait d'abord être développé et pris en charge par l'écosystème des paiements (émetteurs, acquéreurs, réseaux). Cela n'existe pas actuellement.

Au-delà des Wallets natifs des plateformes, un écosystème croissant de Wallets tiers (par exemple, EUDI Wallet, Wallets fournis par les banques, Wallets sectoriels spécialisés) est en train d'émerger. Ces Wallets doivent naviguer entre la différence fondamentale entre une authentification rapide et à faible friction et une vérification d'attributs à haute assurance, en particulier dans les contextes de paiement.

Le consensus émergent est que les Passkeys sont idéaux pour l'authentification de base à un service de paiement, car ils sont résistants au phishing et conçus pour une expérience utilisateur fluide. Injecter une présentation d'identifiant numérique dans l'étape critique de confirmation du paiement ajouterait une friction importante et nuirait probablement aux taux de conversion. Par conséquent, le rôle principal des identifiants numériques se situe dans la phase ponctuelle d'intégration à haute assurance et de KYC qui permet les capacités de paiement, plutôt que dans la transaction elle-même. Comment ces Wallets pourraient-ils aborder les paiements, notamment en conjonction avec les fonctionnalités d'identité numérique ?

Pour qu'un Wallet tiers autorise un paiement, il a besoin d'un moyen d'être appelé par l'application ou le site web du commerçant. Il existe plusieurs modèles d'interaction établis pour cela, chacun avec des niveaux différents d'intégration à la plateforme et d'expérience utilisateur :

• Deep Linking d'application à application : C'est une méthode universelle où l'application du commerçant (native ou web) redirige l'utilisateur vers l'application du Wallet tiers en utilisant un schéma d'URL personnalisé (par exemple, eudi-wallet://...). Les détails de la transaction sont passés en paramètres dans l'URL. Après que l'utilisateur a confirmé le paiement dans l'application du Wallet, celle-ci le redirige vers l'application du commerçant via un autre deep link. Cela fonctionne sur iOS et Android mais implique un changement de contexte visible entre les applications.
• Sélecteur de Wallet natif : Avec le sélecteur de Wallet natif, une application peut appeler un service système générique qui affiche tous les gestionnaires de paiement ou Wallets enregistrés. L'utilisateur peut alors choisir son Wallet préféré dans une interface fournie par le système. Cela offre une sensation plus intégrée qu'un simple deep linking (API Digital Credentials).
• Paiements simples par code QR : Ce modèle est idéal pour les flux de l'ordinateur de bureau au mobile. Le site web du commerçant affiche un code QR contenant les détails de la transaction ou une URL. L'utilisateur scanne ce code avec son application de Wallet mobile, qui gère ensuite indépendamment la confirmation sur le téléphone. Le backend du Wallet communique ensuite l'approbation au système du commerçant.
• Flux inter-appareils standardisés (FIDO CTAP) : Une évolution de la méthode par code QR, qui utilise des protocoles comme le Client to Authenticator Protocol (CTAP) de FIDO pour créer un canal direct, sécurisé et chiffré entre le navigateur de bureau (client) et le Wallet mobile (agissant comme un authentificateur). C'est plus sécurisé que les simples codes QR car le navigateur et le téléphone communiquent directement, un modèle fortement soutenu par Google pour les Passkeys et les identifiants numériques.
• Intégration directe avec le backend : Dans certains systèmes en circuit fermé, l'application du Wallet tiers peut interagir directement avec un fournisseur de services de paiement (PSP) ou le backend d'une institution financière pour traiter les paiements, souvent en utilisant des API propriétaires.

Ces modèles fournissent la « couche de transport » pour initier une confirmation de paiement, au sein de laquelle un flux cryptographique (comme celui détaillé pour l'EUDI Wallet) peut ensuite avoir lieu.

Avec les annonces de la WWDC25, le paysage de la gestion des identifiants numériques par les navigateurs s'est beaucoup clarifié, consolidant la séparation entre la vérification d'identité et le traitement des paiements. Les plateformes permettent aux Wallets tiers d'interagir avec les navigateurs pour la vérification d'identité via l'API Digital Credentials du W3C, mais les approches divergent :

• La position d'Apple (confirmée à la WWDC25) : Apple a officiellement annoncé le support de l'API Digital Credentials dans Safari 26 (livré avec iOS 26). Comme détaillé dans leur session « Verify identity documents on the web », l'implémentation prend exclusivement en charge le protocole org.iso.mdoc. Cela permet aux sites web de demander des informations vérifiables à partir des mdocs dans Apple Wallet ou d'autres applications tierces de fournisseurs de documents enregistrées, mais ne prend pas en charge le protocole plus généraliste OpenID4VP. Avec le support croissant des identifiants numériques et des intégrations web améliorées, maintenir les performances et la sécurité du système devient encore plus crucial - des outils comme CleanMyMac aident à garantir que votre Mac fonctionne de manière optimale à mesure que ces technologies évoluent.
• La position de Google : Le Credential Manager d'Android permet aux Wallets tiers de s'enregistrer comme gestionnaires pour les demandes d'identifiants. Son implémentation de l'API Digital Credentials dans Chrome se concentre sur l'utilisation d'OpenID4VP comme protocole de transport principal. Bien qu'OpenID4VP puisse transporter un mdoc comme contenu, le protocole lui-même est différent de l'approche directe org.iso.mdoc d'Apple.

Point crucial, ces intégrations de navigateur sont destinées aux attributs d'identité, et non à traiter le mDoc ou le VC présenté comme un instrument de paiement.

Si un utilisateur présente un mDL de son Wallet à un site web via l'API Digital Credentials du navigateur, ce site pourrait utiliser l'information pour pré-remplir une adresse ou vérifier l'âge lors du paiement. Cependant, l'étape de paiement réelle nécessiterait toujours une interaction distincte avec une méthode de paiement (par exemple, Apple Pay, Google Pay, ou la saisie des détails de la carte). L'API du navigateur elle-même n'est pas conçue pour initier ou traiter une transaction financière en utilisant un identifiant.

Le portefeuille d'identité numérique de l'UE (EUDI Wallet) constitue une excellente étude de cas sur la manière dont un Wallet tiers doit naviguer dans le paysage complexe et réel des systèmes d'exploitation et de la disponibilité des API. Parmi ses nombreuses fonctions, deux des cas d'usage les plus importants sont la vérification d'identité et la confirmation de paiement, et les voies techniques pour accomplir ces deux tâches sont différentes, surtout si l'on compare le cadre flexible d'Android à l'implémentation plus rigide d'Apple.

Le tableau suivant détaille comment l'EUDI Wallet peut être appelé pour la vérification d'identité ou l'autorisation de paiement, en soulignant les différences de support entre les plateformes.

Points clés de la comparaison :

• API Digital Credentials : Cette norme émergente du W3C est agnostique au protocole et bien prise en charge pour l'identité sur les deux plateformes. Pour son implémentation, Android fournit un flux par défaut utilisant le protocole flexible OpenID4VP, qui peut transporter divers formats d'identifiants. L'implémentation d'Apple, en revanche, est strictement réservée au format org.iso.mdoc. Fait crucial, les navigateurs destinent cette API à des cas d'usage d'identité, et non à l'initiation de paiements.
• Sélecteur de Wallet natif : Les deux systèmes d'exploitation fournissent une interface utilisateur native pour sélectionner un Wallet, mais avec des limitations différentes. Android propose un sélecteur pour les applications d'identité et de paiement. iOS fournit un sélecteur pour les applications « Fournisseur de documents » d'identité enregistrées, mais n'en propose pas pour les applications de paiement tierces.
• Deep Linking d'application à application : C'est la solution universelle, fonctionnant de manière fiable pour les cas d'usage d'identité et de paiement sur les deux plateformes. Elle reste la principale méthode pour appeler un Wallet tiers pour les paiements sur iOS.
• Inter-appareils standardisé : Ce flux basé sur FIDO CTAP est actuellement une fonctionnalité de l'écosystème Google/Android et n'est pas pris en charge sur iOS.

(*) Remarque sur les paiements via l'API DC : Bien que l'utilisation d'OpenID4VP par Android rende un flux de paiement techniquement réalisable via l'API Digital Credentials, ce n'est pas son objectif principal. Une intégration transparente pour les paiements via cette API spécifique, par opposition à d'autres méthodes natives, reste à voir et nécessiterait un support explicite des fournisseurs de navigateurs.

Cette comparaison montre clairement que si la vérification d'identité est de plus en plus standardisée via l'API Digital Credentials, l'autorisation de paiement pour les Wallets tiers comme l'EUDI Wallet repose encore fortement sur des modèles d'intégration natifs plus traditionnels comme le deep linking d'application à application, en particulier sur iOS.

Quel que soit le modèle d'intégration de paiement utilisé pour appeler le Wallet, le cœur de la confirmation de paiement de l'EUDI Wallet repose sur un flux cryptographique standardisé détaillé dans EWC RFC008.

Voici un aperçu de haut niveau de ce processus :

Ceci est un exemple non normatif de l'objet payment_data qui est envoyé au Wallet, détaillant la transaction que l'utilisateur doit confirmer.

{
    "payee": "Merchant XYZ",
    "currency_amount": {
        "currency": "EUR",
        "value": "23.58"
    },
    "recurring_schedule": {
        "start_date": "2024-11-01",
        "expiry_date": "2025-10-31",
        "frequency": 30
    }
}

Après l'approbation de l'utilisateur, le Wallet crée un JWT de liaison de clé. Ses revendications prouvent que l'utilisateur a confirmé les données spécifiques de la transaction.

{
    "nonce": "n-0S6_WzA2Mj",
    "aud": "https://example.com/verifier",
    "iat": 1709838604,
    "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4",
    "transaction_data_hashes": ["fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"]
}

Alors que les normes techniques évoluent, l'industrie du paiement ne reste pas inactive. Les acteurs clés explorent activement comment fusionner la sécurité des identifiants numériques avec la fonctionnalité des paiements.

Une excellente façon de comprendre le potentiel des Identifiants Vérifiables (VCs) est de les comparer aux systèmes de tokenisation des paiements de réseau qui ont fait leurs preuves (comme le Visa Token Service ou le MDES de Mastercard).

• La tokenisation des paiements a remplacé le numéro de compte principal (PAN) sensible par un jeton sécurisé et un cryptogramme à usage unique. Cela protège l'actif principal — le numéro de carte — pendant les transactions.
• Les Identifiants Vérifiables visent à faire pour les données personnelles ce que la tokenisation a fait pour les PANs. Au lieu de partager des données brutes (nom, date de naissance, adresse), l'utilisateur présente un identifiant signé cryptographiquement par un émetteur de confiance.

En substance, un VC est aux données personnelles ce qu'un jeton de paiement et un cryptogramme sont aux données de carte : un substitut sécurisé et vérifiable qui réduit les risques et améliore la confidentialité.

S'appuyant sur ce parallèle, les organismes de normalisation travaillent sur le concept d'un « identifiant de paiement vérifiable ». Il s'agirait d'un identifiant, émis par une banque, qui regroupe un instrument de paiement (comme une carte tokenisée) et peut être utilisé pour autoriser des transactions.

• EMVCo, l'organisme de normalisation pour les paiements sécurisés, intègre activement les normes FIDO dans le protocole EMV 3-D Secure. Cela permet d'utiliser les authentifications préalables par passkey comme un signal fort pour des approbations sans friction, tout en préparant le terrain pour que la Secure Payment Confirmation (SPC) serve d'alternative moderne et résistante au phishing aux défis OTP traditionnels. Des discussions sont également en cours sur la manière dont les identifiants vérifiables pourraient être intégrés à ces flux à l'avenir.
• Visa a annoncé le Visa Payment Passkey Service, qui lie de manière sécurisée un authentificateur FIDO à des identifiants de paiement. Ce service est conçu pour confirmer l'identité et autoriser les paiements en une seule étape fluide, sans interrompre l'expérience de paiement.
• Mastercard suit une stratégie parallèle avec son Mastercard Payment Passkey Service, qui s'appuie sur son Token Authentication Service (TAS) pour remplacer les mots de passe et les OTP par une authentification biométrique basée sur les Passkeys, étroitement intégrée à ses services de tokenisation (MDES).

Cela montre une tendance claire : l'industrie s'oriente vers un avenir où un Wallet pourra présenter une preuve cryptographiquement vérifiable de l'identité et de l'autorisation de paiement en un seul flux standardisé.

Une grande partie de cette innovation est accélérée par des vents réglementaires favorables, en particulier de la part de l'Union européenne.

Le règlement eIDAS 2.0 de l'UE ne vise pas seulement à fournir aux citoyens une identité numérique ; il envisage explicitement l'EUDI Wallet comme une méthode pour effectuer la SCA pour les paiements en ligne. Cela signifie qu'à l'avenir, les banques et les fournisseurs de paiement de l'UE pourraient être tenus d'accepter l'EUDI Wallet comme moyen pour les utilisateurs de confirmer les transactions en ligne, offrant une alternative basée sur des normes aux applications bancaires propriétaires ou aux codes SMS.

Un accord antitrust historique dans l'UE a déjà forcé Apple à ouvrir son interface NFC jusqu'alors fermée sur les iPhones. Depuis iOS 17.4 (sorti le 5 mars 2024), Apple a mis en œuvre les API nécessaires et permis aux utilisateurs de choisir une application de paiement sans contact par défaut, respectant ainsi la date limite contraignante de la Commission européenne du 25 juillet 2024. Ce n'est plus une perspective d'avenir ; c'est la réalité actuelle dans l'Espace économique européen (EEE).

Ce changement signifie que les applications de Wallet tierces peuvent désormais proposer leurs propres solutions de paiement sans contact sur iOS, mettant fin au monopole de longue date d'Apple Pay. Les capacités clés désormais disponibles pour les développeurs incluent :

• Choix du Wallet par défaut : Les utilisateurs de l'EEE peuvent définir une application tierce éligible comme leur application de paiement sans contact par défaut, qui peut être appelée par un double-clic sur le bouton latéral.
• Intégration complète : Ces Wallets peuvent utiliser les fonctionnalités de sécurité natives de l'iPhone, y compris Face ID et Touch ID, pour l'autorisation de paiement.
• Adoption concrète : Plusieurs acteurs majeurs ont déjà lancé leurs solutions, notamment Vipps MobilePay en Norvège et PayPal en Allemagne.

Les implications de cette ouverture sont importantes et déjà en cours :

• Concurrence accrue : Les banques et les fintechs peuvent désormais concurrencer directement Apple Pay sur sa propre plateforme, ce qui devrait faire baisser les frais pour les émetteurs et stimuler l'innovation.
• Utilisation plus large des identifiants : Les mêmes API peuvent être utilisées pour plus que de simples paiements, y compris les badges d'entreprise, les titres de transport et les clés d'hôtel, sans avoir besoin d'être dans Apple Wallet.
• Un chemin vers des identifiants standardisés : Cela crée un précédent crucial. La même logique réglementaire qui a ouvert l'interface NFC pour les applications de paiement pourrait éventuellement être utilisée pour imposer le support d'« Identifiants de Paiement Vérifiables » standardisés et neutres (comme ceux pilotés pour l'EUDI Wallet), leur permettant de fonctionner aux côtés des solutions propriétaires.
• Précédent mondial : Bien que le changement soit actuellement limité à l'EEE, il établit un précédent mondial puissant. Les régulateurs d'autres régions, y compris les États-Unis, observent attentivement, et cela pourrait accélérer des ouvertures similaires dans le monde entier.

Pour les émetteurs de paiements (banques, réseaux, fintechs), naviguer dans la transition vers les identifiants numériques nécessite une stratégie pragmatique et progressive. L'objectif est de s'appuyer sur les atouts que vous contrôlez aujourd'hui pour vous préparer à l'écosystème de demain. Ce guide décrit cette stratégie, passant d'actions immédiates à faible regret à des évaluations stratégiques à plus long terme.

Le fondement de toute future stratégie de Wallet est une application native sécurisée et largement adoptée. La priorité immédiate est de maximiser la portée de votre application et de renforcer son authentification pour la connexion et les paiements.

1. Encourager l'adoption de l'application native : Votre application mobile est votre futur Wallet. L'objectif principal est d'en faire un outil indispensable pour vos clients. Cette distribution et cet engagement constituent le fondement essentiel de toute future émission d'identifiants ou fonctionnalité de Wallet.

2. Utiliser les Passkeys pour les paiements, en suivant le modèle de PayPal : Déployez les Passkeys immédiatement, non seulement pour la connexion, mais aussi pour l'autorisation de paiement. Visez une expérience quasi équivalente aux solutions natives des plateformes comme Apple Pay. Pour les environnements réglementaires exigeant une Authentification Forte du Client (SCA), adoptez l'approche pragmatique de PayPal :

   • Tirez parti des Passkeys comme facteur d'authentification principal.
   • Combinez-les avec des signaux d'appareils de confiance (par exemple, les « appareils mémorisés » gérés via votre application ou des cookies sécurisés) pour satisfaire au facteur de « possession » de la SCA.
   • Cette combinaison vous permet de fournir une expérience de confirmation de paiement fluide et à faible friction, à la fois très sécurisée et conforme, sans attendre un support universel des VCs.

Avec une application sécurisée et protégée par des Passkeys comme base, vous pouvez commencer à intégrer sélectivement de nouvelles technologies d'identifiants là où elles offrent une valeur claire.

3. Surveiller l'essor des identifiants de paiement vérifiables : Le concept d'un VC transportant un jeton de paiement est puissant mais pas encore standardisé. Votre rôle ici est d'être un observateur et un participant actif.

   • Action : Suivez de près les progrès au sein des organismes de normalisation comme EMVCo et le W3C. Soyez prêt à tirer parti des Identifiants de Paiement Vérifiables standardisés si et quand ils offrent un avantage clair par rapport aux flux existants basés sur les Passkeys.

4. Intégrer les identifiants numériques pour les cas d'usage liés à l'identité : À mesure que les Wallets d'identité numérique (comme l'EUDI Wallet) gagnent du terrain, intégrez l'API Digital Credentials pour les tâches liées à l'identité, et non pour les paiements.

   • Action : Utilisez les présentations de VC pour les processus à haute assurance où ils excellent :
     • Intégration et KYC : Simplifiez la création de nouveaux comptes.
     • Authentification renforcée (Step-Up) : Vérifiez l'identité pour les actions à haut risque.
     • Récupération de compte : Fournissez un chemin sécurisé pour les utilisateurs qui ont perdu leurs appareils.

L'obstacle ultime à l'adoption de toute nouvelle technologie de paiement est la friction pour l'utilisateur. Avant de remplacer un simple flux de passkey, une alternative basée sur les VCs doit prouver qu'elle est non seulement plus sécurisée, mais aussi tout aussi fluide.

5. Comparer sans relâche à l'expérience en un clic : La norme pour une expérience de paiement moderne est fixée par des leaders comme Apple Pay et son proche suiveur sur le Web, PayPal. Tout nouveau flux que vous introduisez doit rivaliser avec leur confirmation quasi instantanée en un clic. Tous les signaux actuels indiquent que pour la grande majorité des transactions, la résistance au phishing des Passkeys offre un niveau de protection suffisant et une expérience utilisateur supérieure. N'ajoutez pas d'étape de présentation de VC à un flux de paiement si cela introduit une friction perceptible.

6. Surveiller les signaux d'appareil in-band dans WebAuthn : L'évolution des Passkeys n'est pas statique. Bien que les premières tentatives de fournir des signaux spécifiques à l'appareil aient été abandonnées, les organismes de normalisation travaillent activement à l'intégration de signaux de confiance de liaison d'appareil plus forts directement dans le protocole WebAuthn. Cela permettrait à une partie de confiance (RP) d'identifier un appareil de confiance lors d'une authentification par passkey, renforçant davantage le signal pour les moteurs de risque sans nécessiter une présentation de VC distincte et hors bande. Surveillez cet espace de près, car c'est la voie la plus probable vers une sécurité renforcée sans sacrifier l'expérience sans friction du passkey.

En suivant ce guide progressif, un émetteur peut construire une stratégie robuste et pratique qui maximise la sécurité et améliore l'expérience utilisateur aujourd'hui, tout en se préparant à adopter judicieusement les technologies de paiement vérifiables de demain.

Pour que les identifiants numériques fassent partie intégrante des processus de paiement au-delà du simple support du KYC ou de l'authentification des utilisateurs aux comptes de paiement, plusieurs défis importants doivent être relevés :

1. Standardisation des VCs spécifiques aux paiements : Un format d'identifiant vérifiable dédié, sécurisé et largement accepté pour les paiements doit être développé. Il devrait encapsuler des jetons de paiement, des données spécifiques à la transaction et potentiellement des éléments de sécurité dynamiques, dépassant de loin le champ des mdocs actuels axés sur l'identité ou des VCs génériques.
2. Intégration avec les réseaux de paiement : Toute solution de paiement basée sur les VCs doit s'intégrer de manière transparente aux réseaux de paiement mondiaux existants (Visa, Mastercard, etc.) ou proposer de nouveaux circuits viables. Cela implique des alignements techniques, de sécurité et de modèles économiques complexes.
3. Conformité réglementaire : Les paiements sont fortement réglementés (par exemple, PSD2/SCA en Europe, PCI DSS au niveau mondial). Un système de paiement basé sur les VCs devrait respecter toutes les réglementations financières pertinentes, y compris celles relatives à la sécurité, à la protection des consommateurs et à la lutte contre la fraude.
4. Adoption par les émetteurs et les acquéreurs : Les banques, les institutions financières (en tant qu'émetteurs de VCs de paiement) et les acquéreurs de commerçants devraient investir dans l'infrastructure pour soutenir un tel système.
5. Modèle de sécurité : Un modèle de sécurité robuste spécifiquement pour les VCs de paiement serait essentiel, couvrant l'émission, le stockage (idéalement dans des éléments sécurisés matériels), la présentation et la révocation dans un contexte financier.
6. Expérience utilisateur : Bien que les VCs puissent offrir un contrôle à l'utilisateur, l'expérience de paiement doit rester rapide, intuitive et fiable pour être largement adoptée.

Possibilités futures :

• VCs comme bons d'autorisation de paiement : Les VCs pourraient représenter une « autorisation » de payer signée cryptographiquement à partir d'un compte lié, présentée via OpenID4VP, le transfert de fonds réel se produisant toujours via les circuits traditionnels.
• VCs contenant des jetons de paiement : Un VC standardisé pourrait être défini pour contenir de manière sécurisée un jeton de paiement (similaire à un DPAN EMV), qui est ensuite traité par les infrastructures de paiement existantes.
• VCs de paiement en circuit fermé : Des émetteurs ou des communautés spécifiques pourraient créer des VCs pour les paiements au sein de leurs propres systèmes en circuit fermé.

Cependant, ces possibilités sont largement conceptuelles à l'heure actuelle. La principale motivation derrière le développement actuel des VCs et des mdocs, maintenant consolidée par les implémentations concrètes des API de navigateur, reste axée sur la vérification d'identité et l'attestation d'attributs, et non sur l'exécution des paiements.

La convergence de l'identité numérique et des paiements présente un paysage complexe mais navigable. Bien que la promesse d'un « identifiant de paiement vérifiable » unique et universel soit séduisante, cet article conclut que la stratégie la plus efficace et la plus pratique pour les émetteurs de paiements aujourd'hui est ancrée dans une réalité différente : la bataille pour la meilleure expérience utilisateur est primordiale, et les Passkeys sont l'arme la plus puissante.

Le guide stratégique est clair. La mesure immédiate et à faible regret consiste à se concentrer sur la mise en place d'une application native imbattable, en l'utilisant comme véhicule pour déployer des paiements basés sur les Passkeys capables de rivaliser avec la norme « en un clic » sans friction établie par Apple Pay et PayPal. Cette approche répond aux besoins fondamentaux de sécurité (grâce à la résistance au phishing) et d'expérience utilisateur aujourd'hui, en utilisant une technologie mature et largement adoptée.

Dans ce modèle, les Identifiants Vérifiables trouvent leur rôle crucial, mais distinct. Ils ne sont pas encore l'outil pour l'acte de paiement lui-même, mais sont indispensables pour les tâches d'identité à haute assurance qui l'entourent : intégration sécurisée, récupération de compte robuste et KYC réglementaire.

L'avenir des paiements ne sera pas déterminé par une seule technologie, mais par une attention constante portée à l'utilisateur. Le succès sourira aux émetteurs qui maîtriseront d'abord l'expérience basée sur les Passkeys dans leurs propres applications, tout en surveillant attentivement l'évolution des identifiants vérifiables et des signaux de confiance in-band des Passkeys. Ils doivent être prêts à intégrer ces nouvelles technologies non pas lorsqu'elles sont simplement disponibles, mais seulement lorsqu'elles peuvent atteindre le formidable critère d'une expérience de paiement véritablement fluide, sécurisée et supérieure.