---
url: 'https://www.corbado.com/it/blog/biometria-consapevolezza-pagatore-dynamic-linking'
title: 'Biometria e consapevolezza del pagatore nel dynamic linking'
description: 'La consapevolezza del pagatore con la biometria nel dynamic linking della PSD2: come la biometria locale, la PKI e le passkey soddisfano i requisiti di conformità, con le linee guida e le best practice dell''EBA/RTS.'
lang: 'it'
author: 'Vincent Delitz'
date: '2025-10-02T15:13:36.798Z'
lastModified: '2026-08-29T06:04:15.904Z'
keywords: 'biometria, consapevolezza pagatore, dynamic linking, psd2'
category: 'Passkeys Strategy'
---

# Biometria e consapevolezza del pagatore nel dynamic linking

## Riepilogo: biometria e consapevolezza del pagatore nel dynamic linking

L'approccio di Corbado abbina le passkey resistenti al [phishing](https://www.corbado.com/glossary/phishing)
(SCA) a una visualizzazione controllata dalla banca e a un
[collegamento dinamico](https://www.corbado.com/it/blog/collegamento-dinamico-passkey-spc) lato server per
soddisfare l'Art. 5 delle
[norme tecniche di regolamentazione (RTS) della PSD2](https://www.corbado.com/blog/psd2-sca-requirements) ("ciò
che vedi è ciò che firmi").

- **Implementazione di base (attuale):** Mostriamo l'**importo e il beneficiario** della
  transazione in un'interfaccia utente (UI) controllata da Bison-Bank immediatamente prima
  e durante
  l'[autenticazione](https://www.corbado.com/it/blog/test-password-manager-terze-parti-per-passkey-app-native)
  con passkey. Il nostro backend genera una **challenge unica** che è **legata a
  un'istantanea canonica della transazione** (importo, beneficiario, ID transazione). La
  risposta viene accettata solo se corrisponde a quell'istantanea; **qualsiasi modifica la
  invalida**.

- **Posizione normativa:** Il **collegamento dinamico rimane obbligatorio** per i
  [pagamenti](https://www.corbado.com/it/blog/credenziali-digitali-pagamenti-apple-vs-google-wallet) a distanza
  anche con le passkey (PSD2 Art. 97(2); RTS Art. 5). Le RTS **non richiedono** che il
  "codice di
  [autenticazione](https://www.corbado.com/it/blog/test-password-manager-terze-parti-per-passkey-app-native)" del
  [collegamento dinamico](https://www.corbado.com/it/blog/collegamento-dinamico-passkey-spc) sia calcolato sul
  dispositivo; la generazione/validazione lato server è accettabile quando vengono
  garantite l'**integrità della visualizzazione**, la **specificità** e l'**invalidazione
  in caso di modifica** (vedi anche EBA Q\&A 2020_5366 su dove può essere calcolato il
  codice).

- **Sicurezza e verificabilità:** Associare una firma di passkey **ancorata all'hardware e
  resistente al phishing** a dati specifici della transazione **previene manomissioni e
  attacchi di tipo "relay"** e produce una **prova forte e non ripudiabile** del consenso
  del pagatore. Dove supportato, possiamo opzionalmente adottare la **Secure Payment
  Confirmation (SPC)** per aggiungere una **prova crittografica dei dettagli
  visualizzati** senza modificare il modello di backend.

> **Chiarimento:** Le passkey eliminano il [phishing](https://www.corbado.com/glossary/phishing)
> [cross-origin](https://www.corbado.com/blog/iframe-passkeys-webauthn) (funzionano solo sul sito/app per cui
> sono state create). Il **collegamento dinamico** garantisce che **esattamente ciò che il
> pagatore ha approvato** (importo + beneficiario) sia ciò che la banca esegue.

## 1. SCA e collegamento dinamico della PSD2

- **SCA**: Due elementi indipendenti di categorie distinte (conoscenza/possesso/inerenza),
  protetti contro la divulgazione/replicazione con mitigazioni appropriate (RTS Art. 6-8).
  È richiesta l'indipendenza (Art. 9), inclusa la separazione quando eseguiti su
  dispositivi multiuso (es. protezioni a livello di sistema operativo, hardware sicuro).
- **Collegamento dinamico (RTS Art. 5)**:
    - (i) il pagatore è informato dell'importo e del beneficiario durante
      l'[autenticazione](https://www.corbado.com/it/blog/test-password-manager-terze-parti-per-passkey-app-native)
    - (ii) il codice di autenticazione è unico per quell'importo/beneficiario
    - (iii) qualsiasi modifica invalida il codice
    - (iv) la riservatezza/integrità di importo, beneficiario e codice sono protette
      end-to-end. Ciò realizza l'intento normativo del "ciò che vedi è ciò che firmi".
- **Implicazione**: Una forte autenticazione dell'utente da sola non è sufficiente per i
  [pagamenti](https://www.corbado.com/it/blog/credenziali-digitali-pagamenti-apple-vs-google-wallet).
  L'approvazione deve essere legata a dati specifici della transazione con prove
  verificabili del legame e della visualizzazione al pagatore (RTS Art. 5(1)(a-d)).

**Chiarimento — phishing vs. autorizzazione:** Le passkey sono legate all'origine, quindi
i [domini](https://www.corbado.com/it/blog/webauthn-relying-party-id-rpid-passkey) falsi non possono ottenere
firme valide. Tuttavia, la [PSD2](https://www.corbado.com/blog/psd2-passkeys) richiede ancora il **collegamento
dinamico** per i
[pagamenti](https://www.corbado.com/it/blog/credenziali-digitali-pagamenti-apple-vs-google-wallet) a distanza per
legare l'autorizzazione all'**importo e al beneficiario esatti**, per **invalidare
qualsiasi modifica** e per **proteggere l'integrità** di ciò che viene visualizzato al
pagatore (RTS Art. 5(1)(a-d)). Il
[collegamento dinamico](https://www.corbado.com/it/blog/collegamento-dinamico-passkey-spc) affronta l'integrità
dell'autorizzazione (incluse le sostituzioni MITM/MITB/TPP), non solo il
[phishing](https://www.corbado.com/glossary/phishing).

### 1.1 Contesto teorico — testo legale e linee guida

> [PSD2](https://www.corbado.com/blog/psd2-passkeys) Articolo 97(2): "Per quanto riguarda l'avvio di operazioni
> di [pagamento](https://www.corbado.com/passkeys-for-payment) elettronico, gli Stati membri assicurano che il
> pagatore abbia accesso a procedure di
> [autenticazione forte del cliente](https://www.corbado.com/it/blog/psd2-passkey) che includano elementi che
> colleghino dinamicamente la transazione a un importo specifico e a un beneficiario
> specifico." [PSD2 Art. 97(2)](https://eur-lex.europa.eu/eli/dir/2015/2366/2015-12-23)

> RTS Articolo 5: "I prestatori di servizi di [pagamento](https://www.corbado.com/passkeys-for-payment)
> garantiscono che il codice di autenticazione generato sia specifico per l'importo
> dell'operazione di [pagamento](https://www.corbado.com/passkeys-for-payment) e per il beneficiario concordato
> dal pagatore all'avvio dell'operazione; che il pagatore sia informato dell'importo
> dell'operazione di pagamento e del beneficiario a cui viene data l'autenticazione; che
> il codice di autenticazione accettato dal prestatore di servizi di pagamento corrisponda
> all'importo originale dell'operazione di pagamento e all'identità del beneficiario
> concordato dal pagatore all'avvio dell'operazione; che qualsiasi modifica dell'importo o
> del beneficiario comporti l'invalidazione del codice di autenticazione; che la
> riservatezza, l'autenticità e l'integrità dell'importo e del beneficiario siano
> protette." [RTS Art. 5](https://eur-lex.europa.eu/eli/reg_del/2018/389/2023-09-12)

Il parere dell'EBA del 2019 (EBA-Op-2019-06) ribadisce che il collegamento dinamico lega
l'autenticazione all'importo e al beneficiario, richiede l'indipendenza dei fattori e
accetta le chiavi crittografiche legate al dispositivo come elemento di possesso laddove
esista un legame univoco con il dispositivo. Sottolinea inoltre l'integrità di ciò che
viene visualizzato al pagatore durante l'autenticazione.
[Parere dell'EBA 2019](https://www.eba.europa.eu)

### 1.2 Storia del collegamento dinamico

![storia del collegamento dinamico](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/history_dynamic_linking_3c121b5d88.png)

Prima della [PSD2](https://www.corbado.com/blog/psd2-passkeys), molte banche si affidavano a OTP via SMS o a
liste di TAN stampate che spesso non mostravano l'importo o il beneficiario durante la
fase di approvazione. Questa lacuna rendeva più facile ingannare i clienti per far loro
autorizzare trasferimenti non desiderati una volta che le credenziali erano state rubate.
Il collegamento dinamico è stato introdotto per colmare questa lacuna, garantendo che il
pagatore sia informato dell'importo e del beneficiario esatti al momento
dell'autenticazione e rendendo il codice di autenticazione specifico per quei dettagli, in
modo che qualsiasi modifica lo invalidi (RTS Art. 5(1)(a-d)). Laddove l'SMS fa parte del
flusso, gli [issuer](https://www.corbado.com/glossary/issuer) devono anche garantire la riservatezza,
l'autenticità e l'integrità dell'importo/beneficiario e del codice in tutte le fasi
dell'autenticazione (Q\&A 2018_4414; RTS Art. 5(2)). Le approvazioni in-app di oggi (ad
esempio, "Vuoi autorizzare 100 USD a Mario Rossi tramite
[Face ID](https://www.corbado.com/faq/is-face-id-passkey)?") implementano questo principio del "ciò che vedi è
ciò che firmi" in modo intuitivo per il cliente.

### 1.3 Il collegamento dinamico oggi: notifiche push e biometria locale

![notifica push per collegamento dinamico](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/dynamic_linking_push_notification_f11e26ca47.png)

Oggi, sui dispositivi mobili, dominano due modelli. Il primo è una notifica push che può
portare il cliente direttamente nell'app tramite un deep-link per rivedere i dettagli
della transazione e approvarla. Le autorità di vigilanza hanno chiarito che la notifica
push può servire come prova dell'elemento di possesso se sono in atto i controlli
dell'Articolo 7 per mitigare l'uso non autorizzato e prevenire la replicazione, e se il
percorso complessivo è conforme alle RTS; tuttavia, i rischi di ingegneria sociale
persistono e dovrebbero essere affrontati nella UX (Q\&A 2019_4984; RTS Art. 7).

![biometria locale per collegamento dinamico](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/dynamic_linking_local_biometrics_36dbc6eff7.png)

Il secondo modello prevede approvazioni che utilizzano la biometria nativa del dispositivo
(con un PIN come fallback) per eseguire una verifica dell'utente a livello locale e
sbloccare un'operazione con chiave privata. La chiave privata risiede in un ambiente
hardware sicuro (Secure Enclave/TEE/TPM) e firma una challenge. Questo si allinea
perfettamente con la [SCA](https://www.corbado.com/it/blog/psd2-passkey): inerenza (biometria) più possesso,
provato dal legame con il dispositivo e da una chiave crittografica legata al dispositivo
(EBA-Op-2019-06, parr. 25, 35-37). Per i pagamenti a distanza, il codice deve essere
collegato dinamicamente all'importo e al beneficiario e tali dettagli devono essere
mostrati al pagatore prima della verifica dell'utente (RTS Art. 5). Se entrambi i fattori
si trovano su un unico dispositivo, è necessario implementare ambienti di esecuzione
sicuri e separati e controlli di integrità in modo che la compromissione di uno non
comprometta l'altro (RTS Art. 9(2)-(3)).

### 1.4 Come la biometria locale con PKI implementa il collegamento dinamico

Dietro le quinte, la [biometria locale](https://www.corbado.com/it/blog/passkey-biometria-locale) non "autentica
direttamente alla banca". Invece, il dato biometrico (o il PIN di fallback) esegue una
verifica dell'utente sul dispositivo e controlla l'accesso a una chiave privata non
esportabile memorizzata in un modulo di [sicurezza](https://www.corbado.com/it/faq/exchange-criptovalute-passkey)
basato su hardware. Quando il pagatore approva, il dispositivo utilizza quella chiave
privata per produrre una firma digitale su una challenge fornita dalla banca. Se la banca
deriva o associa quella challenge a un'istantanea canonica della transazione (importo,
beneficiario, identificatori), allora la firma risultante funziona come un codice di
autenticazione specifico per quei dettagli. Qualsiasi modifica invaliderà il codice perché
l'istantanea memorizzata non corrisponde più o, in design più avanzati, perché la
derivazione della challenge cambia. La parte relativa alla consapevolezza del pagatore
rimane un requisito di UX: mostrare l'importo e il beneficiario in una vista controllata
dalla banca immediatamente prima della verifica dell'utente. Insieme, questo soddisfa i
requisiti dell'RTS Art. 5 su consapevolezza, specificità/unicità e invalidazione in caso
di modifica, mentre i controlli dell'Articolo 7 e il legame con il dispositivo provano
l'elemento di possesso.

![biometria e collegamento dinamico](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/biometrics_dynamic_linking_4ee6cf3e76.png)

## 2. Perché le passkey sono conformi alla SCA (legate al dispositivo e sincronizzate)

- **Possesso (chiavi legate al dispositivo e sincronizzate)**: Le chiavi private delle
  passkey sono memorizzate in hardware sicuro
  (TEE/[Secure Enclave](https://www.corbado.com/glossary/secure-enclave)/TPM). Le passkey legate al dispositivo
  non sono esportabili, in linea con le aspettative dell'EBA per un legame univoco con il
  dispositivo (EBA-Op-2019-06, parr. 25, 35-37). Anche le
  [passkey sincronizzate](https://www.corbado.com/it/blog/passkey-device-bound-vs-sincronizzate) possono provare
  il possesso a ogni autenticazione, a condizione che il legame con il dispositivo e i
  controlli anti-replicazione siano efficaci; i regolatori hanno sottolineato la necessità
  di un collegamento affidabile tra l'elemento e il dispositivo (EBA-Op-2019-06; RTS Art.
  7\).
- **Inerenza/conoscenza (Verifica dell'utente)**: La verifica dell'utente tramite
  biometria (inerenza) o PIN del dispositivo (conoscenza) attiva la chiave a livello
  locale. In combinazione con il possesso, si tratta di una vera
  [autenticazione a due fattori (2FA)](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-two-factor-authentication)
  con indipendenza dei fattori. La violazione di uno non compromette l'altro.

## 3. Le passkey soddisfano i requisiti del collegamento dinamico?

Il collegamento dinamico consiste nel **legare l'autenticazione alla transazione**. La
domanda per una banca è: se permettiamo a un utente di approvare un pagamento tramite
passkey (anziché, ad esempio, un OTP o un dispositivo di firma), possiamo garantire che
questa approvazione sia specifica per l'importo e il beneficiario previsti e non possa
essere riutilizzata o manipolata?

Ci sono due opzioni per implementare il collegamento dinamico con le passkey:

- **Collegamento lato server (standard):** Generare una challenge WebAuthn unica che il
  backend associa all'importo e al beneficiario esatti. L'utente vede "€X a Y" in una
  vista controllata dalla banca e approva con una passkey. La risposta viene accettata
  solo per quella transazione. Qualsiasi modifica la invalida.
- **Inclusione crittografica (avanzata):** Incorporare un hash dell'importo/beneficiario
  nella challenge in modo che la firma si impegni sui dati della transazione. Questo non è
  richiesto dalle RTS ma aggiunge la garanzia che anche eventuali sostituzioni nel backend
  fallirebbero la verifica.

**Nota esplicita sulla conformità:** Le RTS **non** richiedono che il "codice di
autenticazione" del collegamento dinamico sia calcolato sul dispositivo del pagatore. Un
[PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) può generarlo e convalidarlo sul
**server** a condizione che l'**importo/beneficiario** siano protetti e che **qualsiasi
modifica** invalidi il codice (vedi EBA Q\&A 2020_5366 sulla posizione/tempistica del
codice). Questo è il nostro approccio di **collegamento dinamico lato server (standard)**.

Entrambi producono un "codice di autenticazione" unico e non riutilizzabile, specifico per
la transazione. Il principale avvertimento è la **consapevolezza del pagatore**: WebAuthn
di per sé non prova cosa è stato visualizzato. L'integrità della visualizzazione deve
provenire da un'interfaccia utente controllata dalla banca.

### 3.1 Considerazioni sulla consapevolezza del pagatore

L'RTS Articolo 5 richiede che il pagatore veda l'importo e il beneficiario durante
l'autenticazione. WebAuthn non attesta ciò che è stato mostrato. In teoria, se l'app o il
sistema operativo sono compromessi, un utente potrebbe essere ingannato mentre l'
[authenticator](https://www.corbado.com/glossary/authenticator) firma comunque. Analizzeremo di seguito in
dettaglio come questo rischio si manifesta nella realtà e perché non è un vero rischio per
la [sicurezza](https://www.corbado.com/it/faq/exchange-criptovalute-passkey), ma piuttosto un problema di
interpretazione della normativa.

**Controlli di integrità della visualizzazione che applichiamo:**

- Una vista controllata dalla banca mostra **importo + beneficiario**: **blocchiamo**
  l'invocazione della passkey se la vista è oscurata o non a fuoco.
- **Rilevamento di overlay/manomissioni** in app/web: nessun prompt di passkey da
  [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) nascosti.
- **Controllo dell'integrità/attestazione del dispositivo**: negare o richiedere un
  passaggio di verifica superiore su segnali di dispositivo rooted/jailbroken/compromesso.
- **Approvazione atomica** rispetto a un'**istantanea** di importo/beneficiario conservata
  sul server: è richiesta una nuova challenge a ogni modifica dei parametri.

**Sull'inclusione crittografica:** Le estensioni di "visualizzazione della transazione" di
WebAuthn (SPC) **non sono ampiamente supportate** oggi. La nostra base di partenza
portabile è il **legame lato server**, rafforzato derivando la challenge dall'istantanea
della transazione (es. H(importo || beneficiario || ID transazione || nonce)) in modo che
la firma si **impegni** su quei valori.

### 3.2 Equivalenza normativa: biometria locale con PKI e passkey

Entrambi i modelli utilizzano la crittografia a chiave pubblica con chiavi di dispositivo
non esportabili, ed entrambi si basano sulla verifica locale dell'utente per sbloccare
l'operazione di firma. In entrambi i casi, la banca garantisce la consapevolezza del
pagatore mostrando l'importo e il beneficiario in una vista controllata dalla banca
immediatamente prima della verifica dell'utente, e assicura la specificità legando il
codice di autenticazione a quei dettagli — invalidandolo in caso di qualsiasi modifica
(RTS Art. 5(1)(a-d)). Le RTS sono tecnologicamente neutrali e non richiedono che
l'importo/beneficiario siano visualizzati all'interno di una finestra di dialogo
biometrica del sistema operativo; richiedono la visualizzazione al pagatore e il legame
del codice (RTS Art. 5). Quando entrambi gli elementi della [SCA](https://www.corbado.com/it/blog/psd2-passkey)
vengono eseguiti su un unico dispositivo, i requisiti di integrità e separazione
dell'Articolo 9 si applicano allo stesso modo (RTS Art. 9(2)-(3)). Infine, la posizione
del calcolo del collegamento dinamico è flessibile: può essere eseguito lato server se
l'integrità è preservata e qualsiasi modifica invalida il codice (Q\&A 2020_5366). Queste
sono le stesse condizioni in cui i regolatori già accettano la
[biometria locale](https://www.corbado.com/it/blog/passkey-biometria-locale) con PKI — pertanto, le passkey,
implementate con gli stessi controlli di consapevolezza del pagatore e di legame,
dovrebbero essere accettate su base equivalente.

### 3.3 Le passkey e l'intento del collegamento dinamico

Quindi, le passkey semplici secondo lo standard WebAuthn soddisfano l'intento del
collegamento dinamico? **In parte:**

- **Attacchi MITM/di rete:** Sì. Il legame con l'origine e le firme per singola challenge
  prevengono la manomissione e il replay.
- **Integrità della transazione:** Sì. L'associazione lato server o l'hashing della
  challenge garantiscono che solo l'importo/beneficiario originale supereranno la
  verifica.
- **Consenso del pagatore:** Più difficile. Le passkey non hanno una visualizzazione a
  livello di [authenticator](https://www.corbado.com/glossary/authenticator). L'inganno dell'interfaccia utente
  su dispositivi compromessi potrebbe essere possibile. È necessario costruire qualcosa in
  più per garantire il consenso del pagatore.

**Perché il collegamento dinamico è ancora necessario con le passkey**

- **Legale:** La PSD2 Art. 97(2) e le RTS Art. 5 impongono il collegamento dinamico per
  **tutte le iniziazioni di pagamento a distanza**. Non ci sono eccezioni per i metodi
  resistenti al phishing.
- **Sicurezza:** Le passkey eliminano il **phishing cross-origin**, ma da sole non
  **provano cosa è stato visualizzato** al pagatore. Il collegamento dinamico e i
  controlli di integrità della visualizzazione garantiscono che l'**importo/beneficiario
  specifico** che l'utente ha visto siano quelli che la banca esegue e che **qualsiasi
  modifica invalidi** l'approvazione.

**In sintesi, le passkey possono soddisfare il collegamento dinamico** quando sono
strettamente legate ai dati della transazione e abbinate a meccanismi di visualizzazione
affidabili. La sfida residua è provare ciò che l'utente ha effettivamente visto.

## 4. Come Corbado implementa il collegamento dinamico con le passkey

Corbado offre una soluzione conforme al collegamento dinamico che affronta esplicitamente
le considerazioni sul consenso del pagatore di cui sopra.

### 4.1 Soluzione end-to-end: flusso, tecnologia, UX e conformità

// TODO: FORNIRE MOCKUP DA KARUNA E DESCRIVERLI

Flusso del processo:

- **Una visualizzazione controllata dalla banca** mostra al pagatore l'importo e il
  beneficiario esatti. Nessun prompt di passkey viene mostrato a meno che questa vista non
  sia visibile.
- **Autenticazione:** il client invoca WebAuthn con una challenge unica e legata alla
  transazione canonizzata. L'[authenticator](https://www.corbado.com/glossary/authenticator) esegue la verifica
  dell'utente (biometria o PIN del dispositivo) e firma la challenge e l'origine.
- **Verifica sul server:** il backend verifica l'hash dell'ID RP e l'origine, abbina la
  challenge alla transazione memorizzata, controlla i flag UV, impone l'uso singolo e la
  scadenza, e confronta l'istantanea di importo/beneficiario memorizzata.
- **Approvazione e audit:** solo allora la transazione viene approvata atomicamente.
  Qualsiasi discrepanza/modifica viene rifiutata e richiede una nuova autenticazione.
  Viene salvato un registro di audit immutabile (ID credenziale, authenticatorData,
  [clientDataJSON](https://www.corbado.com/glossary/clientdatajson), firma, challenge e importo/beneficiario
  canonizzati), opzionalmente concatenato con hash per la prova di manomissione.
- **Controllo dell'integrità del dispositivo:** Valutare i segnali di integrità e
  [attestazione](https://www.corbado.com/it/glossary/attestation) del dispositivo: negare o richiedere un
  passaggio di verifica superiore se il dispositivo è rooted/jailbroken/compromesso.
- **Canonizzazione del beneficiario:** Mostrare un'etichetta amichevole (es. "ACME
  S.p.A."), ma legare e verificare rispetto a un **identificatore canonico del
  beneficiario** (es. IBAN/BIC o altro schema unico).

Dettagli tecnici:

- **Backend:** creare un oggetto transazione con dati canonizzati (es. valuta/decimali
  normalizzati; IBAN/beneficiario canonizzati). Generare una challenge di breve durata che
  si impegna su questi valori (es. H(importo||beneficiario||ID transazione||nonce));
  memorizzarla come in attesa; esporre solo ID opachi al client.
- **Client/authenticator:** visualizzare i dettagli del pagatore in una vista controllata
  dalla banca; invocare WebAuthn (ID RP = dominio Bison) solo quando visibile; richiedere
  la verifica dell'utente; l'authenticator firma la challenge + l'origine secondo
  [WebAuthn](https://www.w3.org/TR/webauthn-3/).
- **Verifica/finalizzazione:** validare firma, hash dell'ID RP, origine/tipo, flag UV;
  anti-replay/scadenza; confrontare l'istantanea immutabile di importo/beneficiario;
  approvare atomicamente; salvare il registro di audit.
- **Derivare la challenge dall'istantanea:**
  `challenge = H(importo ‖ beneficiarioCanonico ‖ IDtransazione ‖ nonce)`

Politiche di UX:

- Chiara enfasi su importo/beneficiario; controlli di conferma/annullamento accessibili;
  timeout brevi; tentativi di ripetizione graduali sempre con una nuova challenge;
  ricevute immediate (es. "Hai approvato €X a Y"). Bloccare il prompt della passkey se la
  visualizzazione è oscurata e avvisare se i parametri cambiano prima della firma.
- Rilevare overlay/contenuti oscurati: non mostrare mai un prompt di passkey se la **vista
  della transazione non è visibile**. Rifiutare se i parametri cambiano a metà flusso e
  riavviare con una **nuova challenge**.

**Nota sulla conformità:** Questo design end-to-end soddisfa l'RTS Art. 5:
**consapevolezza del pagatore** (visualizzazione controllata dalla banca), **specificità**
e **unicità** (codice unico legato a importo/beneficiario), **invalidazione in caso di
modifica** (controlli server rigorosi) e **riservatezza/integrità** di
importo/beneficiario e del codice in tutte le fasi (RTS Art. 5(1)(a-d), 5(2); vedi anche
Q\&A 2018_4414 per l'integrità degli SMS). L'indipendenza dei fattori (Art. 7-9) è
preservata tramite il possesso legato al dispositivo e la verifica locale dell'utente su
dispositivi multiuso con protezioni appropriate (RTS Art. 9(2)-(3)).

_Nota:_\* per i flussi web, Corbado adotterà opzionalmente la
[Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) se/quando Apple fornirà
un supporto ampio, aggiungendo una visualizzazione fidata mediata dal browser che attesta
crittograficamente importo e beneficiario.

## 5. Rischi residui e controlli compensativi

**Preoccupazione: Attacchi di phishing** **Risposta:** Le passkey sono resistenti al
phishing per design: sono legate all'origine legittima e non comportano segreti condivisi,
quindi le credenziali non possono essere raccolte su un sito falso, a differenza degli
OTP. Un utente malintenzionato che inoltra il traffico a un dominio simile non può
ottenere una firma valida per l'origine della banca. Il collegamento dinamico contribuisce
meno in questo vettore, ma rimane obbligatorio per garantire che ogni approvazione sia
unica per l'importo e il beneficiario previsti. Misure complementari (formazione sul
phishing, chiara separazione tra approvazioni di login e di pagamento, punteggio di
anomalia/rischio per contesti di pagamento insoliti) riducono ulteriormente l'esposizione.

**Preoccupazione: Ingegneria sociale / Frode APP (Authorized Push Payment)** **Risposta:**
Nessun authenticator può impedire completamente a un utente di autorizzare un pagamento
con false pretese (es. truffe del "conto sicuro"). Il collegamento dinamico garantisce che
l'utente veda esplicitamente il beneficiario e l'importo e fornisce una forte prova del
consenso, ma non può prevalere su un pagatore convinto. Le compensazioni includono avvisi
contestuali (nuovo beneficiario, primo trasferimento di importo elevato), periodi di
riflessione o esecuzione ritardata per beneficiari ad alto rischio, verifica più forte del
beneficiario e controlli di verifica superiori (conferma extra) su segnali di rischio. Le
notifiche post-pagamento e i canali rapidi per le contestazioni aiutano a rilevare e
contenere i danni. Aggiungiamo **avvisi contestuali** in tempo reale (es. nuovo
beneficiario, primo trasferimento di importo elevato), **periodi di riflessione** per
beneficiari ad alto rischio, una **verifica più forte del beneficiario** e **notifiche
post-pagamento** ("Hai approvato €X a Y") per accelerare il rilevamento e la risposta.

**Preoccupazione: Malware o compromissione del dispositivo** **Risposta:** Le chiavi
private sono **non esportabili** e richiedono una **verifica locale dell'utente** per ogni
firma, quindi il [malware](https://www.corbado.com/glossary/malware) non può semplicemente esfiltrare le
credenziali. Il rischio realistico è l'**inganno dell'interfaccia utente** su un sistema
operativo completamente compromesso. Mitighiamo con un'interfaccia utente
sicura/verificata (es. conferme protette), controlli di integrità del
dispositivo/[attestazione](https://www.corbado.com/it/glossary/attestation) e blocco dei dispositivi ad alto
rischio, e conferme fidate come [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) o un'estensione
di conferma quando disponibile. Se compaiono indicatori di compromissione (rilevamento di
overlay, root/jailbreak), utilizziamo una ri-verifica fuori banda o neghiamo l'esecuzione.
Nessun metodo per i consumatori è perfetto su un dispositivo completamente controllato da
malintenzionati, ma questi controlli restringono drasticamente la finestra di opportunità.

**Preoccupazione: Man-in-the-browser / dirottamento della sessione** **Risposta:**
Estensioni dannose o script iniettati possono avviare azioni sull'origine legittima. Le
passkey legate all'origine fermano il phishing cross-site. Il **collegamento dinamico**
garantisce che le modifiche dietro le quinte a importo/beneficiario **falliscano**.
Rafforziamo il canale tramite controlli CSP/anti-manomissione e richiedendo una **nuova
challenge unica** per ogni conferma.

**Preoccupazione: Minaccia interna o manomissione lato server** **Risposta:** La risposta
di autenticazione è legata in modo univoco all'importo/beneficiario originale, quindi
qualsiasi sostituzione lato server fallisce la convalida. Manteniamo registri di
collegamento immutabili e a prova di manomissione (challenge, credenziale, firma e
importo/beneficiario canonizzati) per audit/non ripudio. Applichiamo la separazione dei
compiti e controlli a quattro occhi sui percorsi critici di elaborazione dei pagamenti per
ridurre il rischio interno.

**Preoccupazione: Dispositivi rubati / furto di credenziali** **Risposta:** Il solo
possesso del dispositivo non è sufficiente: è richiesta la verifica dell'utente
(biometria/PIN) per ogni firma, con limiti di tentativi e blocchi a livello di sistema
operativo. Ogni pagamento richiede una nuova challenge specifica per la transazione; i
token di sessione generici non possono autorizzare pagamenti arbitrari. Aggiunte come la
revoca remota del dispositivo, la verifica superiore all'uso di un nuovo dispositivo, i
controlli di geovelocità e le notifiche ("Hai autorizzato €X a Y") limitano ulteriormente
l'abuso.

**In generale:** le passkey riducono materialmente i rischi di phishing e replay; il
collegamento dinamico rimane essenziale per garantire l'integrità della transazione,
legare le approvazioni a importo/beneficiario e fornire una forte prova del consenso
informato negli scenari di minaccia rimanenti.

## 6. FAQ sulla conformità

**Domanda 1:** Come possiamo provare che l'utente ha effettivamente visto e accettato
l'importo e il beneficiario quando usa una passkey? **Risposta:** Imponiamo la
**visualizzazione al pagatore** in una vista controllata dalla banca e leghiamo
l'approvazione a un'**istantanea lato server** di importo/beneficiario.
L'[assertion](https://www.corbado.com/glossary/assertion) della passkey (authenticatorData,
[clientDataJSON](https://www.corbado.com/glossary/clientdatajson), firma) è accettata **solo** per la challenge
derivata da quella istantanea; **qualsiasi modifica** richiede una nuova challenge. Il
nostro **audit a prova di manomissione** collega l'[assertion](https://www.corbado.com/glossary/assertion) a "€X
al Beneficiario-ID Y" e registra che il nostro sistema non avrebbe proceduto se i dettagli
fossero stati diversi. Dove supportato, la **SPC** aggiunge una **prova crittografica**
che l'utente ha confermato i dettagli visualizzati.

**Domanda 1:** Come possiamo provare che l'utente ha effettivamente visto e accettato
l'importo e il beneficiario quando usa una passkey? **Risposta:** Questa è essenzialmente
la questione del **non ripudio**. Sotto la PSD2, il collegamento dinamico era inteso a
garantire che l'utente fosse consapevole di ciò che stava approvando. Con una passkey, la
prova che conserviamo è la firma crittografica (codice di autenticazione) e i dati
associati (a quale importo/beneficiario era legata sul nostro server). Per policy,
mostriamo i dettagli della transazione all'utente nell'app o nella pagina web prima che si
autentichi. Registriamo quella schermata/vista e la successiva autenticazione con passkey
andata a buon fine per quella specifica transazione. In caso di controversia, possiamo
dimostrare che il dispositivo dell'utente ha prodotto una firma valida per una challenge
associata a (ad es.) "€100 ad ACME Corp." e che il nostro sistema non avrebbe proceduto se
un qualsiasi dettaglio fosse stato diverso. La nostra conformità si basa su una
registrazione sicura: garantiamo che i nostri sistemi siano a prova di manomissione nel
collegare la risposta della passkey ai dati della transazione.

**Domanda 2:** Cosa succede se il dispositivo o il sistema operativo sono compromessi? Può
il [malware](https://www.corbado.com/glossary/malware) manipolare la transazione o il processo della passkey?
**Risposta:** La compromissione del dispositivo è una minaccia critica in qualsiasi
scenario di [banking](https://www.corbado.com/passkeys-for-banking) digitale. Se il sistema operativo è dannoso,
potrebbe tentare di ingannare l'utente o dirottare i processi. Tuttavia, anche in questo
caso peggiore, **le passkey mantengono alcune protezioni chiave**. La chiave privata non
può essere estratta dal [malware](https://www.corbado.com/glossary/malware). Il malware non può nemmeno
impersonare l'utente presso la banca, perché non può produrre la firma della passkey senza
la biometria/PIN dell'utente. Il massimo che potrebbe fare è spingere l'utente ad
autenticare qualcosa con false pretese. Il collegamento dinamico aiuta qui richiedendo
controlli di integrità: il malware non può cambiare silenziosamente i dettagli della
transazione dopo il fatto – se lo fa, la firma non verrà verificata. Il punto più debole è
la **visualizzazione/UI**: un Trojan sofisticato potrebbe alterare ciò che l'utente vede
(es. mostrare "ACME Corp" mentre la transazione sottostante è in realtà destinata a un
altro beneficiario). Questo non è banale, specialmente se l'app della banca utilizza
framework di UI sicuri, ma è concepibile. Detto questo, se rileviamo segni di
compromissione del dispositivo (comportamento insolito, firme di malware note, ecc.),
ricorreremmo a una verifica fuori banda o negheremmo la transazione. **In sintesi:**
Nessuna soluzione è sicura al 100% se il dispositivo dell'utente è completamente
controllato da un utente malintenzionato. Le passkey e il collegamento dinamico riducono
drasticamente la superficie di attacco (un utente malintenzionato non può semplicemente
inoltrare credenziali o alterare dati di rete; dovrebbe eseguire una truffa sull'utente in
tempo reale). Se il sistema operativo fosse compromesso, il collegamento dinamico
garantisce almeno che qualsiasi discrepanza tra ciò che dovrebbe essere e ciò che viene
approvato venga rilevata dal nostro backend.

**Domanda 3:** Se viene utilizzata la biometria per sbloccare la passkey, è considerato un
fattore o due? Stiamo rispettando la regola dei due fattori? **Risposta:** Una biometria
da sola **non** è sufficiente per la [SCA](https://www.corbado.com/it/blog/psd2-passkey) – è solo un fattore di
inerenza. Tuttavia, in un'[implementazione](https://www.corbado.com/it/blog/passkeys-cheat-sheet) di passkey la
biometria non è da sola: il possesso del dispositivo è l'altro fattore. La biometria
dell'utente sblocca la chiave privata memorizzata sul dispositivo. Possesso e inerenza
sono due categorie distinte. Questo è analogo a come molte app di
[banking](https://www.corbado.com/passkeys-for-banking) soddisfano già la SCA: hai il telefono (possesso) e usi
la tua impronta digitale o il tuo volto per sbloccare l'app (inerenza). L'EBA ha
esplicitamente riconosciuto le combinazioni di legame con il dispositivo più biometria
come SCA conforme. Lo scenario delle passkey è esattamente quella combinazione. Se
l'utente opta per l'uso di un PIN invece della biometria per sbloccare la passkey, allora
si tratta di possesso + conoscenza, anch'esso conforme. Imponiamo la verifica dell'utente
su tutte le operazioni con passkey (il che significa che l'utente deve fornire
biometria/PIN ogni volta), quindi non c'è una situazione in cui basta avere il
dispositivo. Pertanto, ogni autorizzazione di pagamento tramite passkey è un evento a due
fattori secondo le definizioni della PSD2.

**Domanda 4:** Un utente malintenzionato potrebbe riutilizzare un'autenticazione con
passkey o bypassare in qualche modo il collegamento dinamico manipolando i dati in
transito? **Risposta:** No. È qui che le passkey e il collegamento dinamico lavorano
insieme in modo forte. Ogni autenticazione WebAuthn produce una **firma unica** che è
legata alla challenge (che generiamo per transazione) ed è limitata al nostro dominio. Un
utente malintenzionato non può riprodurre quella firma per una transazione diversa. La
firma stessa incorpora il nonce della challenge ed è valida solo per ciò per cui è stata
originariamente emessa. Se un utente malintenzionato intercettasse la comunicazione di
rete, non potrebbe alterare l'importo o il beneficiario senza invalidare la firma (poiché
la challenge o il contesto della transazione non corrisponderebbero più). Questa è
effettivamente la protezione MITM di cui abbiamo discusso. Inoltre, le firme delle passkey
includono dati di origine – non verranno verificate se non inviate al nostro esatto sito
web/origine dell'app, quindi il phishing o il reindirizzamento non funzioneranno. In
breve, qualsiasi tentativo di manipolazione invalida il codice di autenticazione, secondo
le regole del collegamento dinamico. Questo è in realtà più sicuro di alcuni attuali
flussi basati su OTP, in cui gli utenti a volte approvano un codice generico e c'è il
rischio che la richiesta sia stata manomessa. Con le passkey, leghiamo crittograficamente
l'autenticazione dell'utente alla sessione/transazione specifica.

**Domanda 5:** Ci sono pareri normativi noti su WebAuthn/passkey per la SCA? Siamo sicuri
che i regolatori accetteranno le passkey come conformi? **Risposta:** Al momento, l'EBA
non ha pubblicato esplicitamente pareri su WebAuthn o sul termine "passkey" nelle sue Q\&A
o linee [guida](https://www.corbado.com/it/blog/passkeys-cheat-sheet). Tuttavia, sulla base dei principi che
hanno stabilito, le passkey rientrano chiaramente nei metodi accettabili. Il parere
dell'EBA del 2019 ha essenzialmente anticipato approcci simili a [FIDO2](https://www.corbado.com/glossary/fido2):
per il possesso, menzionano esplicitamente lo **"scambio di chiavi pubbliche/private" con
un corretto legame con il dispositivo come prova del possesso**. Una passkey WebAuthn è
esattamente questo – una coppia di chiavi pubblica/privata, con la metà privata legata in
modo sicuro al dispositivo. Hanno anche dato un cenno di approvazione alla "firma generata
da un dispositivo" come prova di possesso valida. Quindi, sebbene non abbiano usato il
termine passkey, il metodo è coperto dai loro esempi. Abbiamo anche osservato che i
principali operatori di pagamento in Europa stanno procedendo con implementazioni di
passkey (ad es. [PayPal](https://www.corbado.com/blog/paypal-passkeys)), il che indica un livello di fiducia che
questo sia conforme alla PSD2. Questo esempio dimostra che le passkey vengono accettate
come parte di flussi SCA conformi, a condizione che il collegamento dinamico e i requisiti
generali siano soddisfatti.

**Domanda 6:** Abbiamo ancora bisogno del collegamento dinamico se le passkey sono
resistenti al phishing? **Risposta:** Sì. Le passkey eliminano il **phishing
cross-origin**, ma la PSD2 impone ancora il **collegamento dinamico** per l'iniziazione di
pagamenti a distanza. Il collegamento dinamico lega l'**importo e il beneficiario
specifici** al risultato della SCA e **invalida qualsiasi modifica**, affrontando
l'integrità dell'autorizzazione oltre al phishing (es. sostituzione MITM/MITB/TPP).

## 7. Conclusione: conformità al collegamento dinamico e risultati migliori

La soluzione di Corbado è conforme al collegamento dinamico e alla PSD2. La
visualizzazione al pagatore pre-autenticazione, la challenge unica legata all'importo e al
beneficiario, la verifica rigorosa sul server e l'audit immutabile soddisfano insieme i
requisiti dell'RTS Art. 5 su consapevolezza del pagatore, unicità/specificità,
invalidazione in caso di modifica e integrità/riservatezza. L'indipendenza dei fattori è
preservata attraverso il possesso legato al dispositivo e la verifica dell'utente
(biometria o PIN), in linea con le linee [guida](https://www.corbado.com/it/blog/passkeys-cheat-sheet) dell'EBA.

Rispetto ai metodi OTP/SMS di oggi, Corbado offre una
[sicurezza](https://www.corbado.com/it/faq/exchange-criptovalute-passkey) e risultati per l'utente materialmente
migliori: resistenza al phishing e al replay, prevenzione della manomissione silenziosa
dei parametri, prove non ripudiabili più forti e attrito ridotto attraverso la verifica
sul dispositivo. I rischi residui (es. ingegneria sociale, dispositivi compromessi) sono
mitigati con controlli concreti e sono più limitati rispetto ai metodi tradizionali. Per
il web, Corbado può adottare [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) quando il supporto
delle piattaforme (in particolare Apple) sarà ampio, aggiungendo una prova crittografica
della visualizzazione senza modificare la posizione di conformità di base.

In breve, l'autorizzazione delle transazioni basata su passkey di Corbado soddisfa la
lettera e lo spirito del collegamento dinamico della PSD2 e migliora la resilienza alle
frodi e la verificabilità rispetto agli approcci tradizionali, mantenendo al contempo un
percorso chiaro verso miglioramenti futuri (SPC) man mano che l'ecosistema matura.

In pratica, le passkey soddisfano il collegamento dinamico quando facciamo tre
[cose](https://www.corbado.com/blog/webauthn-pubkeycredparams-credentialpublickey): mostriamo l'importo e il
beneficiario al pagatore prima della verifica dell'utente; generiamo un codice di
autenticazione che è specifico per quegli esatti dettagli; e invalidiamo il codice in caso
di qualsiasi modifica (RTS Art. 5(1)(a-d)). Questo rispecchia i principi che i regolatori
già accettano per la [biometria locale](https://www.corbado.com/it/blog/passkey-biometria-locale), con la
comodità aggiuntiva che le passkey sono native del sistema operativo e funzionano su
canali web e app senza un'app aggiuntiva. In combinazione con il legame all'origine, non
presentano richieste contraffatte — all'utente appaiono solo prompt legittimi dal sito o
dall'app originale.