Liaison dynamique avec les passkeys : Secure Payment Confirmation (SPC)

Want to learn how top banks deploy passkeys? Get our 80-page Banking Passkeys Report (incl. ROI insights). Trusted by JPMC, UBS & QNB.

Get Report

Dans notre série complète en quatre parties (partie 1, partie 2, partie 3 et partie 4) sur la DSP2, nous avons exploré comment les passkeys s'intègrent aux mesures d'authentification forte du client (SCA) introduites par la DSP2. Nous nous sommes particulièrement concentrés sur les éléments d'authentification requis par la SCA pour accéder aux applications bancaires. Les exigences de la SCA ne s'appliquent pas seulement à l'accès aux applications, mais aussi à l'initiation et à la signature de transactions de paiement électronique à distance. De plus, ces exigences nécessitent l'utilisation d'un mécanisme connu sous le nom de liaison dynamique. Dans cet article, nous allons expliquer ce qu'est la liaison dynamique et examiner comment les passkeys peuvent être utilisés efficacement pour mettre en œuvre ce mécanisme, aujourd'hui comme demain.

La liaison dynamique est une exigence de sécurité de la directive DSP2 et de son addendum d'application, les Normes Techniques de Réglementation (NTR). Le concept a été introduit pour renforcer la sécurité des paiements électroniques en s'assurant que chaque transaction est liée de manière unique à un montant spécifique et à un bénéficiaire spécifique par un code d'authentification. Cette liaison empêche toute modification des détails de la transaction une fois qu'elle a été authentifiée par le payeur, réduisant ainsi le risque de fraude. Les paiements électroniques incluent les virements bancaires dans les logiciels de banque en ligne, mais aussi les paiements par carte de crédit sur les sites marchands.

Selon la directive DSP2 et les NTR qui l'accompagnent, la liaison dynamique est définie comme un processus qui garantit que « le code d'authentification généré est spécifique au montant et au bénéficiaire convenus par le payeur lors de l'initiation de la transaction de paiement électronique » (Article 97(2) de la DSP2). Cela signifie que toute modification des détails du paiement invaliderait le code d'authentification, nécessitant une nouvelle authentification.

La liaison dynamique est cruciale dans la DSP2, car elle répond directement aux risques de sécurité associés aux transactions électroniques à distance, qui sont particulièrement vulnérables à différents types de fraude, comme les attaques de l'homme du milieu (man-in-the-middle).

En sécurisant la transaction de cette manière, la liaison dynamique réduit considérablement la possibilité de transactions non autorisées.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

L'article 5 des NTR détaille les exigences pour le code d'authentification dans la liaison dynamique. Ces exigences incluent :

• Sensibilisation du payeur : Le payeur est informé du montant de la transaction de paiement et du bénéficiaire.

• Le code d'authentification est unique : Le code d'authentification généré pour chaque transaction doit être unique et ne doit pas être réutilisable pour une autre transaction.

• Le code d'authentification est spécifique : Les codes générés et le code accepté doivent être spécifiques au montant de la transaction et à l'identité du bénéficiaire tels que confirmés par le payeur. Toute modification du montant ou du bénéficiaire entraîne l'invalidation du code d'authentification.

• Transmission sécurisée : La confidentialité, l'authenticité et l'intégrité sont maintenues pour le montant de la transaction et le bénéficiaire tout au long des phases de l'authentification, y compris la génération, la transmission et l'utilisation du code d'authentification.

Maintenant que les exigences techniques de la liaison dynamique sont posées, nous verrons dans la section suivante comment les passkeys peuvent aider en tant que nouvelle technologie. Nous explorerons leur potentiel pour rationaliser et sécuriser les processus d'authentification des paiements, rendant la liaison dynamique non seulement plus robuste, mais aussi plus conviviale.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

Corbado proved to be a trusted partner. Their hands-on, 24/7 support and on-site assistance enabled a seamless integration into VicRoads' complex systems, offering passkeys to 5 million users.

Les entreprises font confiance à Corbado pour protéger leurs utilisateurs et fluidifier les connexions avec les passkeys. Obtenez votre consultation gratuite sur les passkeys dès maintenant.

Obtenez une consultation gratuite

Analysons d'abord les différentes options d'utilisation des passkeys dans la liaison dynamique.

Dans cette approche, le passkey lui-même agit comme une assertion cryptographique qui est utilisée directement comme code d'authentification. Le défi (challenge) émis pendant le processus de transaction est généré pour refléter spécifiquement les détails de la transaction, tels que le montant et le bénéficiaire, et est stocké avec ces informations. Lorsque l'utilisateur autorise la transaction avec son passkey, une signature unique et cryptographiquement sécurisée est générée, qui peut être vérifiée et stockée avec la transaction. Cette réponse sert non seulement de facteur d'authentification robuste, mais lie aussi directement l'approbation aux détails spécifiques de la transaction, respectant strictement les exigences de la DSP2 pour la liaison dynamique.

Become part of our Passkeys Community for updates & support.

Join

Une intégration plus avancée consiste à encoder des détails de transaction supplémentaires dans le challenge WebAuthn lui-même (ce qui n'est techniquement pas requis par la DSP2/NTR). Cette méthode suggère d'incorporer un hachage cryptographique du bénéficiaire et du montant, ainsi que d'autres données aléatoires, dans le challenge. Ce faisant, le processus d'authentification ne se contente pas de vérifier l'identité de l'utilisateur via le passkey, mais affirme aussi cryptographiquement l'intégrité des détails de la transaction. Cette approche offre une couche de sécurité supplémentaire en garantissant que toute altération du montant ou des détails du bénéficiaire serait détectable au moment du paiement final. La preuve cryptographique devient une partie immuable du code d'authentification, renforçant la confiance et la sécurité dans les environnements de transaction à haut risque (plus d'infos ici).

Analysons les limites et les défis de ces deux options.

L'une des limites de l'utilisation des passkeys dans le contexte de la liaison dynamique, en particulier pour l'authentification des paiements, est le manque de documentation concrète ou d'assurance que le payeur a été correctement informé des informations sur le bénéficiaire.

Bien que les passkeys fournissent une méthode sécurisée pour l'authentification de l'utilisateur, ils ne vérifient pas intrinsèquement si tous les détails de la transaction, en particulier ceux concernant le bénéficiaire, ont été correctement affichés au payeur.

Ce problème n'est pas propre aux passkeys ; c'est un défi commun à divers systèmes de paiement en ligne. S'assurer que le payeur est pleinement conscient et consent à tous les détails de la transaction avant d'initier le paiement est crucial pour maintenir la confiance et la sécurité.

La limitation la plus importante de l'intégration des passkeys dans la liaison dynamique réside dans la distinction entre l'enregistrement de première partie et de tierce partie.

Qu'est-ce qu'un contexte de paiement de première partie ?

✔️ Dans le contexte de paiement de première partie, l'utilisateur interagit directement avec l'émetteur / la banque sur son service internet et son domaine. Les passkeys peuvent être enregistrés et authentifiés de manière transparente. Un exemple pourrait être une banque qui enregistre un passkey sur son propre site web et l'utilise pour autoriser une initiation de paiement depuis son logiciel de banque en ligne. Ici, les passkeys fonctionnent parfaitement. La banque peut s'assurer que le passkey est utilisé dans son domaine, maintenant le contrôle sur l'environnement de paiement et la sécurité de la transaction.

Veuillez consulter notre article de blog sur l'implémentation des passkeys par Mastercard dans un contexte de paiement de première partie.

Qu'est-ce qu'un contexte de paiement de tierce partie ?

Dans le contexte de paiement de tierce partie, l'utilisateur se trouve sur la page d'un marchand lors du processus de paiement sur un domaine différent (par ex. amazon.com) et souhaite initier une transaction par carte de crédit :

• ✔️ Cas 1 – L'utilisateur a déjà un passkey de son émetteur / sa banque : Le marchand affiche un iframe où l'authentification avec le passkey peut avoir lieu. L'IFRAME est affiché par le processus sous-jacent 3-D Secure 2 (3DSS/EMV 3DS) qui est déjà en place pour les transactions par carte de crédit nécessitant la SCA et la liaison dynamique.

• ❌ Cas 2 – L'utilisateur n'a pas de passkey de son émetteur / sa banque : Encore une fois, le marchand affiche l'iframe. Comme aucun passkey n'est encore disponible, l'utilisateur est authentifié par les facteurs d'authentification existants (par ex. OTP par SMS ou l'application bancaire native sur son smartphone). À ce stade, après une authentification réussie, ce serait le moment idéal pour enregistrer un passkey pour l'utilisateur, mais cela n'est pas autorisé en raison des restrictions de la norme WebAuthn. L'enregistrement de passkeys dans un iframe cross-origin n'est pas autorisé (le domaine de la page principale et de l'iframe devrait être identique). Un enrôlement progressif comme dans la capture d'écran suivante serait impossible :

L'enregistrement de passkeys dans les iframes cross-origin sera-t-il pris en charge à l'avenir ?

Bien que les passkeys offrent une bonne solution pour la liaison dynamique dans un contexte de paiement de première partie au sein d'un même domaine, dans les contextes de paiement de tierce partie, ils ne sont actuellement pas pris en charge par WebAuthn Level 2. Cependant, la bonne nouvelle est que le support de l'iframe cross-origin est déjà intégré dans la spécification WebAuthn Level 3 en cours (qui sera rendue généralement disponible d'ici la fin de 2024). Cependant, les navigateurs doivent encore rattraper la spécification :

À ce jour, il semble que d'ici 2024, la couverture pour l'enregistrement cross-origin des passkeys pourrait devenir une réalité dans les principaux navigateurs, ce qui lèverait la limitation technique la plus importante à l'utilisation des passkeys pour les paiements.

Il y a eu plusieurs tentatives (par ex. BasicCard, PaymentHandler ou PaymentManifest) de la part de groupes de travail initiés par Google au W3C pour améliorer l'expérience de paiement sur le web. Jusqu'à présent, aucune n'a atteint une couverture de marché et une utilisation significatives. La friction dans le processus de paiement pour les transactions de commerce électronique reste un défi majeur avec une réglementation croissante contre la fraude. La norme Secure Payment Confirmation (SPC), initiée par Google & Stripe, est actuellement la norme la plus prometteuse s'appuyant sur la norme WebAuthn.

La Secure Payment Confirmation (SPC) aborde tous les éléments importants de la SCA de la DSP2, y compris l'exigence de liaison dynamique, tout en essayant d'améliorer l'expérience utilisateur (UX).

• Offrir une UX native au navigateur : SPC s'appuie sur le navigateur pour fournir une expérience d'authentification cohérente et rationalisée sur différents sites marchands et relying parties. Cette approche vise à améliorer la sécurité des transactions au-delà de ce qui est généralement atteint avec du contenu rendu dans un iframe, en ayant une apparence cohérente et en garantissant la sensibilisation du payeur :

Exemple tiré de https://www.w3.org/press-releases/2023/spc-cr/

• Fournir une preuve cryptographique : La norme garantit qu'une preuve cryptographique de la confirmation par l'utilisateur des détails du paiement est générée et incluse dans l'assertion WebAuthn sans avoir besoin d'encoder les informations dans le challenge WebAuthn.

• Permettre l'enrôlement par des tiers : Contrairement à la norme WebAuthn Level 2, où l'enregistrement d'un authenticator doit se faire dans un contexte de première partie, SPC permet l'enregistrement de passkeys directement depuis un iframe cross-origin. Cette capacité répond aux cas d'usage courants dans l'écosystème des paiements et facilite l'intégration pour les marchands et les processeurs de paiement. Comme nous l'avons vu plus haut, cette fonctionnalité fait déjà partie de la prochaine version de la norme sous-jacente et sera donc probablement retirée de SPC à l'avenir.

• Authentification cross-origin des paiements : SPC étend l'utilité de WebAuthn en permettant à n'importe quelle origine de générer une assertion pour une transaction, même si elle s'appuie sur des identifiants d'une autre Relying Party (sans avoir besoin de quitter la page). Dans ce cas, même un iframe du marchand / émetteur n'est pas nécessaire. Cette fonctionnalité est particulièrement utile dans les scénarios où plusieurs parties (marchand + émetteur / banque) sont impliquées dans le processus d'authentification et où l'assertion peut ensuite être transportée vers la Relying Party d'origine (le fournisseur de compte, par ex. une banque) pour vérification.

L'exemple ci-dessus est tiré de l'Explainer SPC et montre le concept d'authentification Cross-Origin des paiements : Dans un processus de paiement utilisant SPC, l'utilisateur reste sur le site du marchand (surligné en bleu) tout au long de la transaction. Le navigateur web (en vert) maintient l'affichage de l'origine du marchand et présente également une boîte de dialogue prédéfinie non personnalisable avec toutes les informations importantes pour la liaison dynamique (montant + bénéficiaire) pour confirmer la transaction. Après la confirmation de l'utilisateur, le système d'exploitation (représenté en orange) gère l'authentification biométrique nécessaire pour vérifier la transaction.

Ces objectifs illustrent l'engagement de SPC à améliorer à la fois la sécurité et l'expérience utilisateur des paiements en ligne, visant à simplifier les processus d'authentification tout en maintenant des normes de sécurité élevées dans le paysage des paiements numériques.

Passons en revue tous les flux possibles que SPC permettrait et comparons-les aux passkeys standard, afin de comprendre les avantages.

Comme nous pouvons le voir ici, la distinction la plus importante est l'enregistrement sur le site web du marchand au sein d'un iframe, qui n'est pas encore pris en charge par les passkeys (voir notre discussion ci-dessus), et la toute nouvelle possibilité d'authentification Cross-Origin. Passons-les en revue un par un.

Voici un exemple de maquette d'enregistrement d'un passkey SPC directement sur la page de Mastercard. Comme vous pouvez le voir ici, la création du passkey est proposée juste après la fin de l'authentification par OTP SMS dans ce cas.

Dans ce cas, la communication ressemblerait à un processus d'enregistrement de passkeys standard, car cela se passe entièrement dans le contexte de première partie.

Tiré de https://developer.chrome.com/docs/payments/register-secure-payment-confirmation

Ce passkey SPC pourrait maintenant être utilisé sur un site marchand pour l'authentification, dans un iframe sur le site marchand et pour l'authentification Cross-Origin (voir ci-dessous).

Comme nous l'avons vu précédemment, le processus d'enregistrement d'un passkey SPC sur un site marchand se produirait généralement pendant la transaction de paiement, dans le contexte du flux 3-D Secure (3DS). Ce flux est conçu pour renforcer la sécurité des transactions par carte de crédit et de débit en ligne en impliquant une étape d'authentification supplémentaire qui vérifie l'identité du titulaire de la carte.

Lors d'une transaction de paiement, lorsque le flux 3DS est initié, le processus d'authentification est facilité par un iframe hébergé sur le site du marchand (par ex. amazon.com) mais contrôlé par le fournisseur de services de paiement ou la banque émettrice (par ex. mastercard.com). Cet iframe sert d'environnement sécurisé pour que le client authentifie son identité à l'aide des facteurs d'authentification existants.

Une fois que le client s'est authentifié avec succès à l'aide de ces facteurs conventionnels (par ex. OTP par SMS ou application bancaire), il a la possibilité d'enregistrer un passkey SPC pour les transactions futures. Comme la norme SPC autorise la création de passkeys cross-origin depuis des iframes, cela fonctionnerait. L'enregistrement de ce passkey dans l'iframe impliquerait généralement que le client effectue une action qui génère et lie le passkey à sa carte de crédit, comme la vérification de son empreinte digitale ou la reconnaissance faciale sur un appareil compatible. Gardez à l'esprit que l'iframe est contrôlé par le fournisseur de services de paiement (par ex. PayPal) ou la banque émettrice (par ex. mastercard.com). Par conséquent, le passkey SPC est créé directement avec l'émetteur / la banque et non avec le marchand. Le flux simplifié ressemblerait à ceci :

Tiré de https://developer.chrome.com/docs/payments/register-secure-payment-confirmation

Sur https://spc-merchant.glitch.me/, Google a mis en place une application de démonstration accessible via Chrome sur Windows et Mac, qui illustre comment cela fonctionnerait depuis un iframe :

Elle permet également de jouer directement avec le site de la banque qui est hébergé sous : https://spc-rp.glitch.me/reauth. Dans cet exemple, aucune communication hors bande avec des API entre le marchand et l'émetteur / la banque n'est nécessaire – tout est géré par le navigateur. L'authentification à l'aide d'un passkey existant fonctionnerait de la même manière depuis l'iframe.

Dans l'exemple suivant, nous voyons l'authentification Cross-Origin où l'utilisateur a déjà enregistré un passkey SPC avec Mastercard. Le site marchand d'exemple (decorshop.com) peut déclencher l'authentification Cross-Origin. La différence majeure et importante est que la page du marchand / de l'émetteur n'est jamais visible pendant le processus d'authentification. Le navigateur, en combinaison avec le système d'exploitation, présente l'UX de paiement prédéfinie (fournie par l'implémentation du navigateur de la norme SPC) et la modale d'authentification (norme WebAuthn). La communication entre le marchand et l'émetteur / la banque est gérée en arrière-plan.

Originalement de (partiellement ajusté) : https://www.w3.org/2023/Talks/mc-passkeys-20230911.pdf (Mastercard)

Originalement de (partiellement ajusté) : https://github.com/w3c/secure-payment-confirmation/tree/main/sequence-diagrams

Lors de l'utilisation de l'authentification Cross-Origin, le marchand communique avec l'émetteur / la banque via une forme d'API pour échanger des informations sur les identifiants existants (n°2 dans le diagramme de séquence ci-dessus). Si des identifiants existent et que le navigateur de l'utilisateur prend en charge SPC, l'authentification commence. À la fin, l'assertion est renvoyée jusqu'à l'émetteur / la banque via des protocoles existants comme EMV 3DS, où l'assertion peut être finalement vérifiée cryptographiquement à la fin (n°16).

Comme l'assertion inclut également des informations sur les informations affichées par le navigateur, toutes les exigences de la liaison dynamique sont remplies. Ce serait une étape majeure en termes d'amélioration de l'UX et de l'expérience de paiement du client.

La norme Secure Payment Confirmation (SPC) est une évolution intéressante dans le monde de l'authentification des paiements en ligne, visant à renforcer la sécurité tout en rationalisant l'expérience utilisateur. À ce jour, Google Chrome est le seul grand navigateur à prendre en charge SPC sous une forme ou une autre. Cependant, ce n'est pas surprenant car la norme a été partiellement initiée par Google. De la part d'autres grands navigateurs comme Safari d'Apple et Mozilla Firefox, il y a un manque notable d'engagement sans signaux clairs sur leurs plans de prise en charge de SPC. Plus précisément, Apple pousse sa propre norme propriétaire Apple Pay et ne semble pas intéressé par d'autres normes de paiement.

La connexion de SPC avec WebAuthn a rendu le processus de développement plus difficile. En effet, toute amélioration ou modification de la norme SPC doit être soigneusement évaluée pour éviter la redondance et s'assurer qu'elle apporte de véritables améliorations par rapport aux capacités existantes. L'objectif est d'affiner SPC pour répondre à des besoins spécifiques dans le processus de paiement qui ne sont pas entièrement couverts par WebAuthn, tels que l'intégration directe dans le flux de paiement et la fourniture d'une expérience d'authentification plus conviviale qui peut fonctionner de manière transparente sur différents sites marchands.

Alors que SPC continue d'évoluer, son adoption par différents navigateurs sera cruciale pour une mise en œuvre généralisée. L'implication d'acteurs majeurs comme Google indique une direction positive, mais un soutien plus large sera nécessaire pour établir SPC comme une norme dans l'industrie du paiement en ligne.

Les défis décrits ci-dessus, en particulier autour de la sensibilisation du payeur, ont incité le groupe de travail WebAuthn à travailler sur une extension de confirmation (anciennement connue sous le nom de « txAuthSimple ») au sein de la norme WebAuthN. Son objectif est de permettre soit à l'authenticator, soit au navigateur/OS (dans une interface utilisateur privilégiée) d'afficher les détails de la transaction à l'utilisateur et de s'assurer que la relying party reçoit une preuve cryptographique que l'utilisateur a bien confirmé ces détails. Cela résout directement le problème du « manque de garantie de la sensibilisation de l'utilisateur » décrit dans la section 3.3.1.

Similaire à la manière dont Secure Payment Confirmation (SPC) fournit une boîte de dialogue dédiée pilotée par le navigateur, l'extension de confirmation s'attaque au problème du « Ce que vous voyez est ce que vous signez » (WYSIWYS). Ses principaux objectifs sont :

• Affichage fiable des détails de la transaction : Plutôt que de laisser le contenu web afficher le montant et le bénéficiaire, l'extension s'appuie soit sur l'écran sécurisé d'un appareil, soit sur une boîte de dialogue de l'interface utilisateur du navigateur sous le contrôle de l'OS.
• Preuve cryptographique : L'authenticator (ou la plateforme client) signe un enregistrement du texte exact affiché. En vérifiant cette signature, la relying party peut confirmer que l'utilisateur a vu les bons détails.
• Solution de repli si l'authenticator ne prend pas en charge l'affichage : Dans les cas où un authenticator matériel ne peut pas afficher de texte, le navigateur peut l'afficher et l'inclure dans les [=client data=]. C'est une garantie plus faible mais permet une compatibilité plus large.

L'extension ajoute un nouveau champ aux structures d'extension WebAuthn existantes. Les Relying Parties fournissent une simple chaîne de texte (avec un formatage de base optionnel) appelée confirmation :

partial dictionary AuthenticationExtensionsClientInputs {
  USVString confirmation;
};

Lorsque le client (navigateur) reçoit cela, il :

1. Invite l'utilisateur avec une boîte de dialogue de confirmation spéciale (pour qu'il sache qu'il s'agit de plus qu'une simple connexion).
2. Passe la même chaîne à l'authenticator sous forme de données CBOR si l'authenticator prend en charge l'extension.
3. Retourne toute sortie de l'authenticator à la Relying Party.

Si l'authenticator prend en charge l'affichage de texte, il doit afficher ce texte (par exemple, sur son propre écran ou son interface utilisateur de confiance) avant de terminer la vérification de l'utilisateur. Il inclut ensuite la même chaîne dans sa sortie signée.

Du côté de la Relying Party, les étapes de vérification garantissent que le texte confirmation retourné correspond à ce qui a été envoyé. Si la sortie de l'extension de l'authenticator est manquante mais que la politique de la Relying Party autorise une solution de repli, la Relying Party peut se fier à la valeur confirmation des données client, indiquant que le navigateur a affiché le texte à la place de l'authenticator.

En intégrant le bénéficiaire et le montant dans cette extension, l'utilisateur voit précisément ce qu'il autorise sur un affichage de confiance. La signature de l'utilisateur ne reflète plus seulement un challenge haché, mais aussi le texte exact de la transaction. Ceci est particulièrement précieux pour l'exigence de liaison dynamique de la DSP2, car :

• Toute non-concordance ou modification des détails de la transaction après l'affichage invalide la signature.
• La Relying Party peut prouver que l'utilisateur a reçu les bons détails de la transaction au moment de la signature, remplissant l'exigence de « sensibilisation du payeur » de la DSP2 de manière beaucoup plus robuste que le simple hachage de données dans le challenge.

Bien que l'extension de confirmation soit encore en discussion, elle représente une étape cruciale vers des flux de transaction plus sécurisés et conviviaux. En l'intégrant directement dans la spécification WebAuthn, elle offre :

• Interopérabilité : Tout authenticator ou client implémentant l'extension suivrait le même format standardisé.
• Flexibilité : Les Relying Parties peuvent appliquer des politiques plus strictes (exigeant un affichage au niveau de l'authenticator) ou accepter une solution de repli au niveau du navigateur si nécessaire.
• Alignement plus large de l'écosystème : Elle s'aligne bien avec les mandats réglementaires comme la DSP2, en particulier autour d'une liaison dynamique robuste.

Pour plus de détails techniques, vous pouvez consulter la discussion en cours : pull request GitHub #2020. En résumé, l'extension de confirmation pourrait également combler la dernière lacune majeure dans les flux standard basés sur les passkeys : fournir une preuve cryptographique de ce que l'utilisateur a exactement vu lorsqu'il a donné son consentement, bien que de manière moins structurée qu'avec la Secure Payment Confirmation. Si elle gagne du terrain auprès des navigateurs et des fournisseurs d'authenticators, elle pourrait devenir une méthode hautement standardisée pour offrir la garantie de sécurité WYSIWYS nécessaire dans le cadre de la liaison dynamique de la DSP2, et au-delà.

Bien que SPC et l'extension de confirmation partagent un objectif commun de renforcer la liaison dynamique dans WebAuthn, ils diffèrent par leur portée et leur approche. Le tableau ci-dessous met en évidence certaines de ces différences :

En substance, SPC tente d'offrir une solution de paiement complète* et intègre également la liaison dynamique* dans son flux. L'extension de confirmation*, quant à elle, répond à l'exigence « ce que vous voyez est ce que vous signez » au sein des messages WebAuthn standard sans imposer un flux de paiement complet. L'une ou l'autre approche pourrait faciliter la conformité à la DSP2, mais chacune dépend du soutien des navigateurs et des authenticators pour offrir des avantages concrets.

Notre recommandation pour les émetteurs, les banques et les institutions financières est donc d'évaluer soigneusement les cas d'usage à couvrir et de surveiller l'évolution de l'écosystème, car la facilité d'utilisation des passkeys exercera une pression considérable sur les solutions existantes de SCA et de liaison dynamique pour qu'elles améliorent leur UX. Les clients exigeront des solutions biométriques sur le web. Pour le moment, notre recommandation opérationnelle est la suivante :

• ✔️ Passkeys pour les paiements initiés sur le site de l'émetteur / de la banque : Les passkeys sont une très bonne solution pour les émetteurs / banques pour implémenter la liaison dynamique directement sur leurs sites web et applications. Ils pourraient être combinés avec d'autres options d'authentification comme les notifications push, les OTP par e-mail / SMS ou les TOTP pour renforcer davantage la sécurité des paiements à haut risque. Bien sûr, les considérations relatives à la conformité SCA devraient toujours faire partie de cette discussion (voir aussi notre série en 4 parties sur les passkeys et la SCA).

  Une solution proposée peut être mise en œuvre par les émetteurs / banques eux-mêmes, car les passkeys sont basés sur la norme ouverte WebAuthn. Cependant, cela nécessite un savoir-faire considérable, la gestion des cas limites et un suivi continu de toutes les nouvelles réglementations et évolutions techniques. L'alternative est d'utiliser un fournisseur d'authentification tiers. Par exemple, Corbado Connect prend en charge la liaison dynamique via la signature de transaction, en s'appuyant sur des challenges WebAuthn ajustés. Toutes les informations sont consignées dans le journal d'audit. Ceci n'est pas seulement utile pour les institutions financières, mais peut être utilisé pour toutes sortes de signatures (par ex. signature de documents, actions utilisateur à haut risque). En option, un OTP supplémentaire par SMS ou e-mail peut être utilisé pour améliorer encore plus la sécurité.

• ❌ Passkeys pour les paiements sur les pages marchandes : Le déploiement de passkeys pour les paiements sur les pages marchandes n'est pas encore possible. Les cas d'usage cross-origin sont encore en développement mais pourraient être une option viable à la fin de 2024. Utiliser des passkeys pour l'authentification sur les pages marchandes est cependant déjà une excellente idée aujourd'hui et peut également être utilisé pour commencer à collecter des passkeys qui pourront ensuite être utilisés pour les paiements à l'avenir.

• ❌ Passkeys SPC ou extension de confirmation pour la liaison dynamique : La norme SPC n'a pas encore atteint un état de maturité et de support suffisant pour être utilisée dans des environnements de production.

Dans l'ensemble, nous sommes heureux de voir que les marchands et les banques ont commencé à s'engager avec la norme et à ajouter leurs exigences et leur soutien à l'écosystème. À l'avenir, les institutions financières et les plateformes de commerce électronique devraient surveiller de près ces avancées technologiques et réfléchir à la manière dont elles pourraient intégrer les passkeys dans leurs systèmes. Alors que les réglementations continuent d'évoluer, il est crucial de rester en avance, en s'assurant que les processus d'authentification des paiements s'alignent sur les dernières normes de sécurité et offrent une expérience utilisateur sécurisée et efficace pour les consommateurs, ce qui améliore la conversion et réduit les frictions.

Pourquoi les Passkeys sont-ils importants ?

Les Passkeys pour les entreprises

Les mots de passe et le phishing mettent les entreprises en danger. Les passkeys offrent la seule solution MFA qui équilibre sécurité et UX. Notre livre blanc couvre la mise en œuvre et l'impact commercial.

Download free whitepaper

Work email *

Name *

Company *

Job title *

Phone number

Get whitepaper

En examinant les passkeys pour la liaison dynamique, il est évident que bien que les passkeys puissent aider à respecter la SCA et la liaison dynamique, l'intégration technique dans des services tiers avec la norme WebAuthn, initialement conçue pour des contextes de première partie, présente certains défis. Ces normes évoluent progressivement pour mieux prendre en charge les scénarios de tierce partie, démontrant un virage vers une plus grande flexibilité dans leur application. La Secure Payment Confirmation (SPC) cherche à poursuivre cette adaptation, visant à améliorer les processus d'authentification des paiements en incorporant des interactions plus conviviales et transparentes sur divers sites marchands.

Cependant, l'avancement et l'acceptation plus large de la norme SPC ou de l'extension de confirmation dépendent fortement de son adoption par les principaux navigateurs — un processus qui a été lent, Google Chrome étant actuellement le seul supporter. Ce faible taux d'adoption pourrait potentiellement empêcher la SPC de dépasser son état actuel, à moins que davantage de navigateurs ne commencent à l'intégrer. Le développement continu et la traction croissante des passkeys suggèrent une direction prometteuse où les systèmes s'appuyant sur des modules de sécurité matériels (HSM) tels que les enclaves sécurisées, les TEE et les TPM joueront également un rôle important pour les applications de paiement, car ces technologies offrent une sécurité renforcée qui pourrait rendre la liaison dynamique des paiements plus pratique et confortable, non seulement pour les transactions initiées sur les sites bancaires, mais aussi sur les plateformes marchandes tierces.

Le potentiel des passkeys à étendre leur utilité aux processus de paiement en ligne met en évidence un aspect important de la sécurisation des transactions sur le web et de la transformation d'Internet en un lieu globalement plus sûr.