Sign up to the Passkey Intelligence Webinar on Oct. 8Sign up to the Passkey Intelligence Webinar & learn how to get +80% Passkey AdoptionLa 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.
Vincent
Created: October 2, 2025
Updated: October 3, 2025
See the original blog version in English here.
Want to learn how to get +80% Passkey Adoption?
Join our Passkey Intelligence Webinar on October 8.
L'approccio di Corbado abbina le passkey resistenti al phishing (SCA) a una visualizzazione controllata dalla banca e a un collegamento dinamico lato server per soddisfare l'Art. 5 delle norme tecniche di regolamentazione (RTS) della PSD2 ("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 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 a distanza anche con le passkey (PSD2 Art. 97(2); RTS Art. 5). Le RTS non richiedono che il "codice di autenticazione" del collegamento dinamico 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 cross-origin (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.
Recent Articles
Chiarimento — phishing vs. autorizzazione: Le passkey sono legate all'origine, quindi i domini falsi non possono ottenere firme valide. Tuttavia, la PSD2 richiede ancora il collegamento dinamico per i pagamenti 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 affronta l'integrità dell'autorizzazione (incluse le sostituzioni MITM/MITB/TPP), non solo il phishing.
PSD2 Articolo 97(2): "Per quanto riguarda l'avvio di operazioni di pagamento elettronico, gli Stati membri assicurano che il pagatore abbia accesso a procedure di autenticazione forte del cliente che includano elementi che colleghino dinamicamente la transazione a un importo specifico e a un beneficiario specifico." PSD2 Art. 97(2)
RTS Articolo 5: "I prestatori di servizi di pagamento garantiscono che il codice di autenticazione generato sia specifico per l'importo dell'operazione di pagamento 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
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
Prima della PSD2, 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 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?") implementano questo principio del "ciò che vedi è ciò che firmi" in modo intuitivo per il cliente.
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).
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: 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)).
Dietro le quinte, la 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 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.
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:
Nota esplicita sulla conformità: Le RTS non richiedono che il "codice di autenticazione" del collegamento dinamico sia calcolato sul dispositivo del pagatore. Un PSP 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.
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 firma comunque. Analizzeremo di seguito in dettaglio come questo rischio si manifesta nella realtà e perché non è un vero rischio per la sicurezza, ma piuttosto un problema di interpretazione della normativa.
Controlli di integrità della visualizzazione che applichiamo:
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.
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 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 con PKI — pertanto, le passkey, implementate con gli stessi controlli di consapevolezza del pagatore e di legame, dovrebbero essere accettate su base equivalente.
Quindi, le passkey semplici secondo lo standard WebAuthn soddisfano l'intento del collegamento dinamico? In parte:
Perché il collegamento dinamico è ancora necessario con le passkey
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.
Corbado offre una soluzione conforme al collegamento dinamico che affronta esplicitamente le considerazioni sul consenso del pagatore di cui sopra.
// TODO: FORNIRE MOCKUP DA KARUNA E DESCRIVERLI
Flusso del processo:
Dettagli tecnici:
challenge = H(importo ‖ beneficiarioCanonico ‖ IDtransazione ‖ nonce)Politiche di UX:
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 se/quando Apple fornirà un supporto ampio, aggiungendo una visualizzazione fidata mediata dal browser che attesta crittograficamente importo e beneficiario.
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 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 e blocco dei dispositivi ad alto rischio, e conferme fidate come 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.
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 della passkey (authenticatorData, 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 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 manipolare la transazione o il processo della passkey? Risposta: La compromissione del dispositivo è una minaccia critica in qualsiasi scenario di 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. 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 – è solo un fattore di inerenza. Tuttavia, in un'implementazione 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 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. 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: 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), 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).
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 dell'EBA.
Rispetto ai metodi OTP/SMS di oggi, Corbado offre una sicurezza 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 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: 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, 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.
Share this article
Related Articles
Table of Contents
