Serveur de contrôle d'accès EMV 3DS : Passkeys, FIDO et SPC

Le paysage de l'authentification des paiements en ligne connaît une transformation majeure, motivée par le double besoin de renforcer la sécurité contre les fraudes sophistiquées et d'améliorer l'expérience utilisateur pour réduire les frictions et l'abandon de panier. Le protocole EMV® 3-D Secure (3DS), en particulier ses dernières versions (EMV 3DS 2.x), sert de technologie fondamentale pour authentifier les transactions carte non présente (CNP) à l'échelle mondiale. Géré par EMVCo, ce protocole facilite l'échange de données entre les commerçants, les émetteurs (via leur serveur de contrôle d'accès - ACS) et le domaine d'interopérabilité (serveurs d'annuaire opérés par les schémas de paiement) pour vérifier l'identité du titulaire de la carte.

Dans ce cadre, deux avancées technologiques clés liées aux standards de l'Alliance FIDO (Fast Identity Online) émergent :

1. L'utilisation des données d'authentification FIDO générées lors d'interactions utilisateur antérieures (par exemple, la connexion chez un commerçant) pour enrichir l'évaluation des risques pour le flux sans friction EMV 3DS.
2. L'intégration de la Secure Payment Confirmation (SPC), un standard web du W3C basé sur FIDO/WebAuthn, comme méthode de « challenge » simplifiée et résistante au phishing au sein du flux EMV 3DS.

Cet article offre un aperçu du marché mondial des solutions de serveur de contrôle d'accès (ACS) EMV 3DS fournies aux banques émettrices. Il identifie les principaux fournisseurs et tente d'évaluer leur support actuel pour les structures de données FIDO non-SPC et la Secure Payment Confirmation (SPC) pour les flux avec challenge. De plus, il clarifie le mécanisme par lequel les émetteurs peuvent utiliser leurs propres passkeys FIDO pour une vérification cryptographique dans le flux de challenge 3DS via la SPC et discute de l'applicabilité mondiale de ce standard.

EMV 3DS fonctionne principalement via deux parcours d'authentification distincts :

• Flux sans friction : C'est le parcours privilégié, visant une expérience utilisateur transparente. L'ACS de l'émetteur effectue une évaluation des risques basée sur un riche ensemble de données échangées lors de l'initiation de la transaction (via la requête d'authentification, ou message AReq). Ces données incluent les détails de la transaction, les informations sur le commerçant, les caractéristiques de l'appareil, les données du navigateur (potentiellement collectées via le JavaScript 3DSMethod) et éventuellement des informations d'authentification antérieures. Si le risque est jugé faible, la transaction est authentifiée sans nécessiter d'interaction directe ou de « challenge » de la part du titulaire de la carte. Ce flux représente la majorité des transactions 3DS, en particulier lorsque les moteurs de risque sont bien réglés.
• Flux avec challenge : Si l'ACS détermine que le risque de la transaction est élevé, si cela est imposé par la réglementation (comme la DSP2 SCA en Europe) ou la politique de l'émetteur, le titulaire de la carte est activement mis au défi de vérifier son identité. Les méthodes de challenge traditionnelles incluent les mots de passe à usage unique (OTP) envoyés par SMS, les questions basées sur la connaissance ou l'authentification hors bande (OOB) via une application bancaire. L'objectif des nouvelles versions de 3DS et des technologies associées comme la SPC est de rendre ce flux avec challenge plus sécurisé et moins contraignant que les méthodes héritées.

EMVCo et l'Alliance FIDO ont collaboré pour définir une manière standardisée pour les commerçants de transmettre des informations sur les authentifications FIDO antérieures (où le commerçant a agi en tant que Relying Party, par exemple, lors de la connexion de l'utilisateur) à l'ACS de l'émetteur dans le message AReq 3DS standard. Ce mécanisme, pris en charge pour la première fois dans EMV 3DS v2.1, utilise des champs spécifiques dans l'AReq, principalement la structure threeDSRequestorAuthenticationInfo, qui contient des sous-champs comme threeDSRequestorAuthenticationData.

La note technique de l'Alliance FIDO et le livre blanc d'EMVCo associé spécifient une structure JSON pour ce champ threeDSRequestorAuthenticationData lors de la transmission des détails d'une authentification FIDO antérieure. Cet objet JSON inclut des détails tels que l'heure d'authentification (authTime), l'ID du Relying Party FIDO (rpId ou appId), et des informations sur le ou les authentificateurs utilisés, y compris la clé publique, l'AAGUID/AAID, et des indicateurs de présence de l'utilisateur (UP) et de vérification de l'utilisateur (UV).

La logique est que si un commerçant a récemment effectué une authentification FIDO forte (par exemple, en utilisant la biométrie ou un passkey) pour la session utilisateur initiant l'achat, cette information peut servir de signal de risque supplémentaire précieux pour l'ACS de l'émetteur. En recevant et en traitant ces données FIDO standardisées, l'ACS peut potentiellement avoir une plus grande confiance dans la légitimité de la transaction, augmentant la probabilité d'une approbation sans friction et réduisant le besoin d'un challenge séparé. Il est important de noter que dans ce scénario, le commerçant est le RP FIDO, et l'émetteur consomme ces données comme une entrée pour son moteur de risque ; l'émetteur ne vérifie pas cryptographiquement l'assertion FIDO elle-même dans ce flux sans friction. L'ACS conserve la possibilité d'ignorer ces données s'il n'est pas configuré pour les traiter.

La Secure Payment Confirmation (SPC) représente une intégration distincte des standards FIDO au sein du flux avec challenge EMV 3DS. La SPC est un standard web du W3C, développé en collaboration avec FIDO et EMVCo, et basé sur WebAuthn. Elle est formellement prise en charge dans EMV 3DS à partir de la version 2.3.

Lorsque la SPC est utilisée comme méthode de challenge :

1. L'émetteur (ou une partie explicitement déléguée par l'émetteur, comme un schéma de paiement) agit en tant que Relying Party FIDO (RP). C'est fondamentalement différent du flux de données FIDO hors SPC décrit précédemment, où le commerçant agit généralement comme le RP pour ses propres besoins de connexion/authentification.
2. Pendant le challenge 3DS, l'ACS signale le besoin d'une SPC et fournit les identifiants de credential FIDO nécessaires ainsi qu'un challenge cryptographique au commerçant/serveur 3DS.
3. Le système du commerçant invoque l'API SPC du navigateur, présentant les détails de la transaction (montant, devise, bénéficiaire, instrument) à l'utilisateur dans une boîte de dialogue sécurisée contrôlée par le navigateur.
4. L'utilisateur s'authentifie à l'aide de son authentificateur FIDO (par exemple, biométrie de l'appareil, PIN, clé de sécurité), qui signe les détails de la transaction et le challenge en utilisant la clé privée associée au passkey enregistré par l'émetteur.
5. L'assertion FIDO résultante (preuve cryptographique d'authentification et de consentement) est renvoyée via le protocole 3DS (généralement via un second message AReq) à l'ACS de l'émetteur.
6. L'ACS, en tant que RP, valide cryptographiquement l'assertion en utilisant la clé publique correspondante, confirmant l'identité du titulaire de la carte et son consentement aux détails spécifiques de la transaction.

La SPC vise à fournir une expérience de challenge qui est à la fois plus sécurisée (résistante au phishing, liaison dynamique de l'authentification aux données de la transaction) et potentiellement moins frictionnelle (souvent plus rapide que la saisie d'un OTP) par rapport aux méthodes traditionnelles.

Les deux voies d'intégration FIDO — l'une exploitant les données d'authentification antérieures du commerçant pour l'évaluation des risques sans friction, l'autre utilisant des credentials gérés par l'émetteur pour un challenge direct basé sur FIDO via la SPC — offrent des approches distinctes pour améliorer la sécurité et l'expérience utilisateur dans le cadre d'EMV 3DS. Comprendre le support des fournisseurs pour chacune est crucial pour les émetteurs et les PSP qui planifient leurs stratégies d'authentification.

Cette section analyse les capacités des fournisseurs mondiaux de solutions ACS EMV 3DS, en se concentrant sur leur présence sur le marché et leur support pour les données FIDO (hors SPC) et la Secure Payment Confirmation (SPC). Les chiffres précis de part de marché sont propriétaires et difficiles à obtenir publiquement ; par conséquent, la présence est évaluée sur la base des déclarations des fournisseurs, des certifications, des partenariats, de la portée géographique et des rapports de marché.

• Présence sur le marché : Entersekt, en particulier après son acquisition de l'activité logicielle 3DS de Modirum en décembre 2023, se positionne comme un fournisseur mondial de premier plan de solutions EMV 3DS, visant une position dans le top cinq du marché. Modirum avait plus de 20 ans d'expérience en 3DS. Entersekt met en avant une croissance record tirée par de nouveaux clients, notamment en Amérique du Nord, et des partenariats stratégiques, y compris une relation élargie avec Mastercard. Ils affirment sécuriser plus de 2,5 milliards de transactions par an (pour l'exercice 24) et sont classés n°1 dans la prévention de la prise de contrôle de compte (ATO) dans le secteur bancaire par Liminal. Leur ACS est disponible en mode hébergé (par Entersekt ou le client) ou sur site. Ils servent des émetteurs et des processeurs dans le monde entier.
• Support des données FIDO hors SPC (sans friction) : Entersekt met l'accent sur son authentification Context Aware™, l'analyse comportementale et de l'appareil pour les signaux de risque, et l'intégration avec divers services de notation de risque. Leur ACS est certifié FIDO EMVCo 2.2. Bien qu'ils soulignent l'exploitation des données de risque et d'intelligence comportementale pour la RBA, la confirmation explicite du traitement des données d'attestation FIDO standardisées provenant d'authentifications antérieures du commerçant dans le champ threeDSRequestorAuthenticationInfo pour l'amélioration du flux sans friction n'est pas explicitement mentionnée dans les documents en ligne. Cependant, leur concentration sur l'authentification avancée et les signaux de risque suggère cette capacité.
• Support de la SPC (Challenge) : De forts indicateurs suggèrent qu'Entersekt supporte la SPC. Modirum, dont Entersekt a acquis l'activité 3DS, a fourni des composants pour le projet pilote SPC de Visa utilisant 3DS 2.2 avec des extensions. Entersekt liste explicitement le support de la conformité SPC dans le cadre de ses capacités de conformité réglementaire. Leur ACS prend en charge l'authentification biométrique, est certifié pour EMV 3DS 2.2, et intègre probablement les capacités issues de la participation de Modirum au projet pilote. La combinaison de l'acquisition de Modirum, de la mention explicite de la conformité SPC et de la certification FIDO indique fortement un support de la SPC dans leur offre actuelle.

• Présence sur le marché : Arcot de Broadcom est un acteur fondamental du marché 3DS, ayant co-inventé le protocole original avec Visa. Ils se positionnent comme un leader mondial reconnu, servant plus de 5 000 institutions financières dans le monde et traitant des transactions de 229 pays. Leur réseau Arcot met l'accent sur une vaste approche de données de consortium (revendiquant plus de 600 millions de signatures d'appareils, 150 trillions de points de données) pour alimenter leurs moteurs de notation de fraude et de risque. Ils ont une forte présence en Europe, en Australie et en Amérique du Nord.
• Support des données FIDO hors SPC (sans friction) : Broadcom met fortement l'accent sur la richesse de son réseau de données et l'utilisation de l'IA/réseaux neuronaux pour la détection de la fraude et l'évaluation basée sur le risque, allant au-delà des éléments de données EMV 3DS standard. Ils déclarent explicitement que leur solution exploite les données circulant à travers plusieurs émetteurs et intègre des données numériques comme l'appareil et la géolocalisation. Bien qu'ils ne mentionnent pas explicitement le traitement de la structure JSON FIDO spécifique de threeDSRequestorAuthenticationData, leur concentration sur l'ingestion de divers points de données pour la RBA suggère fortement qu'ils pourraient consommer de telles données si elles étaient fournies, conformément à l'intention des directives EMVCo/FIDO. Leur plateforme vise à maximiser les approbations sans friction grâce à une évaluation des risques supérieure.
• Support de la SPC (Challenge) : La documentation de Broadcom confirme le support des authentificateurs FIDO (clé de sécurité, biométrie, Passkey) au sein de leur suite plus large VIP Authentication Hub / Identity Security. Leur ACS 3DS prend en charge diverses méthodes de challenge, y compris les OTP et les notifications push, et ils mentionnent le support de la biométrie. Ils offrent également des capacités d'authentification déléguée et ont introduit des fonctionnalités d'évaluation des risques post-challenge. Cependant, la confirmation explicite que leur produit ACS EMV 3DS prend actuellement en charge la SPC comme méthode de challenge spécifique (nécessitant des capacités EMV 3DS v2.3+ et le flux à deux AReq) est absente de la documentation fournie. Bien qu'ils soient un acteur majeur probablement capable de l'implémenter, le matériel public actuel se concentre davantage sur leur moteur RBA et les méthodes de challenge traditionnelles/OOB.

• Présence sur le marché : Netcetera se positionne comme un acteur international majeur du paiement, particulièrement fort en Europe et au Moyen-Orient. Ils déclarent que leur ACS est utilisé par plus de 800 banques/émetteurs, sécurisant plus de 50 millions de cartes dans le monde. Ils mettent en avant les certifications avec tous les principaux réseaux de cartes (Visa, Mastercard, Amex, Discover, JCB, UnionPay, etc.) et la conformité PCI. Ils ont été notamment le premier fournisseur d'ACS au monde à obtenir la certification EMV 3DS 2.3.1.
• Support des données FIDO hors SPC (sans friction) : La documentation de Netcetera souligne l'importance des données collectées via la 3DSMethod pour l'évaluation des risques de l'ACS afin d'augmenter l'authentification sans friction. Ils proposent une intégration avec des outils de risque. Cependant, la confirmation spécifique du traitement des données d'authentification FIDO antérieures du commerçant (de threeDSRequestorAuthenticationInfo) pour l'évaluation des risques n'est pas explicitement mentionnée dans les documents examinés.
• Support de la SPC (Challenge) : Netcetera démontre un fort soutien pour la SPC. Ils ont été le premier fournisseur au monde certifié pour EMV 3DS 2.3.1, la version intégrant la SPC. Ils ont participé au projet pilote SPC de Visa, fournissant les composants v2.3.1. La documentation de leur produit définit explicitement la SPC. Ils ont organisé des webinaires discutant de l'intégration de FIDO et de la SPC et publié des articles soulignant les avantages de la SPC. Cette combinaison de certification, de participation à un projet pilote et de documentation explicite confirme leur support pour les challenges SPC.

• Présence sur le marché : Worldline se positionne comme le leader européen des services de paiement et de transaction et un acteur mondial majeur (revendiquant le statut de 4ème acteur mondial du paiement). Ils traitent des milliards de transactions par an et mettent l'accent sur la conformité garantie, le contrôle de la fraude à l'aide de l'IA/ML et la scalabilité. Leur ACS est déclaré être certifié EMV 3DS et conforme aux principaux schémas (Visa Secure, Mastercard Identity Check) et à la DSP2. Ils rapportent traiter plus de 2,4 milliards de transactions 3DS par an pour plus de 100 émetteurs.
• Support des données FIDO hors SPC (sans friction) : L'offre ACS de Worldline comprend un moteur de règles RBA permettant aux émetteurs de configurer des flux sans friction ou avec challenge en fonction du risque. Leur solution plus large « Trusted Authentication » exploite l'intelligence des appareils et l'analyse comportementale. Bien qu'ils supportent FIDO de manière générale, la confirmation explicite du traitement des données FIDO antérieures du commerçant (hors SPC) au sein de l'ACS pour l'évaluation des risques n'est pas détaillée dans les extraits fournis.
• Support de la SPC (Challenge) : Worldline montre des indications claires de support pour la SPC. Leur documentation reconnaît l'évolution d'EMV 3DS 2.3 pour inclure SPC/FIDO. Ils commercialisent explicitement leur solution « WL Trusted Authentication » comme supportant l'authentification FIDO et proposent un « WL FIDO Server » adapté aux « cas d'usage 3DS, avec emvCO2.3 et SPC ».

• Présence sur le marché : GPayments positionne ActiveAccess comme une « plateforme de serveur de contrôle d'accès (ACS) robuste et leader du marché » avec plus de 20 ans d'expérience dans l'espace 3D Secure. Ils sont certifiés avec les principaux schémas de cartes (Visa Secure, Mastercard Identity Check, JCB J/Secure) pour 3DS1 et EMV 3DS. Leur solution peut être déployée sur site ou hébergée dans le cloud. Les rapports de marché identifient GPayments comme un acteur notable offrant des solutions ACS.
• Support des données FIDO hors SPC (sans friction) : ActiveAccess prend en charge l'intégration avec des solutions RBA tierces et utilise divers paramètres pour sa propre évaluation des risques. Cependant, la documentation fournie ne mentionne pas explicitement le support pour l'ingestion ou l'utilisation des données d'authentification FIDO antérieures du commerçant (hors SPC) pour l'évaluation des risques sans friction.
• Support de la SPC (Challenge) : La documentation examinée pour ActiveAccess ne mentionne pas explicitement le support de la Secure Payment Confirmation (SPC), des challenges WebAuthn ou des challenges FIDO dans le cadre de ses capacités de flux avec challenge. Bien qu'ils prennent en charge diverses méthodes d'authentification, y compris l'OOB (qui peut inclure la biométrie), le support spécifique de la SPC n'est pas clair d'après les informations disponibles.

• Présence sur le marché : Visa, en tant que réseau de paiement mondial majeur, définit le programme Visa Secure basé sur le standard EMV 3DS. Ils ont été les pionniers du protocole 3DS original. Plutôt que d'agir principalement comme un fournisseur direct d'ACS de la même manière que des entreprises technologiques comme Entersekt ou Broadcom, Visa gère le programme et s'appuie sur une liste de fournisseurs 3DS approuvés (y compris les fournisseurs d'ACS) dont les produits sont certifiés conformes à EMV 3DS et aux règles Visa Secure. Les émetteurs se procurent généralement des solutions ACS auprès de ces fournisseurs certifiés. Visa se concentre sur le réseau (serveur d'annuaire), la définition des règles du programme, la promotion de l'adoption et la stimulation de l'innovation comme les pilotes SPC.
• Support des données FIDO hors SPC (sans friction) : Visa Secure, basé sur EMV 3DS, prend intrinsèquement en charge l'échange de données riches pour l'évaluation des risques afin de permettre un flux sans friction. Le cadre EMVCo/FIDO pour la transmission des données FIDO antérieures fonctionne au sein de l'écosystème Visa Secure si le fournisseur d'ACS choisi prend en charge son traitement.
• Support de la SPC (Challenge) : Visa est activement impliqué dans le pilotage et la promotion de la SPC. Ils travaillent avec des partenaires (comme Netcetera et Modirum/Entersekt dans les pilotes) pour tester et affiner le flux SPC au sein du protocole 3DS. Cet engagement fort indique un soutien stratégique pour la SPC comme méthode de challenge au sein du programme Visa Secure, sous réserve de la préparation de l'écosystème (support de l'ACS, du commerçant, du navigateur).

• Présence sur le marché : Similaire à Visa, Mastercard gère le programme Mastercard Identity Check basé sur EMV 3DS. Ils offrent des options aux émetteurs et aux commerçants, y compris le traitement de secours (stand-in) et potentiellement l'utilisation de partenaires ou de filiales comme NuData. Mastercard a acquis NuData Security, une société de biométrie comportementale, en 2017, améliorant ainsi ses capacités d'évaluation des risques. Ils mettent également l'accent sur l'innovation continue en matière de biométrie, de RBA et d'IA. Comme Visa, ils s'appuient sur des fournisseurs certifiés pour les composants ACS de base, mais peuvent offrir des services groupés ou exploiter la technologie acquise.
• Support des données FIDO hors SPC (sans friction) : Mastercard Identity Check exploite l'échange de données riches d'EMV 3DS 2.x pour une meilleure prise de décision en matière de risque et un flux sans friction. Leur acquisition de NuData suggère une forte concentration sur l'analyse comportementale dans le cadre de cette évaluation des risques. Le support pour le traitement des données FIDO antérieures du commerçant dépendrait de l'implémentation ACS spécifique utilisée par l'émetteur au sein du programme Identity Check.
• Support de la SPC (Challenge) : Mastercard est un membre clé d'EMVCo et est impliqué dans le développement des standards EMV 3DS, y compris la v2.3 qui prend en charge la SPC. Ils promeuvent également plus largement l'adoption des passkeys. Plus de détails peuvent être trouvés ici. Ils sont un fervent partisan de la SPC et poussent vers des méthodes d'authentification modernes.

Le marché des ACS EMV 3DS compte de nombreux fournisseurs au-delà de ceux détaillés ci-dessus. Des fournisseurs tels que /n software, RSA, 2C2P, 3dsecure.io, Adyen, ACI Worldwide, Computop et d'autres proposent également des solutions certifiées ou jouent des rôles importants dans des régions ou des segments spécifiques. Cette analyse vise à couvrir les acteurs mondiaux de premier plan mais n'est pas exhaustive en raison de la nature dynamique du marché. Les capacités des fournisseurs, en particulier en ce qui concerne les standards émergents comme la SPC, évoluent rapidement. Si vous remarquez des inexactitudes ou si vous avez des informations à jour sur le support des fournisseurs pour les données FIDO ou la Secure Payment Confirmation, n'hésitez pas à nous contacter afin que nous puissions nous assurer que cet aperçu reste actuel et précis.

Un principe fondamental de l'utilisation de la Secure Payment Confirmation (SPC) dans le flux de challenge EMV 3DS est que l'émetteur de la carte (ou une partie explicitement déléguée par l'émetteur, comme un schéma de paiement) agit en tant que Relying Party FIDO (RP). C'est fondamentalement différent du flux de données FIDO hors SPC décrit précédemment, où le commerçant agit généralement comme le RP pour ses propres besoins de connexion/authentification.

Pour que la SPC fonctionne dans un challenge 3DS, les étapes suivantes sont nécessaires :

1. Enrôlement : Le titulaire de la carte doit d'abord enregistrer un authentificateur FIDO (par exemple, la biométrie de l'appareil comme l'empreinte digitale/l'identification faciale, le PIN de l'appareil, ou une clé de sécurité itinérante) auprès de sa banque émettrice. Ce processus crée un passkey, où la clé publique et un identifiant de credential unique sont stockés par l'émetteur et associés au compte du titulaire de la carte ou à une carte de paiement spécifique. L'enrôlement peut se faire dans l'application mobile de la banque, le portail de banque en ligne, ou potentiellement être proposé après un challenge 3DS traditionnel réussi. Fait crucial, pour que la SPC soit invoquée par un tiers comme un site web marchand, le credential doit généralement être créé avec le consentement explicite de l'utilisateur autorisant son utilisation dans de tels contextes, impliquant souvent des extensions WebAuthn spécifiques lors de l'enregistrement.
2. Authentification (pendant le challenge 3DS) :
   • Lorsqu'une transaction 3DS déclenche un challenge, et que l'émetteur/ACS supporte et choisit la SPC, l'ACS identifie le ou les ID de credential FIDO pertinents liés au titulaire de la carte et à l'appareil.
   • L'ACS inclut ce ou ces ID de credential, ainsi qu'un challenge cryptographique unique et les détails de la transaction (montant, devise, nom/origine du bénéficiaire, icône/nom d'affichage de l'instrument), dans la réponse d'authentification (ARes) renvoyée au serveur 3DS/Requestor.
   • Le composant 3DS Requestor du commerçant utilise ces informations de l'ARes pour invoquer l'API SPC du navigateur.
   • Le navigateur présente une boîte de dialogue standardisée et sécurisée affichant les détails de la transaction fournis par l'ACS.
   • L'utilisateur confirme la transaction et s'authentifie à l'aide de son authentificateur FIDO enregistré (par exemple, en touchant un capteur d'empreintes digitales, par reconnaissance faciale, en entrant le PIN de l'appareil, en touchant une clé de sécurité). Cette action déverrouille la clé privée stockée en toute sécurité sur l'appareil/authentificateur.
   • L'authentificateur signe les détails de la transaction présentés et le challenge cryptographique reçu de l'ACS.
   • Le navigateur renvoie l'assertion FIDO résultante (la charge utile de données signée) au 3DS Requestor du commerçant.
   • Le 3DS Requestor transmet cette assertion à l'ACS de l'émetteur, généralement encapsulée dans un second message AReq.
   • L'émetteur/ACS, agissant en tant que Relying Party faisant autorité, utilise la clé publique précédemment stockée du titulaire de la carte pour vérifier cryptographiquement la signature sur l'assertion. Une vérification réussie confirme que le titulaire légitime de la carte, utilisant son authentificateur enregistré, a approuvé les détails spécifiques de la transaction présentés.

L'intégration de la SPC dans le flux de challenge EMV 3DS nécessite des modifications de la séquence de messages standard, impliquant généralement deux échanges AReq/ARes :

1. Requête d'authentification initiale (AReq #1) : Le commerçant/serveur 3DS initie le processus 3DS en envoyant un AReq contenant les données de transaction et de l'appareil. Pour signaler la capacité à gérer la SPC, la requête peut inclure un indicateur comme threeDSRequestorSpcSupport défini sur 'Y' (ou similaire, selon l'implémentation du fournisseur ACS).
2. Réponse d'authentification initiale (ARes #1) : Si l'ACS détermine qu'un challenge est requis et opte pour la SPC, il répond avec un ARes l'indiquant. Le transStatus peut être défini sur 'S' (indiquant SPC requise) ou une autre valeur spécifique. Cet ARes contient la charge utile de données nécessaire pour l'appel à l'API SPC.
3. Invocation de l'API SPC & Authentification FIDO : Le composant 3DS Requestor du commerçant reçoit l'ARes #1 et utilise la charge utile pour invoquer l'API SPC du navigateur. L'utilisateur interagit avec son authentificateur via l'interface utilisateur sécurisée du navigateur.
4. Retour de l'assertion FIDO : Après une authentification utilisateur réussie, le navigateur renvoie les données de l'assertion FIDO au 3DS Requestor.
5. Seconde requête d'authentification (AReq #2) : Le 3DS Requestor construit et envoie un second message AReq à l'ACS. L'objectif principal de ce message est de transporter les données de l'assertion FIDO. Il inclut généralement :
   • ReqAuthData : Contenant l'assertion FIDO.
   • ReqAuthMethod : Défini sur '09' (ou la valeur désignée pour l'assertion SPC/FIDO).
   • Potentiellement la valeur AuthenticationInformation de l'ARes #1 pour lier les requêtes.
   • Optionnellement, un SPCIncompletionIndicator si l'appel à l'API SPC a échoué ou a expiré.
6. Réponse d'authentification finale (ARes #2) : L'ACS reçoit l'AReq #2, valide l'assertion FIDO en utilisant la clé publique du titulaire de la carte, et détermine le résultat final de l'authentification. Il renvoie l'ARes #2 contenant le statut définitif de la transaction (par exemple, transStatus = 'Y' pour Authentification réussie, 'N' pour Échec).

Ce flux à deux AReq représente une déviation par rapport aux méthodes de challenge 3DS traditionnelles (comme l'OTP ou l'OOB gérées via les messages CReq/CRes ou RReq/RRes) qui se terminent généralement dans le cycle initial AReq/ARes après la réception d'un transStatus = 'C'. Bien que la partie interaction utilisateur de la SPC (scan biométrique, saisie du PIN) soit souvent beaucoup plus rapide que la saisie d'un OTP, l'introduction d'un second aller-retour complet AReq/ARes ajoute une latence réseau entre le serveur 3DS, le serveur d'annuaire et l'ACS. Les implémenteurs et les fournisseurs doivent optimiser soigneusement ce flux et gérer les délais d'attente potentiels pour s'assurer que le temps de transaction global de bout en bout reste compétitif et répond aux attentes des utilisateurs.

La Secure Payment Confirmation est positionnée pour une adoption mondiale en raison de sa double standardisation. Elle est formellement définie comme un standard web par le World Wide Web Consortium (W3C), ayant atteint le statut de Recommandation Candidate à la mi-2023, avec des travaux en cours pour devenir une Recommandation complète. Simultanément, la SPC a été intégrée dans les spécifications EMV® 3-D Secure à partir de la version 2.3, gérée par EMVCo, l'organisme technique mondial pour les standards de paiement. Cette intégration garantit que la SPC fonctionne dans le cadre mondial établi pour l'authentification des transactions CNP. La collaboration entre le W3C, l'Alliance FIDO et EMVCo souligne l'effort de toute l'industrie pour créer des standards interopérables pour des paiements en ligne sécurisés et conviviaux.

Bien que la conception de la SPC, en particulier sa capacité à lier cryptographiquement l'authentification de l'utilisateur à des détails de transaction spécifiques (« liaison dynamique »), aide à satisfaire les exigences d'Authentification Forte du Client (SCA) en vertu de réglementations comme la Directive sur les Services de Paiement (DSP2) en Europe, son utilité n'est pas confinée à ces régions réglementées. La SPC est un standard technique mondial applicable sur n'importe quel marché, y compris les États-Unis et le Canada, à condition que les composants nécessaires de l'écosystème soient en place.

Sur les marchés sans mandats SCA explicites pour chaque transaction, les principaux moteurs de l'adoption de la SPC sont :

• Amélioration de l'expérience utilisateur : Offrir une méthode de challenge potentiellement plus rapide et plus pratique (par exemple, en utilisant la biométrie de l'appareil) par rapport aux OTP traditionnels ou aux questions basées sur la connaissance, réduisant potentiellement l'abandon de panier. Des projets pilotes ont montré des réductions significatives du temps d'authentification par rapport aux challenges traditionnels.
• Sécurité renforcée : L'authentification basée sur FIDO inhérente à la SPC est résistante aux attaques de phishing, au credential stuffing et à d'autres menaces courantes ciblant les mots de passe et les OTP.

Par conséquent, les émetteurs et les commerçants dans des régions comme l'Amérique du Nord peuvent choisir d'implémenter la SPC de manière stratégique pour renforcer la sécurité et offrir une meilleure expérience client, même sans obligation réglementaire de le faire pour toutes les transactions.

Le déploiement réussi et l'adoption généralisée de la Secure Payment Confirmation (SPC) dépendent fortement d'une préparation coordonnée de plusieurs composants de l'écosystème des paiements. Bien que les standards FIDO sous-jacents et la technologie des passkeys mûrissent rapidement, le support spécifique au niveau du navigateur pour l'API SPC et l'intégration complète dans la chaîne de paiement restent des obstacles critiques. Les autres acteurs de l'écosystème progressent généralement bien.

Résumé de la préparation de l'écosystème (État en mai 2025)

Ce que cela signifie en pratique (Mai 2025)

Le principal facteur limitant pour l'adoption de la SPC est la couche user-agent (navigateur) :

• Safari (macOS & iOS) : ❌ WebKit ne dispose toujours pas de la méthode de requête de paiement secure-payment-confirmation. Tout site visité dans Safari doit se rabattre sur d'autres méthodes d'authentification (OTP, OOB, potentiellement des expériences WebAuthn non-SPC). Apple n'a pas exprimé d'intérêt pour implémenter l'extension.
• Chrome / Edge (Chromium) : ⚠️ La SPC de base (création de credential + authentification) est stable, mais les clés ne sont pas encore stockées dans des authentificateurs matériels et n'ont été utilisées que dans des projets pilotes. Les implémenteurs doivent s'attendre à des changements potentiellement disruptifs et être prêts à conditionner la fonctionnalité en fonction de vérifications de disponibilité de l'API (par exemple, canMakePayment()) ou de feature flags.
• Firefox : ❌ L'équipe a signalé son intérêt mais n'a pas de calendrier d'implémentation engagé ; les commerçants doivent prévoir des chemins de repli élégants.

Parce que l'infrastructure des émetteurs (ACS, serveurs FIDO) et les serveurs d'annuaire des schémas sont largement prêts ou progressent rapidement, et que les outils des commerçants/PSP deviennent disponibles, le principal obstacle à une utilisation généralisée de la SPC est le support des navigateurs. Une fois que la couverture des navigateurs s'améliorera, les tâches restantes concerneront principalement l'intégration par les commerçants/PSP (mise à niveau vers EMV 3DS v2.3+, ajout de la logique d'invocation de la SPC, gestion du flux à deux AReq) et la généralisation de l'enrôlement des passkeys par les émetteurs spécifiquement pour les contextes de paiement.

Pour l'instant, attendez-vous à ce que la SPC n'apparaisse que pour une part limitée des transactions. Tant que Safari (et donc tout l'écosystème iOS) ne la supportera pas, la SPC ne pourra pas atteindre un support de marché.

L'analyse révèle une nette divergence dans l'état de préparation des deux principales intégrations FIDO au sein d'EMV 3DS en mai 2025. Alors que les éléments fondamentaux pour la Secure Payment Confirmation (SPC) en tant que méthode de challenge progressent – en particulier les capacités des émetteurs/ACS et la préparation des schémas – son adoption généralisée est considérablement freinée par le goulot d'étranglement critique du support des navigateurs, notamment le manque d'implémentation dans Safari d'Apple (bloquant tous les appareils iOS/iPadOS) et Firefox, ainsi que les limitations des implémentations actuelles de Chromium. La SPC reste un état futur prometteur, mais ce n'est pas une solution pratique et universelle aujourd'hui.

Sur la base de l'état actuel de l'écosystème, nous formulons les recommandations suivantes :

• Commerçants :
  • Donnez la priorité à l'adoption des Passkeys : Implémentez les passkeys pour la connexion et l'authentification des utilisateurs. Au-delà de l'amélioration de votre propre sécurité et de l'expérience utilisateur (facteurs non détaillés ici), cela crée les données nécessaires pour les flux sans friction 3DS.
  • Transmettez les données FIDO : Assurez-vous que votre intégration 3DS remplit correctement le champ threeDSRequestorAuthenticationInfo avec les détails des authentifications par passkey antérieures réussies pendant la session de paiement. Travaillez avec votre fournisseur de PSP/serveur 3DS pour activer cela.
• Émetteurs :
  • Enrôlez les Passkeys des utilisateurs : Commencez à proposer et à encourager les titulaires de cartes à enrôler des passkeys directement auprès de vous (pour l'accès à l'application bancaire, la future SPC, etc.). Construisez l'infrastructure FIDO Relying Party nécessaire.
  • Exploitez dès maintenant les données de Passkeys des commerçants : Demandez à votre fournisseur d'ACS d'ingérer et d'utiliser les données FIDO transmises par les commerçants (threeDSRequestorAuthenticationInfo) comme un signal positif fort dans votre moteur RBA. Conservez des enregistrements des passkeys de commerçants de confiance associés aux utilisateurs lorsque cela est possible. Visez à augmenter de manière significative les approbations sans friction pour les transactions précédées d'une authentification par passkey forte chez le commerçant.
  • Préparez-vous pour la SPC, surveillez activement : Assurez-vous que votre feuille de route ACS inclut le support complet de la SPC EMV 3DS v2.3.1+, mais traitez-le comme une amélioration future. Surveillez en permanence les développements des navigateurs (en particulier Safari) pour évaluer quand la SPC pourrait devenir viable à grande échelle.
• Fournisseurs d'ACS :
  • Améliorez la RBA avec l'intelligence des Passkeys : Investissez massivement dans la capacité de votre moteur RBA à traiter et à faire confiance aux données FIDO/passkey fournies par les commerçants. Développez une logique pour suivre l'utilisation des passkeys lors des achats chez les commerçants pour un utilisateur/appareil donné. Stockez les clés publiques (provenant de l'enrôlement direct par l'émetteur) pour vérifier l'intégrité cryptographique des données d'authentification du commerçant si elles sont fournies. Liez directement l'utilisation réussie des passkeys à des taux d'approbation sans friction plus élevés.
  • Développez des capacités SPC robustes : Continuez à développer et à certifier le support complet du flux de challenge SPC (EMV 3DS v2.3.1+) en prévision de l'adoption future par le marché.
• Schémas/Réseaux de paiement :
  • Défendez les données FIDO pour le flux sans friction : Promouvez activement et potentiellement incitez à la transmission et à l'utilisation des données d'authentification FIDO du commerçant (threeDSRequestorAuthenticationInfo) dans le flux 3DS. Fournissez des directives claires et un soutien aux émetteurs et aux fournisseurs d'ACS sur la manière d'exploiter efficacement ces données pour la RBA.
  • Poursuivez la promotion de la SPC et l'engagement avec les navigateurs : Maintenez les efforts pour standardiser et promouvoir la SPC, en vous engageant de manière critique avec les fournisseurs de navigateurs (Apple, Mozilla, Google) pour encourager une implémentation complète et interopérable de la norme API SPC.

L'opportunité immédiate et tangible réside dans l'amélioration du flux sans friction en tirant parti de l'adoption croissante des passkeys au niveau des commerçants. Tous les participants de l'écosystème devraient donner la priorité à la création, la transmission et la consommation intelligente de ces données d'authentification antérieures dans le cadre EMV 3DS existant. Cette voie offre des avantages à court terme en réduisant la friction et potentiellement la fraude sans attendre un support universel de la SPC par les navigateurs. Parallèlement, la préparation du terrain pour la SPC – en particulier l'enrôlement des passkeys par les émetteurs et la préparation des ACS – garantit que l'écosystème est positionné pour adopter cette méthode de challenge supérieure une fois que le goulot d'étranglement des navigateurs sera résolu.