---
url: 'https://www.corbado.com/fr/blog/biometrie-sensibilisation-payeur-lien-dynamique'
title: 'Biométrie et sensibilisation du payeur dans le lien dynamique'
description: 'La sensibilisation du payeur par la biométrie dans le cadre du lien dynamique de la DSP2 : comment la biométrie locale + PKI et les passkeys assurent la conformité, avec les directives de l''ABE/NTR et les bonnes pratiques.'
lang: 'fr'
author: 'Vincent Delitz'
date: '2025-10-02T15:13:39.810Z'
lastModified: '2026-08-28T12:01:32.669Z'
keywords: 'biométrie, sensibilisation du payeur, lien dynamique, dsp2'
category: 'Passkeys Strategy'
---

# Biométrie et sensibilisation du payeur dans le lien dynamique

## Résumé : Biométrie et sensibilisation du payeur dans le lien dynamique

L'approche de Corbado associe les passkeys résistants au [phishing](https://www.corbado.com/glossary/phishing)
(SCA) à un affichage contrôlé par la banque et à un lien dynamique côté serveur pour
respecter l'Art. 5 des [NTR de la DSP2](https://www.corbado.com/blog/psd2-sca-requirements) (« ce que vous voyez
est ce que vous signez »).

- **Implémentation de base (actuelle) :** Nous affichons le **montant et le bénéficiaire**
  de la transaction dans une interface utilisateur contrôlée par la banque Bison, juste
  avant et pendant l'[authentification](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys)
  par passkey. Notre back-end génère un **challenge unique** qui est **lié à un instantané
  canonique de la transaction** (montant, bénéficiaire, txnId). La réponse n'est acceptée
  que si elle correspond à cet instantané ; **toute modification l'invalide**.

- **Position réglementaire :** Le **lien dynamique reste obligatoire** pour les
  [paiements](https://www.corbado.com/passkeys-for-payment) à distance, même avec les passkeys (DSP2 Art. 97(2) ;
  NTR Art. 5). Les NTR **n'exigent pas** que le « code
  d'[authentification](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys) » du lien
  dynamique soit calculé sur l'appareil ; la génération/validation côté serveur est
  acceptable lorsque **l'intégrité de l'affichage**, la **spécificité** et
  **l'invalidation en cas de changement** sont appliquées (voir aussi la Q\&R de l'ABE
  2020_5366 sur l'endroit où le code peut être calculé).

- **Sécurité et auditabilité :** Lier une signature de passkey **ancrée dans le matériel
  et résistante au phishing** à des données de transaction spécifiques **empêche la
  falsification et le relais**, et produit une **preuve solide et irréfutable** du
  consentement du payeur. Lorsque cela est pris en charge, nous pouvons éventuellement
  adopter la **Secure Payment Confirmation (SPC)** pour ajouter une **preuve
  cryptographique des détails affichés** sans modifier le modèle de back-end.

> **Clarification :** Les passkeys éliminent le [phishing](https://www.corbado.com/glossary/phishing)
> inter-origines (ils ne fonctionnent que sur le site/l'application pour lesquels ils ont
> été créés). Le **lien dynamique** garantit que **ce que le payeur a approuvé**
> (montant + bénéficiaire) est **exactement** ce que la banque exécute.

## 1. DSP2, SCA et lien dynamique

- **SCA** : Deux éléments indépendants de catégories distinctes
  (connaissance/possession/inhérence), protégés contre la divulgation/réplication avec des
  mesures d'atténuation appropriées (NTR Art. 6–8). L'indépendance est requise (Art. 9), y
  compris la séparation lors de l'exécution sur des appareils polyvalents (par exemple,
  protections au niveau de l'OS, matériel sécurisé).
- **Lien dynamique (NTR Art. 5)** :
    - (i) le payeur est informé du montant et du bénéficiaire lors de
      l'[authentification](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys)
    - (ii) le code d'authentification est unique à ce montant/bénéficiaire
    - (iii) toute modification invalide le code
    - (iv) la confidentialité/intégrité du montant, du bénéficiaire et du code sont
      protégées de bout en bout. Cela répond à l'intention réglementaire du « ce que vous
      voyez est ce que vous signez ».
- **Implication** : Une [authentification forte](https://www.corbado.com/fr/blog/passkeys-dsp2) de l'utilisateur
  seule ne suffit pas pour les [paiements](https://www.corbado.com/passkeys-for-payment). L'approbation doit être
  liée à des données de transaction spécifiques avec une preuve vérifiable de ce lien et
  de l'affichage au payeur (NTR Art. 5(1)(a–d)).

**Clarification — phishing vs. autorisation :** Les passkeys sont liés à une origine, donc
les faux [domaines](https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys) ne peuvent pas
obtenir de signatures valides. Cependant, la [DSP2](https://www.corbado.com/fr/blog/passkeys-dsp2) exige toujours
un **lien dynamique** pour les [paiements](https://www.corbado.com/passkeys-for-payment) à distance afin de lier
l'autorisation au **montant et au bénéficiaire exacts**, pour **invalider toute
modification** et pour **protéger l'intégrité** de ce qui est affiché au payeur (NTR Art.
5(1)(a–d)). Le lien dynamique traite de l'intégrité de l'autorisation (y compris la
substitution MITM/MITB/TPP), et pas seulement du [phishing](https://www.corbado.com/glossary/phishing).

### 1.1 Contexte théorique — texte de loi et directives

> [DSP2](https://www.corbado.com/fr/blog/passkeys-dsp2) Article 97(2) : « En ce qui concerne le lancement
> d'opérations de paiement électronique, les États membres veillent à ce que les
> prestataires de services de paiement appliquent une
> [authentification forte du client](https://www.corbado.com/blog/psd2-sca-requirements) qui comprenne des
> éléments qui établissent un lien dynamique entre l'opération, un montant et un
> bénéficiaire spécifiques. »
> [DSP2 Art. 97(2)](https://eur-lex.europa.eu/eli/dir/2015/2366/2015-12-23)

> NTR Article 5 : « Les prestataires de services de paiement veillent à ce que le code
> d'authentification généré soit spécifique au montant de l'opération de
> [paiement](https://www.corbado.com/passkeys-for-payment) et au bénéficiaire acceptés par le payeur lors du
> lancement de l'opération ; le payeur est informé du montant de l'opération de paiement
> et du bénéficiaire pour lequel l'authentification est donnée ; le code
> d'authentification accepté par le
> [prestataire de services de paiement](https://www.corbado.com/fr/blog/passkeys-prestataire-paiement-sdk-tiers)
> correspond au montant initial de l'opération de paiement et à l'identité du bénéficiaire
> acceptés par le payeur lors du lancement de l'opération ; toute modification du montant
> ou du bénéficiaire entraîne l'invalidation du code d'authentification ; la
> confidentialité, l'authenticité et l'intégrité du montant et du bénéficiaire sont
> protégées. » [NTR Art. 5](https://eur-lex.europa.eu/eli/reg_del/2018/389/2023-09-12)

L'Avis de l'ABE 2019 (EBA‑Op‑2019‑06) renforce le fait que le lien dynamique lie
l'authentification au montant et au bénéficiaire, exige l'indépendance des facteurs et
accepte les clés cryptographiques liées à l'appareil comme preuve de possession lorsqu'un
lien unique avec l'appareil existe. Il souligne également l'intégrité de ce qui est
affiché au payeur lors de l'authentification.
[Avis de l'ABE 2019](https://www.eba.europa.eu)

### 1.2 Historique du lien dynamique

![history dynamic linking](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/history_dynamic_linking_3c121b5d88.png)

Avant la [DSP2](https://www.corbado.com/fr/blog/passkeys-dsp2), de nombreuses banques s'appuyaient sur des OTP
par SMS ou des listes de TAN imprimées qui n'affichaient souvent ni le montant ni le
bénéficiaire à côté de l'étape d'approbation. Cette lacune permettait de tromper plus
facilement les clients pour qu'ils autorisent des virements non intentionnels une fois
leurs identifiants volés. Le lien dynamique a été introduit pour combler cette lacune en
s'assurant que le payeur est informé du montant exact et du bénéficiaire au moment de
l'authentification et en rendant le code d'authentification spécifique à ces détails afin
que toute modification l'invalide (NTR Art. 5(1)(a–d)). Lorsque le SMS fait partie du
flux, les émetteurs doivent également garantir la confidentialité, l'authenticité et
l'intégrité du montant/bénéficiaire et du code à toutes les phases de l'authentification
(Q\&R 2018_4414 ; NTR Art. 5(2)). Les approbations in-app d'aujourd'hui (par exemple, «
Voulez-vous autoriser 100 USD à Jean Dupont via [Face ID](https://www.corbado.com/faq/is-face-id-passkey) ? »)
mettent en œuvre ce principe du « ce que vous voyez est ce que vous signez » de manière
conviviale pour le client.

### 1.3 Le lien dynamique aujourd'hui : notification push et biométrie locale

![dynamic linking push notification](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/dynamic_linking_push_notification_f11e26ca47.png)

Aujourd'hui, sur mobile, deux modèles dominent. Premièrement, une notification push peut
rediriger le client vers l'application via un deep-link pour qu'il examine les détails de
la transaction et l'approuve. Les superviseurs ont précisé que la notification push peut
servir de preuve de l'élément de possession si les contrôles de l'Article 7 sont en place
pour atténuer l'utilisation non autorisée et empêcher la réplication, et si le parcours
global est conforme aux NTR ; néanmoins, les risques d'ingénierie sociale subsistent et
doivent être pris en compte dans l'UX (Q\&R 2019_4984 ; NTR Art. 7).

![dynamic linking local biometrics](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/dynamic_linking_local_biometrics_36dbc6eff7.png)

Deuxièmement, les approbations utilisant la biométrie native de l'appareil (avec un PIN en
solution de secours) effectuent une vérification de l'utilisateur localement pour
déverrouiller une opération de clé privée. La clé privée se trouve dans un environnement
matériel sécurisé (Secure Enclave/TEE/TPM) et signe un challenge. Cela correspond
parfaitement à la SCA : inhérence (biométrie) plus possession prouvée par le lien à
l'appareil et une clé cryptographique liée à l'appareil (EBA‑Op‑2019‑06, paras. 25,
35–37). Pour les paiements à distance, le code doit être dynamiquement lié au montant et
au bénéficiaire, et ces détails doivent être affichés au payeur avant la vérification de
l'utilisateur (NTR Art. 5). Si les deux facteurs sont sur un seul appareil, il faut mettre
en œuvre des environnements d'exécution sécurisés distincts et des contrôles d'intégrité
afin que la compromission de l'un ne compromette pas l'autre (NTR Art. 9(2)–(3)).

### 1.4 Comment la biométrie locale avec PKI met en œuvre le lien dynamique

Sous le capot, la [biométrie locale](https://www.corbado.com/fr/blog/passkeys-vs-biometrie-locale) ne
s'authentifie pas directement « auprès de la banque ». Au lieu de cela, la biométrie (ou
le PIN de secours) effectue une vérification de l'utilisateur sur l'appareil et contrôle
l'accès à une clé privée non exportable stockée dans un module de sécurité matériel.
Lorsque le payeur approuve, l'appareil utilise cette clé privée pour produire une
signature numérique sur un challenge fourni par la banque. Si la banque dérive ou associe
ce challenge à un instantané canonique de la transaction (montant, bénéficiaire,
identifiants), alors la signature résultante fonctionne comme un code d'authentification
spécifique à ces détails. Toute modification invalidera le code car l'instantané stocké ne
correspond plus ou, dans des conceptions améliorées, parce que la dérivation du challenge
change. La partie relative à la sensibilisation du payeur reste une exigence d'UX :
afficher le montant et le bénéficiaire dans une [vue](https://www.corbado.com/blog/vuejs-passkeys) contrôlée par
la banque juste avant la vérification de l'utilisateur. Ensemble, cela satisfait aux
exigences de l'Art. 5 des NTR sur la sensibilisation, la spécificité/unicité et
l'invalidation en cas de changement, tandis que les contrôles de l'Article 7 et le lien à
l'appareil prouvent l'élément de possession.

![biometrics dynamic linking](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/biometrics_dynamic_linking_4ee6cf3e76.png)

## 2. Pourquoi les passkeys sont conformes à la SCA (liés à l'appareil et synchronisés)

- **Possession (clés liées à l'appareil et synchronisées)** : Les clés privées des
  passkeys sont stockées dans du matériel sécurisé
  (TEE/[Secure Enclave](https://www.corbado.com/glossary/secure-enclave)/TPM). Les passkeys liés à l'appareil ne
  sont pas exportables, ce qui correspond aux attentes de l'ABE pour un lien unique à
  l'appareil (EBA‑Op‑2019‑06, paras. 25, 35–37). Les passkeys synchronisés peuvent
  également prouver la possession à chaque authentification, à condition que le lien à
  l'appareil et les contrôles anti-réplication soient efficaces ; les régulateurs ont
  souligné la nécessité d'un lien fiable entre l'élément et l'appareil (EBA‑Op‑2019‑06 ;
  NTR Art. 7).
- **Inhérence/connaissance (Vérification de l'utilisateur)** : La vérification de
  l'utilisateur via la biométrie (inhérence) ou le PIN de l'appareil (connaissance) active
  la clé localement. Combiné à la possession, il s'agit d'une véritable
  [2FA](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-two-factor-authentication) avec indépendance des
  facteurs. La compromission de l'un ne compromet pas l'autre.

## 3. Les passkeys répondent-ils aux exigences du lien dynamique ?

Le lien dynamique consiste à **lier l'authentification à la transaction**. La question
pour une banque est la suivante : si nous permettons à un utilisateur d'approuver un
paiement via un passkey (plutôt que, disons, un OTP ou un dispositif de signature),
pouvons-nous garantir que cette approbation est spécifique au montant et au bénéficiaire
prévus, et qu'elle ne peut pas être réutilisée ou manipulée ?

Il existe 2 options pour implémenter le lien dynamique avec les passkeys :

- **Lien côté serveur (standard) :** Générer un challenge WebAuthn unique que le back-end
  associe au montant et au bénéficiaire exacts. L'utilisateur voit « X € à Y » dans une
  [vue](https://www.corbado.com/blog/vuejs-passkeys) contrôlée par la banque et approuve avec un passkey. La
  réponse n'est acceptée que pour cette transaction. Toute modification l'invalide.
- **Inclusion cryptographique (avancée) :** Intégrer un hash du montant/bénéficiaire dans
  le challenge pour que la signature s'engage sur les données de la transaction. Ce n'est
  pas requis par les NTR mais ajoute une assurance que même les échanges de back-end
  échoueraient à la vérification.

**Note de conformité explicite :** Les NTR **n'exigent pas** que le « code
d'authentification » du lien dynamique soit calculé sur l'appareil du payeur. Un
[PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) peut le générer et le valider sur
le **serveur** tant que le **montant/bénéficiaire** sont protégés et que **toute
modification** invalide le code (voir Q\&R de l'ABE 2020_5366 sur l'emplacement/le moment
du code). C'est notre approche de **lien dynamique côté serveur (standard)**.

Les deux produisent un « code d'authentification » unique, non réutilisable et spécifique
à la transaction. La principale réserve est la **sensibilisation du payeur** : WebAuthn
lui-même ne prouve pas ce qui a été affiché. L'intégrité de l'affichage doit provenir
d'une interface utilisateur contrôlée par la banque.

### 3.1 Considération sur la sensibilisation du payeur

L'Article 5 des NTR exige que le payeur voie le montant et le bénéficiaire pendant
l'authentification. WebAuthn n'atteste pas de ce qui a été montré. En théorie, si
l'application ou l'OS est compromis, un utilisateur pourrait être trompé alors que
l'authentificateur signe toujours. Nous analyserons ci-dessous en détail comment ce risque
se manifeste en réalité et pourquoi ce n'est pas un risque de sécurité réel, mais plutôt
une question d'interprétation de la réglementation.

**Contrôles d'intégrité de l'affichage que nous appliquons :**

- Une [vue](https://www.corbado.com/blog/vuejs-passkeys) contrôlée par la banque affiche le **montant + le
  bénéficiaire** : nous **bloquons** l'invocation du passkey si la vue est obscurcie ou
  floue.
- **Détection de superposition/falsification** dans l'application/le web : pas d'invites
  de passkey depuis des iframes cachées.
- **Contrôle de l'intégrité/attestation de l'appareil** : refuser ou renforcer la sécurité
  sur les signaux d'appareils rootés/jailbreakés/compromis.
- **Approbation atomique** par rapport à un **instantané** du montant/bénéficiaire détenu
  par le serveur : un nouveau challenge est requis pour tout changement de paramètre.

**À propos de l'inclusion cryptographique :** Les extensions « d'affichage de transaction
» de WebAuthn (SPC) ne sont **pas largement prises en charge** aujourd'hui. Notre base de
référence portable est le **lien côté serveur**, renforcé en dérivant le challenge de
l'instantané de la transaction (par exemple, H(montant ‖ bénéficiaire ‖ txnId ‖ nonce))
afin que la signature **s'engage** sur ces valeurs.

### 3.2 Équivalence réglementaire : biométrie locale avec PKI et passkeys

Les deux modèles utilisent la cryptographie à clé publique avec des clés d'appareil non
exportables, et tous deux s'appuient sur une vérification locale de l'utilisateur pour
déverrouiller l'opération de signature. Dans les deux cas, la banque assure la
sensibilisation du payeur en affichant le montant et le bénéficiaire dans une vue
contrôlée par la banque juste avant la vérification de l'utilisateur, et assure la
spécificité en liant le code d'authentification à ces détails — l'invalidant en cas de
changement (NTR Art. 5(1)(a–d)). Les NTR sont neutres sur le plan technologique et
n'exigent pas que le montant/bénéficiaire soit affiché à l'intérieur d'une modale
biométrique de l'OS ; elles exigent l'affichage au payeur et le lien du code (NTR Art. 5).
Lorsque les deux éléments de la SCA s'exécutent sur un seul appareil, les exigences
d'intégrité et de séparation de l'Article 9 s'appliquent également (NTR Art. 9(2)–(3)).
Enfin, l'emplacement du calcul du lien dynamique est flexible : il peut être effectué côté
serveur si l'intégrité est préservée et que tout changement invalide le code (Q\&R
2020_5366). Ce sont les mêmes conditions dans lesquelles les régulateurs acceptent déjà la
[biométrie locale](https://www.corbado.com/fr/blog/passkeys-vs-biometrie-locale) avec PKI — par conséquent, les
passkeys, mis en œuvre avec les mêmes contrôles de sensibilisation du payeur et de lien,
devraient être acceptés sur une base équivalente.

### 3.3 Les passkeys et l'intention du lien dynamique

Alors, les passkeys simples conformes à la norme WebAuthn répondent-ils à l'intention du
lien dynamique ? **Partiellement :**

- **Attaques MITM/réseau :** Oui. Le lien à l'origine et les signatures par challenge
  empêchent la falsification et la relecture.
- **Intégrité de la transaction :** Oui. L'association au serveur ou le hachage du
  challenge garantit que seuls le montant/bénéficiaire d'origine seront vérifiés.
- **Consentement du payeur :** Plus difficile. Les passkeys n'ont pas d'affichage au
  niveau de l'authentificateur. La tromperie de l'interface utilisateur sur des appareils
  compromis pourrait être possible. Il faut construire quelque chose par-dessus pour
  garantir le consentement du payeur.

**Pourquoi le lien dynamique est toujours nécessaire avec les passkeys**

- **Légal :** L'Art. 97(2) de la DSP2 et l'Art. 5 des NTR exigent le lien dynamique pour
  **toute initiation de paiement à distance**. Il n'y a pas d'exception pour les méthodes
  résistantes au phishing.
- **Sécurité :** Les passkeys suppriment le **phishing inter-origines**, mais ils ne
  prouvent pas par eux-mêmes **ce qui a été affiché** au payeur. Le lien dynamique + les
  contrôles d'intégrité de l'affichage garantissent que le **montant/bénéficiaire
  spécifique** que l'utilisateur a vu est ce que la banque exécute, et que **toute
  modification invalide** l'approbation.

**En résumé, les passkeys peuvent satisfaire au lien dynamique** lorsqu'ils sont
strictement liés aux données de transaction et associés à des mécanismes d'affichage
fiables. Le défi résiduel est de prouver ce que l'utilisateur a réellement vu.

## 4. Comment Corbado met en œuvre le lien dynamique avec les passkeys

Corbado offre une solution conforme au lien dynamique qui aborde explicitement les
considérations de consentement du payeur ci-dessus.

### 4.1 Solution de bout en bout : flux, technologie, UX et conformité

// TODO FOURNIR LES MAQUETTES DE KARUNA ET LES DÉCRIRE

Déroulement du processus :

- **Un affichage contrôlé par la banque** montre au payeur le montant et le bénéficiaire
  exacts. Aucune invite de passkey n'est affichée à moins que cette vue ne soit visible.
- **Authentification :** le client invoque WebAuthn avec un challenge unique et lié pour
  la transaction canonique. L'authentificateur effectue la vérification de l'utilisateur
  (biométrie ou PIN de l'appareil) et signe le challenge et l'origine.
- **Vérification du serveur :** le back-end vérifie le hash de l'ID RP et l'origine, fait
  correspondre le challenge à la transaction stockée, vérifie les indicateurs UV, impose
  une utilisation unique et une expiration, et compare l'instantané du
  montant/bénéficiaire stocké.
- **Approbation et audit :** ce n'est qu'alors que la transaction est approuvée de manière
  atomique. Toute non-concordance/modification est rejetée et nécessite une nouvelle
  authentification. Un enregistrement d'audit immuable est conservé (ID du credential,
  authenticatorData, [clientDataJSON](https://www.corbado.com/glossary/clientdatajson), signature, challenge, et
  montant/bénéficiaire canoniques), éventuellement avec une chaîne de hachage pour prouver
  l'absence de falsification.
- **Contrôle de l'intégrité de l'appareil :** Évaluer les signaux d'intégrité et
  d'[attestation](https://www.corbado.com/glossary/attestation) de l'appareil : refuser ou renforcer la sécurité
  si l'appareil est rooté/jailbreaké/compromis.
- **Canonisation du bénéficiaire :** Afficher une étiquette conviviale (par exemple, «
  ACME GmbH »), mais lier et vérifier par rapport à un **identifiant de bénéficiaire
  canonique** (par exemple, IBAN/BIC ou autre schéma unique).

Détails techniques :

- **Back-end :** créer un objet de transaction avec des données canoniques (par exemple,
  devise/décimales normalisées ; IBAN/bénéficiaire canonique). Générer un challenge à
  courte durée de vie s'engageant sur ces valeurs (par exemple,
  H(montant||bénéficiaire||txnId||nonce)) ; stocker en attente ; n'exposer que des ID
  opaques au client.
- **Client/authentificateur :** afficher les détails du payeur dans une vue contrôlée par
  la banque ; invoquer WebAuthn (ID RP = domaine Bison) uniquement lorsque visible ;
  exiger la vérification de l'utilisateur ; l'authentificateur signe le challenge +
  l'origine conformément à [WebAuthn](https://www.w3.org/TR/webauthn-3/).
- **Vérification/finalisation :** valider la signature, le hash de l'ID RP, l'origine/le
  type, les indicateurs UV ; anti-relecture/expiration ; comparer l'instantané immuable du
  montant/bénéficiaire ; approuver de manière atomique ; conserver l'enregistrement
  d'audit.
- **Dériver le challenge de l'instantané :** :
  `challenge = H(montant ‖ bénéficiaireCanonique ‖ txnId ‖ nonce)`

Politiques UX :

- Mettre clairement l'accent sur le montant/bénéficiaire ; contrôles de
  confirmation/annulation accessibles ; délais d'attente courts ; nouvelles tentatives en
  douceur utilisant toujours un nouveau challenge ; reçus immédiats (par exemple, « Vous
  avez approuvé X € à Y »). Bloquer l'invite de passkey si l'affichage est obscurci et
  avertir si les paramètres changent avant la signature.
- Détecter les superpositions/contenus obscurcis : ne jamais afficher d'invite de passkey
  si la **vue de la transaction n'est pas visible**. Rejeter si les paramètres changent en
  cours de route et redémarrer avec un **nouveau challenge**.

**Note de conformité :** Cette conception de bout en bout répond à l'Art. 5 des NTR :
**sensibilisation du payeur** (affichage contrôlé par la banque), **spécificité** et
**unicité** (code unique lié au montant/bénéficiaire), **invalidation en cas de
changement** (contrôles stricts du serveur), et **confidentialité/intégrité** du
montant/bénéficiaire et du code à toutes les phases (NTR Art. 5(1)(a–d), 5(2) ; voir aussi
Q\&R 2018_4414 pour l'intégrité des SMS). L'indépendance des facteurs (Arts. 7–9) est
préservée via la possession liée à l'appareil et la vérification de l'utilisateur locale
sur des appareils polyvalents avec des protections appropriées (NTR Art. 9(2)–(3)).

_Note :_\* pour les flux web, Corbado adoptera éventuellement la
[Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc)
([https://www.w3.org/TR/](https://www.w3.org/TR/)[payment](https://www.corbado.com/passkeys-for-payment)-request-secure-[payment](https://www.corbado.com/passkeys-for-payment)-confirmation/)
si/quand [Apple](https://www.corbado.com/fr/blog/comment-supprimer-cle-acces-apple-windows-android) offrira un
large support, ajoutant un affichage de confiance médiatisé par le navigateur qui atteste
cryptographiquement du montant et du bénéficiaire.

## 5. Risques résiduels et contrôles compensatoires

**Préoccupation : Attaques de phishing** **Réponse :** Les passkeys sont résistants au
phishing par conception : ils sont liés à l'origine légitime et n'impliquent aucun secret
partagé, de sorte que les identifiants ne peuvent pas être collectés sur un faux site,
contrairement aux OTP. Un attaquant qui relaie le trafic vers un domaine d'apparence
similaire ne peut pas obtenir de signature valide pour l'origine de la banque. Le lien
dynamique contribue moins dans ce vecteur, mais reste obligatoire pour garantir que toute
approbation est unique au montant et au bénéficiaire prévus. Des mesures complémentaires
(sensibilisation au phishing, séparation claire des approbations de
[connexion](https://www.corbado.com/fr/faq/connexion-second-appareil-cle-acces-liee) et de paiement, notation
d'anomalie/risque pour les contextes de paiement inhabituels) réduisent davantage
l'exposition.

**Préoccupation : Ingénierie sociale / Fraude au virement autorisé (APP)** **Réponse :**
Aucun authentificateur ne peut empêcher totalement un utilisateur d'autoriser un paiement
sous de faux prétextes (par exemple, les arnaques au « compte de sécurité »). Le lien
dynamique garantit que l'utilisateur voit explicitement le bénéficiaire et le montant et
fournit une preuve solide de son consentement, mais il ne peut pas passer outre un payeur
convaincu. Les compensations incluent des avertissements contextuels (nouveau
bénéficiaire, premier virement important), des périodes de réflexion ou une exécution
différée pour les bénéficiaires à haut risque, une vérification plus stricte du
bénéficiaire et des contrôles renforcés (confirmation supplémentaire) sur les signaux de
risque. Les notifications post-paiement et les canaux de litige rapides aident à détecter
et à contenir les dommages. Nous ajoutons des **avertissements contextuels** en temps réel
(par exemple, nouveau bénéficiaire, premier virement important), des **périodes de
réflexion** pour les bénéficiaires à haut risque, une **vérification plus stricte du
bénéficiaire** et des **notifications post-paiement** (« Vous avez approuvé X € à Y »)
pour accélérer la [détection](https://www.corbado.com/fr/blog/le-role-de-lia-dans-la-detection-des-cybermenaces)
et la réponse.

**Préoccupation : Malware ou compromission de l'appareil** **Réponse :** Les clés privées
sont **non exportables** et nécessitent une **vérification locale de l'utilisateur** pour
chaque signature, donc un [malware](https://www.corbado.com/glossary/malware) ne peut pas simplement exfiltrer
les identifiants. Le risque réaliste est la **tromperie de l'interface utilisateur** sur
un OS entièrement compromis. Atténuez ce risque avec une interface utilisateur
sécurisée/vérifiée (par exemple, confirmations protégées), des contrôles d'intégrité de
l'appareil/[attestation](https://www.corbado.com/glossary/attestation) et le blocage des appareils à haut risque,
et des confirmations de confiance telles que [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) ou
une extension de confirmation lorsqu'elle est disponible. Si des indicateurs de
compromission apparaissent (détection de superposition, root/jailbreak), utilisez une
re-vérification hors bande ou refusez l'exécution. Aucune méthode grand public n'est
parfaite sur un appareil entièrement contrôlé par un attaquant, mais ces contrôles
réduisent considérablement la fenêtre d'attaque.

**Préoccupation : Man-in-the-browser / Détournement de session** **Réponse :** Des
extensions malveillantes ou des scripts injectés peuvent lancer des actions sur l'origine
légitime. Les passkeys liés à l'origine arrêtent le phishing inter-sites. Le **lien
dynamique** garantit que les modifications en coulisses du montant/bénéficiaire
**échouent**. Nous renforçons le canal via des contrôles CSP/anti-falsification et en
exigeant un **nouveau challenge unique** pour chaque confirmation.

**Préoccupation : Menace interne ou falsification côté serveur** **Réponse :** La réponse
d'authentification est liée de manière unique au montant/bénéficiaire d'origine, donc
toute substitution côté serveur échoue à la validation. Maintenez des enregistrements de
lien immuables et à l'épreuve des falsifications (challenge, credential, signature et
montant/bénéficiaire canoniques) pour l'audit/la non-répudiation. Appliquez la séparation
des tâches et les contrôles à quatre yeux sur les chemins critiques de traitement des
paiements pour réduire le risque interne.

**Préoccupation : Appareils volés / Vol d'identifiants** **Réponse :** La simple
possession de l'appareil est insuffisante : une vérification de l'utilisateur
(biométrie/PIN) est requise pour chaque signature, avec des limitations de tentatives et
des blocages au niveau de l'OS. Chaque paiement nécessite un nouveau challenge spécifique
à la transaction ; les jetons de session génériques ne peuvent pas autoriser des paiements
arbitraires. Des ajouts comme la révocation d'appareil à distance, le renforcement de la
sécurité lors de l'utilisation d'un nouvel appareil, les contrôles de géovélocité et les
notifications (« Vous avez autorisé X € à Y ») limitent davantage les abus.

Globalement : les passkeys réduisent considérablement les risques de phishing et de
relecture ; le lien dynamique reste essentiel pour garantir l'intégrité des transactions,
lier les approbations au montant/bénéficiaire et fournir une preuve solide du consentement
éclairé dans les scénarios de menace restants.

## 6. FAQ sur la conformité

**Question 1 :** Comment pouvons-nous prouver que l'utilisateur a réellement vu et accepté
le montant et le bénéficiaire en utilisant un passkey ? **Réponse :** Nous imposons un
**affichage pour le payeur** dans une vue contrôlée par la banque et lions l'approbation à
un **instantané côté serveur** du montant/bénéficiaire. L'[assertion](https://www.corbado.com/glossary/assertion)
du passkey (authenticatorData, [clientDataJSON](https://www.corbado.com/glossary/clientdatajson), signature)
n'est acceptée **que** pour le challenge dérivé de cet instantané ; **tout changement**
nécessite un nouveau challenge. Notre **audit à l'épreuve des falsifications** lie
l'[assertion](https://www.corbado.com/glossary/assertion) à « X € à l'ID-Bénéficiaire Y » et enregistre que notre
système n'aurait pas procédé si les détails différaient. Lorsque cela est pris en charge,
la **SPC** ajoute une **preuve cryptographique** que l'utilisateur a confirmé les détails
affichés.

**Question 1 :** Comment pouvons-nous prouver que l'utilisateur a réellement vu et accepté
le montant et le bénéficiaire en utilisant un passkey ? **Réponse :** C'est
essentiellement la question de la **non-répudiation**. Dans le cadre de la DSP2, le lien
dynamique visait à garantir que l'utilisateur est conscient de ce qu'il approuve. Avec un
passkey, la preuve que nous conservons est la signature cryptographique (code
d'authentification) et les données associées (à quel montant/bénéficiaire elle était liée
sur notre serveur). Par politique, nous affichons les détails de la transaction à
l'utilisateur dans l'application ou la page web avant qu'il ne s'authentifie. Nous
enregistrons cet écran/cette vue et l'authentification par passkey réussie qui s'ensuit
pour cette transaction spécifique. En cas de litige, nous pouvons montrer que l'appareil
de l'utilisateur a produit une signature valide pour un challenge qui était associé à (par
exemple) « 100 € à ACME Corp. » et que notre système n'aurait pas procédé si un détail
était différent. Notre conformité repose sur une journalisation sécurisée : nous nous
assurons que nos systèmes sont inviolables pour lier la réponse du passkey aux données de
la transaction.

**Question 2 :** Et si l'appareil ou l'OS est compromis ? Un [malware](https://www.corbado.com/glossary/malware)
peut-il manipuler la transaction ou le processus de passkey ? **Réponse :** La
compromission de l'appareil est une menace critique dans tout scénario de
[services bancaires](https://www.corbado.com/passkeys-for-banking) numériques. Si le système d'exploitation est
malveillant, il pourrait tenter de tromper l'utilisateur ou de détourner des processus.
Cependant, même dans le pire des cas, les **passkeys maintiennent certaines protections
clés**. La clé privée ne peut pas être extraite par un [malware](https://www.corbado.com/glossary/malware). Un
malware ne peut pas non plus se faire passer pour l'utilisateur auprès de la banque, car
il ne peut pas produire la signature du passkey sans la biométrie/le PIN de l'utilisateur.
Le maximum qu'il pourrait faire est de pousser l'utilisateur à authentifier quelque chose
sous de faux prétextes. Le lien dynamique aide ici en exigeant des contrôles d'intégrité :
le malware ne peut pas changer silencieusement les détails de la transaction après coup –
s'il le fait, la signature ne sera pas vérifiée. Le point le plus faible est
l'**affichage/l'interface utilisateur** : un [cheval de Troie](https://www.corbado.com/fr/glossary/malware)
sophistiqué pourrait modifier ce que l'utilisateur voit (par exemple, afficher « ACME Corp
» alors que la transaction sous-jacente va en réalité à un autre bénéficiaire). Ce n'est
pas trivial, surtout si l'application bancaire utilise des frameworks d'interface
utilisateur sécurisés, mais c'est concevable. Cela dit, si nous détectons des signes de
compromission de l'appareil (comportement inhabituel, signatures de malware connues,
etc.), nous reviendrions à une vérification hors bande ou refuserions la transaction. **En
résumé :** Aucune solution n'est efficace à 100 % si l'appareil de l'utilisateur est
entièrement contrôlé par un attaquant. Les passkeys + le lien dynamique réduisent
considérablement la surface d'attaque (un attaquant ne peut pas simplement utiliser des
identifiants par procuration ou altérer les données réseau ; il devrait monter une arnaque
en temps réel sur l'utilisateur). Si l'OS est compromis, le lien dynamique garantit au
moins que toute incohérence entre ce qui devrait être et ce qui est approuvé est détectée
par notre back-end.

**Question 3 :** Si une donnée biométrique est utilisée pour déverrouiller le passkey,
est-ce considéré comme un ou deux facteurs ? Respectons-nous la règle des 2 facteurs ?
**Réponse :** Une donnée biométrique seule n'est **pas** suffisante pour la SCA – c'est
juste un facteur d'inhérence. Cependant, dans une
[implémentation](https://www.corbado.com/fr/blog/aide-memoire-cles-dacces) de passkey, la biométrie n'est pas
seule : la possession de l'appareil est l'autre facteur. La biométrie de l'utilisateur
déverrouille la clé privée stockée sur l'appareil. La possession et l'inhérence sont deux
catégories distinctes. C'est analogue à la manière dont de nombreuses applications
[bancaires](https://www.corbado.com/passkeys-for-banking) satisfont déjà à la SCA : vous avez le téléphone
(possession) et vous utilisez votre empreinte digitale ou votre visage pour déverrouiller
l'application (inhérence). L'ABE a explicitement reconnu les combinaisons de lien à
l'appareil plus biométrie comme une SCA conforme. Le scénario du passkey est exactement
cette combinaison. Si l'utilisateur choisit d'utiliser un PIN au lieu de la biométrie pour
déverrouiller le passkey, alors c'est possession + connaissance, également conforme. Nous
imposons la vérification de l'utilisateur sur toutes les opérations de passkey (ce qui
signifie que l'utilisateur doit fournir sa biométrie/son PIN à chaque fois), il n'y a donc
aucune situation où le simple fait d'avoir l'appareil suffit. Ainsi, chaque autorisation
de paiement via passkey est un événement à deux facteurs selon les définitions de la DSP2.

**Question 4 :** Un attaquant pourrait-il réutiliser une authentification par passkey ou
contourner d'une manière ou d'une autre le lien dynamique en manipulant les données en
transit ? **Réponse :** Non. C'est là que les passkeys et le lien dynamique fonctionnent
bien ensemble. Chaque
[authentification WebAuthn](https://www.corbado.com/fr/blog/webauthn-mediation-immediate-expliquee) produit une
**signature unique** qui est liée au challenge (que nous générons par transaction) et est
limitée à notre domaine. Un attaquant ne peut pas rejouer cette signature pour une
transaction différente. La signature elle-même incorpore le nonce du challenge et n'est
valide que pour ce pour quoi elle a été initialement émise. Si un attaquant interceptait
la communication réseau, il ne pourrait pas modifier le montant ou le bénéficiaire sans
invalider la signature (puisque le challenge ou le contexte de la transaction ne
correspondrait plus). C'est effectivement la protection MITM dont nous avons parlé. De
plus, les signatures de passkey incluent des données d'origine – elles ne seront pas
vérifiées si elles ne sont pas envoyées à notre origine exacte de site web/application,
donc le phishing ou la redirection ne fonctionneront pas. En bref, toute tentative de
manipulation invalide le code d'authentification, conformément aux règles du lien
dynamique. C'est en fait plus sûr que certains flux actuels basés sur les OTP, où les
utilisateurs approuvent parfois un code générique et il y a un risque que la demande ait
été falsifiée. Avec les passkeys, nous lions cryptographiquement l'authentification de
l'utilisateur à la session/transaction spécifique.

**Question 5 :** Existe-t-il des avis réglementaires connus sur WebAuthn/passkeys pour la
SCA ? Sommes-nous sûrs que les régulateurs accepteront les passkeys comme conformes ?
**Réponse :** À ce jour, l'ABE n'a pas explicitement publié d'avis sur WebAuthn ou le
terme « passkeys » dans ses Q\&R ou ses directives. Cependant, sur la base des principes
qu'ils ont établis, les passkeys s'intègrent clairement dans les méthodes acceptables.
L'avis de l'ABE de 2019 anticipait essentiellement des approches de type
[FIDO2](https://www.corbado.com/glossary/fido2) : pour la possession, ils mentionnent explicitement **« l'échange
de clés publiques/privées » avec un lien approprié à l'appareil comme preuve de
possession**. Un passkey WebAuthn est exactement cela – une paire de clés publique/privée,
la moitié privée étant liée de manière sécurisée à l'appareil. Ils ont également fait un
clin d'œil à la « signature générée par un appareil » comme preuve de possession valide.
Donc, bien qu'ils n'aient pas utilisé le terme passkey, la méthode est couverte par leurs
exemples. Nous avons également observé que les principaux acteurs des paiements en Europe
avancent avec des implémentations de passkeys (par exemple,
[PayPal](https://www.corbado.com/blog/paypal-passkeys)), ce qui indique un niveau de confiance dans le fait que
cela est conforme à la DSP2. Cet exemple démontre que les passkeys sont acceptés dans le
cadre de flux SCA conformes, à condition que le lien dynamique et les exigences générales
soient respectés.

**Question 6 :** Avons-nous encore besoin du lien dynamique si les passkeys sont
résistants au phishing ? **Réponse :** Oui. Les passkeys éliminent le **phishing
inter-origines**, mais la DSP2 impose toujours le **lien dynamique** pour l'initiation de
paiement à distance. Le lien dynamique lie le **montant et le bénéficiaire spécifiques**
au résultat de la SCA et **invalide toute modification**, traitant de l'intégrité de
l'autorisation au-delà du phishing (par exemple, substitution MITM/MITB/TPP).

## 7. Conclusion : conformité au lien dynamique et résultats améliorés

La solution de Corbado est conforme au lien dynamique et à la DSP2. L'affichage
pré-authentification au payeur, le challenge unique lié au montant et au bénéficiaire, la
vérification stricte du serveur et l'audit immuable satisfont ensemble aux exigences de
l'Art. 5 des NTR sur la sensibilisation du payeur, l'unicité/spécificité, l'invalidation
en cas de changement et l'intégrité/confidentialité. L'indépendance des facteurs est
préservée grâce à la possession liée à l'appareil et à la vérification de l'utilisateur
(biométrie ou PIN), conformément aux directives de l'ABE.

Par rapport aux méthodes OTP/SMS actuelles, Corbado offre une sécurité et des résultats
utilisateur nettement meilleurs : résistance au phishing et à la relecture, prévention de
la falsification silencieuse des paramètres, preuve non répudiable plus solide et friction
réduite grâce à la vérification de l'utilisateur sur l'appareil. Les risques résiduels
(par exemple, ingénierie sociale, appareils compromis) sont atténués par des contrôles
concrets et sont plus étroits qu'avec les méthodes traditionnelles. Pour le web, Corbado
peut adopter la [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) lorsque le support de la
plateforme (notamment [Apple](https://www.corbado.com/fr/blog/comment-supprimer-cle-acces-apple-windows-android))
sera généralisé, ajoutant une preuve cryptographique de l'affichage sans changer la
posture de conformité de base.

En bref, l'autorisation de transaction basée sur les passkeys de Corbado respecte la
lettre et l'esprit du lien dynamique de la DSP2 et améliore la résilience à la fraude et
l'auditabilité par rapport aux approches traditionnelles, tout en maintenant une voie
claire vers les améliorations futures (SPC) à mesure que l'écosystème mûrit.

En pratique, les passkeys satisfont au lien dynamique lorsque nous faisons trois choses :
nous affichons le montant et le bénéficiaire au payeur avant la vérification de
l'utilisateur ; nous générons un code d'authentification spécifique à ces détails exacts ;
et nous invalidons le code en cas de changement (NTR Art. 5(1)(a–d)). Cela reflète les
principes que les régulateurs acceptent déjà pour la
[biométrie locale](https://www.corbado.com/fr/blog/passkeys-vs-biometrie-locale), avec la commodité
supplémentaire que les passkeys sont natifs à l'OS et fonctionnent sur les canaux web et
applicatifs sans application supplémentaire. Combinés au lien à l'origine, ils ne
présentent pas de demandes usurpées — seules les invites légitimes du site ou de
l'application d'origine apparaissent à l'utilisateur.