---
url: 'https://www.corbado.com/fr/blog/liaison-dynamique-passkeys-spc'
title: 'Liaison dynamique avec les passkeys : Secure Payment Confirmation (SPC)'
description: 'Découvrez comment la liaison dynamique, les passkeys et la Secure Payment Confirmation (SPC) peuvent améliorer les paiements numériques. Apprenez à utiliser les passkeys pour la liaison dynamique.'
lang: 'fr'
author: 'Vincent Delitz'
date: '2025-07-15T13:23:17.318Z'
lastModified: '2026-03-25T10:05:21.938Z'
keywords: 'liaison dynamique, secure payment confirmation, spc'
category: 'Passkeys Strategy'
---
# Liaison dynamique avec les passkeys : Secure Payment Confirmation (SPC)
## 1. Introduction
Dans notre série complète en quatre parties (partie 1, partie 2, partie 3 et partie 4) sur
la [DSP2](https://www.corbado.com/fr/blog/biometrie-sensibilisation-payeur-lien-dynamique), nous avons exploré
comment les passkeys s'intègrent aux mesures d'**authentification forte du client (SCA)**
introduites par la [DSP2](https://www.corbado.com/fr/blog/biometrie-sensibilisation-payeur-lien-dynamique). Nous
nous sommes particulièrement concentrés sur les éléments
d'[authentification](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe) 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](https://www.corbado.com/passkeys-for-payment) é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.
## 2. Qu'est-ce que la liaison dynamique dans la DSP2 ?
La **liaison dynamique** est une exigence de sécurité de la directive
[DSP2](https://www.corbado.com/fr/blog/biometrie-sensibilisation-payeur-lien-dynamique) 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](https://www.corbado.com/passkeys-for-payment) é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](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe). 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](https://www.corbado.com/passkeys-for-payment) électroniques incluent les virements bancaires dans les
logiciels de [banque](https://www.corbado.com/passkeys-for-banking) en ligne, mais aussi les
[paiements](https://www.corbado.com/passkeys-for-payment) par carte de crédit sur les sites marchands.
### 2.1 Définition et importance dans la DSP2
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](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe) 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](https://www.corbado.com/passkeys-for-payment) électronique » (Article 97(2) de la
DSP2). Cela signifie que toute modification des détails du
[paiement](https://www.corbado.com/passkeys-for-payment) 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.
### 2.2 Exigences pour la liaison dynamique dans les transactions financières
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.
## 3. Comment les passkeys peuvent-ils être utilisés pour la liaison dynamique ?
Analysons d'abord les différentes options d'utilisation des passkeys dans la liaison
dynamique.
### 3.1 Option 1 : Utilisation standard des passkeys dans la liaison dynamique
Dans cette approche, le passkey lui-même agit comme une [assertion](https://www.corbado.com/glossary/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.
### 3.2 Option 2 : Preuve cryptographique améliorée via le challenge WebAuthn
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](https://www.w3.org/2024/Talks/Fime_W3C_6feb24.pdf)).
### 3.3 Limites et défis des options de passkeys standard
Analysons les limites et les défis de ces deux options.
#### 3.3.1 La sensibilisation du payeur ne peut être garantie
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é.
#### 3.3.2 Cas d'usage : Contexte de paiement de première partie vs. de tierce partie
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](https://www.corbado.com/passkeys-for-banking) 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](https://www.corbado.com/blog/mastercard-passkeys) 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](https://www.corbado.com/blog/iframe-passkeys-webauthn) où l'authentification avec le
passkey peut avoir lieu. L'[IFRAME](https://www.corbado.com/blog/iframe-passkeys-webauthn) est affiché par le
processus sous-jacent [3-D Secure](https://www.corbado.com/glossary/3d-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](https://www.corbado.com/blog/iframe-passkeys-webauthn). 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](https://www.corbado.com/passkeys-for-banking) 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](https://www.corbado.com/blog/iframe-passkeys-webauthn) 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](https://www.corbado.com/blog/iframe-passkeys-webauthn) est déjà intégré dans la spécification
[WebAuthn Level 3](https://www.corbado.com/blog/passkeys-prf-webauthn) en cours (qui sera rendue généralement
disponible d'ici la fin de 2024). Cependant, les navigateurs doivent encore rattraper la
spécification :
| **Navigateur/Norme** | **Contexte de première partie** | **Contexte de tierce partie** |
| ---------------------------------------------------------------------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| **Enregistrer des passkeys dans des iframes cross-origin :** | | |
| Requis dans WebAuthn Level 2 | ✔️ [Détails](https://issues.chromium.org/issues/40258856) | ❌ |
| Requis dans WebAuthn Level 3 | ✔️ [Détails](https://issues.chromium.org/issues/40258856) | ✔️ [Détails](https://issues.chromium.org/issues/40258856) |
| Implémenté dans Chrome | ✔️ [Détails](https://issues.chromium.org/issues/40258856) | ✔️ [Détails](https://issues.chromium.org/issues/40258856) |
| Implémenté dans Firefox | ✔️ [Détails](https://issues.chromium.org/issues/40258856) | [Signal positif](https://github.com/mozilla/standards-positions/issues/964) pour l'implémentation |
| Implémenté dans [Safari](https://github.com/WebKit/standards-positions/issues/304) | ✔️ [Détails](https://issues.chromium.org/issues/40258856) | En attente d'un signal pour l'implémentation |
| **S'authentifier avec des passkeys dans des iframes cross-origin :** | | |
| Requis dans WebAuthn Level 2 | ✔️ | ✔️ |
| Requis dans WebAuthn Level 3 | ✔️ | ✔️ |
| Implémenté dans Chrome | ✔️ | ✔️ |
| Implémenté dans Firefox | ✔️ | ✔️ |
| Implémenté dans Safari | ✔️ | ✔️ |
À ce jour, il semble que d'ici 2024, la couverture pour l'enregistrement
[cross-origin](https://www.corbado.com/blog/iframe-passkeys-webauthn) 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.
## 4. Option future : Secure Payment Confirmation (SPC)
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](https://www.corbado.com/passkeys-for-e-commerce) 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.
### 4.1 Quels sont les objectifs de la norme SPC ?
La [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (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](https://www.corbado.com/blog/dynamic-linking-passkeys-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](https://www.corbado.com/fr/blog/biometrie-sensibilisation-payeur-lien-dynamique) :
_Exemple
tiré de
[https://www.w3.org/press-releases/2023/spc-cr/](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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/authenticator) doit se faire dans un
contexte de première partie, [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-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](https://www.corbado.com/blog/dynamic-linking-passkeys-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](https://www.corbado.com/glossary/assertion)
pour une transaction, même si elle s'appuie sur des identifiants d'une autre
[Relying Party](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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.
### 4.2 À quoi ressembleraient les flux de passkeys SPC ?
Passons en revue tous les flux possibles que SPC permettrait et comparons-les aux passkeys
standard, afin de comprendre les avantages.
| | **Passkeys SPC** | **Passkeys** |
| ------------------------------------------------------ | ---------------- | ------------ |
| **Auth/enregistrement sur le site de l'émetteur** | ✔️ | ✔️ |
| **Enregistrement sur le site marchand dans un iframe** | ✔️ | ❌/✔️ |
| **Auth sur le site marchand dans un iframe** | ✔️ | ✔️ |
| **Auth cross-origin sur le site marchand** | ✔️ | ❌ |
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.
#### 4.2.1 Passkeys SPC : Enregistrement / Authentification directement sur le site de l'émetteur / de la banque
Voici un exemple de maquette d'enregistrement d'un passkey SPC directement sur la page de
[Mastercard](https://www.corbado.com/blog/mastercard-passkeys). 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](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).
#### 4.2.2 Passkeys SPC : Enregistrement / Authentification sur un site marchand pendant le paiement
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](https://www.corbado.com/glossary/3d-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](https://www.corbado.com/blog/mastercard-passkeys).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](https://www.corbado.com/blog/paypal-passkeys)) 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](https://developer.chrome.com/docs/payments/register-secure-payment-confirmation)_
Sur [https://spc-merchant.glitch.me/](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](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.
#### 4.2.3 Passkeys SPC : Authentification Cross-Origin
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](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](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.
### 4.3 Quel est le statut de la norme Secure Payment Confirmation ?
La norme [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (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.
## 5. Option future 2 : L'extension de confirmation
Les défis décrits ci-dessus, en particulier autour de la **sensibilisation du payeur**,
ont incité le [groupe de travail WebAuthn](https://github.com/w3c/webauthn/pull/2020) à
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](https://www.corbado.com/glossary/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](#331-la-sensibilisation-du-payeur-ne-peut-etre-garantie).
### 5.1 Quels sont les objectifs de l'extension de confirmation ?
Similaire à la manière dont
[Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (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](https://www.corbado.com/glossary/authenticator) (ou la
plateforme client) signe un enregistrement du texte exact affiché. En vérifiant cette
signature, la [relying party](https://www.corbado.com/glossary/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.
### 5.2 Comment fonctionne l'extension de confirmation ?
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` :
```webidl
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](https://www.corbado.com/glossary/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.
### 5.3 Pourquoi est-ce important pour la liaison dynamique ?
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.
### 5.4 Statut actuel de l'extension de confirmation
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](https://github.com/w3c/webauthn/pull/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à.
### 5.5 Comparaison : En quoi SPC et l'extension de confirmation sont-ils différents ?
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 :
| **Critères de comparaison** | **SPC** | **Extension de confirmation** |
| ------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| **Flux de paiement intégré**
_(Gère le processus de paiement complet, les montants, le bénéficiaire, l'interface utilisateur, etc.)_ | ✔️ Inclut une boîte de dialogue de navigateur standardisée pour les paiements | ❌ Se concentre uniquement sur l'affichage et la signature d'une chaîne de texte |
| **Affichage de transaction de confiance**
_(Garantit que l'utilisateur voit le bon bénéficiaire/montant)_ | ✔️ Le flux basé sur le navigateur garantit une UX cohérente | ✔️ Soit l'affichage de l'authenticator, soit le navigateur |
| **Gestion des solutions de repli**
_(Si l'authenticator a une capacité d'affichage limitée ou nulle)_ | ❌ Pas spécifiquement conçu pour les chemins de repli | ✔️ La Relying Party peut accepter un affichage au niveau du client si nécessaire |
| **Portée au-delà de la liaison dynamique**
_(Objectifs plus larges, par ex. flux en un clic, auth cross-origin)_ | ✔️ Conçu pour rationaliser l'ensemble du processus de paiement | ❌ Strictement une extension au challenge/réponse standard de WebAuthn |
| **Maturité et adoption actuelles**
_(Prêt pour les navigateurs)_ | Faible adoption au-delà de Chrome ; calendrier incertain | En discussion au sein du [GT WebAuthn](https://github.com/w3c/webauthn/pull/2020) mais prometteur |
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.
## 6. Recommandation pour les émetteurs / banques
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](https://issues.chromium.org/issues/40258856)
:** 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](https://www.corbado.com/passkeys-for-e-commerce) 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.
## 6. Conclusion
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.