Dynamic Linking con le Passkey: Secure Payment Confirmation (SPC)

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

Get Report

Nella nostra serie completa in quattro parti (parte 1, parte 2, parte 3 e parte 4) sulla PSD2, abbiamo analizzato come le passkey si integrano con le misure di strong customer authentication (SCA) introdotte dalla PSD2. Ci siamo concentrati in particolare sugli elementi di autenticazione richiesti dalla SCA per accedere alle applicazioni bancarie. I requisiti della SCA non si applicano solo all'accesso alle applicazioni, ma anche all'avvio e alla firma di transazioni di pagamento elettronico a distanza. Inoltre, questi requisiti impongono l'uso di un meccanismo noto come collegamento dinamico. In questo articolo spiegheremo cos'è il collegamento dinamico ed esamineremo come le passkey possono essere utilizzate efficacemente per implementare questo meccanismo, sia oggi che in futuro.

Il collegamento dinamico è un requisito di sicurezza previsto dalla direttiva PSD2 e dalla sua appendice di attuazione, i Regulatory Technical Standards (RTS). Il concetto è stato introdotto per aumentare la sicurezza dei pagamenti elettronici, garantendo che ogni transazione sia collegata in modo univoco a un importo specifico e a un beneficiario specifico tramite un codice di autenticazione. Questo collegamento impedisce qualsiasi modifica dei dettagli della transazione una volta che è stata autenticata dal pagatore, riducendo così il rischio di frode. I pagamenti elettronici includono i bonifici bancari nei software di online banking, ma anche i pagamenti con carta di credito sui siti dei merchant.

Secondo la direttiva PSD2 e i relativi RTS, il collegamento dinamico è definito come un processo che garantisce che "il codice di autenticazione generato sia specifico per l'importo e il beneficiario concordati dal pagatore al momento dell'avvio della transazione di pagamento elettronico" (articolo 97, paragrafo 2, della PSD2). Ciò significa che qualsiasi modifica ai dettagli del pagamento invaliderebbe il codice di autenticazione, richiedendo una nuova autenticazione.

Il collegamento dinamico è fondamentale nella PSD2, poiché affronta direttamente i rischi per la sicurezza associati alle transazioni elettroniche a distanza, che sono particolarmente vulnerabili a diversi tipi di frode, come gli attacchi man-in-the-middle.

Proteggendo la transazione in questo modo, il collegamento dinamico riduce significativamente la possibilità di transazioni non autorizzate.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

L'articolo 5 degli RTS approfondisce i requisiti per il codice di autenticazione nel collegamento dinamico. Tali requisiti includono:

• Consapevolezza del pagatore: il pagatore è messo a conoscenza dell'importo della transazione di pagamento e del beneficiario.

• Il codice di autenticazione è unico: il codice di autenticazione generato per ogni transazione deve essere unico e non riutilizzabile per nessun'altra transazione.

• Il codice di autenticazione è specifico: i codici generati e il codice accettato devono essere specifici per l'importo della transazione e l'identità del beneficiario, come confermato dal pagatore. Qualsiasi modifica all'importo o al beneficiario comporta l'invalidazione del codice di autenticazione.

• Trasmissione sicura: la riservatezza, l'autenticità e l'integrità dell'importo della transazione e del beneficiario sono mantenute in tutte le fasi dell'autenticazione, comprese la generazione, la trasmissione e l'uso del codice di autenticazione.

Una volta definiti questi requisiti tecnici del collegamento dinamico, nella prossima sezione vedremo come le passkey possano essere d'aiuto come nuova tecnologia. Esploreremo il loro potenziale per semplificare e rendere più sicuri i processi di autenticazione dei pagamenti, rendendo il collegamento dinamico non solo più robusto, ma anche più facile da usare.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

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

Le aziende si affidano a Corbado per proteggere i propri utenti e rendere gli accessi più fluidi con le passkey. Richiedi subito la tua consulenza gratuita sulle passkey.

Richiedi una consulenza gratuita

Analizziamo innanzitutto le diverse opzioni su come le passkey possono essere utilizzate nel collegamento dinamico.

In questo approccio, la passkey stessa funge da assertion crittografica che viene utilizzata direttamente come codice di autenticazione. La challenge emessa durante il processo di transazione viene generata per riflettere specificamente i dettagli della transazione, come l'importo e il beneficiario, e viene memorizzata insieme a tali informazioni. Quando l'utente autorizza la transazione utilizzando la propria passkey, viene generata una firma unica e crittograficamente sicura che può essere verificata e memorizzata insieme alla transazione. Questa risposta non solo funge da robusto fattore di autenticazione, ma lega anche direttamente l'approvazione ai dettagli specifici della transazione, rispettando rigorosamente i requisiti della PSD2 per il collegamento dinamico.

Become part of our Passkeys Community for updates & support.

Join

Un'integrazione più avanzata prevede la codifica di ulteriori dettagli della transazione nella challenge WebAuthn stessa (cosa che tecnicamente non è richiesta dalla PSD2/RTS). Questo metodo suggerisce di incorporare nella challenge un hash crittografico del beneficiario e dell'importo, insieme ad altri dati casuali. In questo modo, il processo di autenticazione non solo verifica l'identità dell'utente tramite la passkey, ma asserisce anche crittograficamente l'integrità dei dettagli della transazione. Questo approccio offre un ulteriore livello di sicurezza, garantendo che qualsiasi manomissione dell'importo o dei dettagli del beneficiario sia rilevabile al momento del pagamento finale. La prova crittografica diventa una parte immutabile del codice di autenticazione, aumentando la fiducia e la sicurezza in ambienti di transazione ad alto rischio (maggiori informazioni qui).

Analizziamo i limiti e le sfide di queste due opzioni.

Uno dei limiti dell'utilizzo delle passkey nel contesto del collegamento dinamico, in particolare per l'autenticazione dei pagamenti, è la mancanza di una documentazione concreta o di una garanzia che il pagatore sia stato informato accuratamente sulle informazioni del beneficiario.

Sebbene le passkey forniscano un metodo sicuro per l'autenticazione dell'utente, non verificano intrinsecamente se tutti i dettagli della transazione, specialmente quelli relativi al beneficiario, siano stati visualizzati correttamente al pagatore.

Questo problema non è esclusivo delle passkey; è una sfida comune a vari sistemi di pagamento online. Garantire che il pagatore sia pienamente consapevole e acconsenta a tutti i dettagli della transazione prima di avviare il pagamento è fondamentale per mantenere la fiducia e la sicurezza.

La limitazione più significativa dell'integrazione delle passkey nel collegamento dinamico emerge nella distinzione tra registrazione di prima parte e di terza parte.

Cos'è un contesto di pagamento di prima parte?

✔️ Nel contesto di pagamento di prima parte, l'utente interagisce direttamente con l'issuer/banca sul loro servizio internet e dominio. Le passkey possono essere registrate e autenticate senza problemi. Un esempio potrebbe essere una banca che registra una passkey sul proprio sito web e la utilizza per autorizzare l'avvio di un pagamento dal proprio software di online banking. In questo caso, le passkey funzionano perfettamente. La banca può garantire che la passkey venga utilizzata all'interno del suo dominio, mantenendo il controllo sull'ambiente di pagamento e sulla sicurezza della transazione.

Consulta il nostro post sul blog per l'implementazione delle passkey di Mastercard in un contesto di pagamento di prima parte.

Cos'è un contesto di pagamento di terza parte?

Nel contesto di pagamento di terza parte, l'utente si trova sulla pagina di un merchant durante il processo di checkout su un dominio diverso (ad es. amazon.com) e vuole avviare una transazione con carta di credito:

• ✔️ Caso 1 – L'utente ha già una passkey dal proprio issuer/banca: Il merchant mostra un iframe dove può avvenire l'autenticazione con la passkey. L'IFRAME è mostrato dal processo sottostante 3-D Secure 2 (3DSS/EMV 3DS), già in uso per le transazioni con carta di credito che devono supportare SCA e collegamento dinamico.

• ❌ Caso 2 – L'utente non ha una passkey dal proprio issuer/banca: Anche in questo caso, il merchant mostra l'iframe. Poiché non sono ancora disponibili passkey, l'utente viene autenticato con i fattori di autenticazione esistenti (ad es. SMS OTP o l'app nativa di banking sul proprio smartphone). A questo punto, dopo un'autenticazione riuscita, sarebbe il momento ideale per registrare una passkey per l'utente, ma ciò non è consentito a causa delle restrizioni dello standard WebAuthn. La registrazione di passkey in un iframe cross-origin non è permessa (il dominio della pagina principale e dell'iframe dovrebbero essere identici). Un'iscrizione graduale come nello screenshot seguente sarebbe impossibile:

La registrazione di passkey in iframe cross-origin sarà supportata in futuro?

Sebbene le passkey offrano una buona soluzione per il collegamento dinamico in un contesto di pagamento di prima parte all'interno di un singolo dominio, nei contesti di pagamento di terza parte non sono attualmente supportate da WebAuthn Level 2. Tuttavia, la buona notizia è che il supporto per iframe cross-origin è già incorporato nella specifica WebAuthn Level 3 in corso di sviluppo (che sarà resa disponibile a livello generale entro la fine del 2024). Tuttavia, i browser devono ancora adeguarsi alla specifica:

Ad oggi, sembra che entro il 2024 la copertura per la registrazione cross-origin delle passkey potrebbe diventare una realtà nei principali browser, il che eliminerebbe la più significativa limitazione tecnica nell'uso delle passkey per i pagamenti.

Ci sono stati diversi tentativi (ad es. BasicCard, PaymentHandler o PaymentManifest) da parte di gruppi di lavoro avviati da Google presso il W3C per migliorare l'esperienza di pagamento sul web. Finora nessuno ha ottenuto una copertura di mercato e un utilizzo significativi. L'attrito nel processo di pagamento per le transazioni di ecommerce rimane una grande sfida con l'aumento della regolamentazione contro le frodi. Lo standard Secure Payment Conformation, avviato da Google e Stripe, è attualmente lo standard più promettente che si basa sullo standard WebAuthn.

La Secure Payment Confirmation (SPC) affronta tutti gli elementi importanti della SCA della PSD2, incluso il requisito del collegamento dinamico, e allo stesso tempo cerca di migliorare l'esperienza utente (UX).

• Offrire una UX nativa del browser: SPC sfrutta il browser per fornire un'esperienza di autenticazione coerente e semplificata su diversi siti di merchant e relying party. Questo approccio è inteso a migliorare la sicurezza delle transazioni oltre a quanto si ottiene tipicamente con i contenuti renderizzati in un iframe, avendo un aspetto coerente e garantendo la consapevolezza del pagatore:

Esempio da https://www.w3.org/press-releases/2023/spc-cr/

• Fornire una prova crittografica: lo standard garantisce che la prova crittografica della conferma dei dettagli di pagamento da parte dell'utente venga generata e inclusa nell'assertion WebAuthn senza la necessità di codificare le informazioni nella challenge WebAuthn.

• Consentire la registrazione di terze parti: a differenza dello standard WebAuthn Level 2, in cui la registrazione di un authenticator deve avvenire in un contesto di prima parte, SPC consente la registrazione di passkey direttamente da un iframe cross-origin. Questa funzionalità risponde a casi d'uso comuni nell'ecosistema dei pagamenti e facilita un'integrazione più semplice per merchant e processori di pagamento. Come abbiamo discusso sopra, questa funzionalità fa già parte della prossima versione dello standard sottostante e quindi probabilmente verrà rimossa in futuro da SPC.

• Autenticazione cross-origin dei pagamenti: SPC estende l'utilità di WebAuthn consentendo a qualsiasi origine di generare un'assertion per una transazione, anche se sfrutta le credenziali di un altro Relying Party (senza la necessità di lasciare la pagina). In questo caso, non è necessario nemmeno un iframe dal merchant/issuer. Questa funzione è particolarmente utile in scenari in cui più parti (merchant + issuer/banca) sono coinvolte nel processo di autenticazione e l'assertion può quindi essere trasportata al Relying Party originale (il fornitore del conto, ad es. una banca) per la verifica.

L'esempio sopra è tratto dall'Explainer di SPC e mostra il concetto di autenticazione Cross-Origin dei pagamenti: in un processo di pagamento che utilizza SPC, l'utente rimane sul sito del merchant (evidenziato in blu) per tutta la durata della transazione. Il browser web (colorato in verde) mantiene la visualizzazione dell'origine del merchant e presenta anche una finestra di dialogo predefinita e non personalizzabile con tutte le informazioni importanti per il collegamento dinamico (importo + beneficiario) per confermare la transazione. Dopo la conferma dell'utente, il sistema operativo (rappresentato in arancione) gestisce l'autenticazione biometrica necessaria per verificare la transazione.

Questi obiettivi illustrano l'impegno di SPC nel migliorare sia la sicurezza che l'esperienza utente dei pagamenti online, mirando a semplificare l'autenticazione mantenendo elevati standard di sicurezza in tutto il panorama dei pagamenti digitali.

Esaminiamo tutti i possibili flussi che SPC consentirebbe e confrontiamoli con le passkey standard, in modo da comprenderne i vantaggi.

Come possiamo vedere qui, la distinzione più importante è la registrazione sul sito web del merchant all'interno di un iframe, che non è ancora supportata dalle passkey (vedi la nostra discussione sopra), e la possibilità completamente nuova dell'autenticazione Cross-Origin. Analizziamole una per una.

Ecco un esempio di mockup della registrazione di una passkey SPC direttamente sulla pagina di Mastercard. Come puoi vedere qui, la creazione della passkey viene offerta subito dopo il completamento dell'autenticazione tramite SMS OTP, in questo caso.

In questo caso, la comunicazione assomiglierebbe a un processo di registrazione standard di passkey, poiché avviene completamente nel contesto di prima parte.

Tratto da https://developer.chrome.com/docs/payments/register-secure-payment-confirmation

Questa passkey SPC potrebbe ora essere utilizzata su un sito di un merchant per l'autenticazione, in un iframe sul sito del merchant e per l'autenticazione cross-origin (vedi sotto).

Come abbiamo discusso in precedenza, il processo di registrazione di una passkey SPC su un sito di un merchant avverrebbe tipicamente durante la transazione di pagamento, nel contesto del flusso 3-D Secure (3DS). Questo flusso è progettato per aumentare la sicurezza delle transazioni online con carta di credito e di debito, coinvolgendo un passaggio di autenticazione aggiuntivo che verifica l'identità del titolare della carta.

Durante una transazione di pagamento, quando viene avviato il flusso 3DS, il processo di autenticazione è facilitato tramite un iframe ospitato sul sito del merchant (ad es. amazon.com) ma controllato dal fornitore di servizi di pagamento o dalla banca emittente (ad es. mastercard.com). Questo iframe funge da ambiente sicuro per il cliente per autenticare la propria identità utilizzando i fattori di autenticazione esistenti.

Una volta che il cliente si autentica con successo utilizzando questi fattori convenzionali (ad es. SMS OTP o app bancaria), c'è l'opportunità di registrare una passkey SPC per le transazioni future. Poiché lo standard SPC consente la creazione di passkey cross-origin dall'interno degli iframe, questo funzionerebbe. La registrazione di questa passkey nell'iframe comporterebbe tipicamente che il cliente esegua un'azione che genera e lega la passkey alla sua carta di credito, come la verifica dell'impronta digitale o il riconoscimento facciale su un dispositivo compatibile. Tieni presente che l'iframe è controllato dal fornitore di servizi di pagamento (ad es. PayPal) o dalla banca emittente (ad es. mastercard.com). Pertanto, la passkey SPC viene creata direttamente con l'issuer/banca e non con il merchant. Il flusso semplificato sarebbe simile a questo:

Tratto da https://developer.chrome.com/docs/payments/register-secure-payment-confirmation

Su https://spc-merchant.glitch.me/, Google ha creato un'applicazione demo a cui si può accedere tramite Chrome su Windows e Mac, che illustra come funzionerebbe dall'interno di un iframe:

Permette anche di sperimentare direttamente con il sito della banca, ospitato su: https://spc-rp.glitch.me/reauth. In questo esempio, non è necessaria alcuna comunicazione fuori banda con le API tra il merchant e l'issuer/banca: tutto è gestito dal browser. L'autenticazione tramite una passkey esistente funzionerebbe allo stesso modo dall'interno dell'iframe.

Nell'esempio seguente, vediamo l'autenticazione cross-origin in cui l'utente ha già registrato una passkey SPC con Mastercard. Il sito del merchant di esempio (decorshop.com) può attivare l'autenticazione cross-origin. La differenza principale e importante è che la pagina del merchant/issuer non è mai visibile durante il processo di autenticazione. Il browser, in combinazione con il sistema operativo, presenta la UX di pagamento predefinita (fornita dall'implementazione del browser dello standard SPC) e la finestra di dialogo di autenticazione (standard WebAuthn). La comunicazione tra merchant e issuer/banca viene gestita in background.

Originale da (parzialmente modificato): https://www.w3.org/2023/Talks/mc-passkeys-20230911.pdf (Mastercard)

Originale da (parzialmente modificato): https://github.com/w3c/secure-payment-confirmation/tree/main/sequence-diagrams

Quando si utilizza l'autenticazione cross-origin, il merchant comunica con l'issuer/banca tramite una qualche forma di API per scambiare informazioni sulle credenziali esistenti (n. 2 nel diagramma di sequenza sopra). Se esistono credenziali e il browser dell'utente supporta SPC, l'autenticazione inizia. Alla fine, l'assertion viene restituita fino all'issuer/banca tramite protocolli esistenti come EMV 3DS, dove l'assertion può essere infine verificata crittograficamente (n. 16).

Poiché l'assertion include anche informazioni sulle informazioni visualizzate dal browser, tutti i requisiti per il collegamento dinamico sono soddisfatti. Questo sarebbe un passo importante in termini di miglioramenti della UX e dell'esperienza di pagamento del cliente.

Lo standard Secure Payment Confirmation (SPC) è uno sviluppo interessante nel mondo dell'autenticazione dei pagamenti online, volto a migliorare la sicurezza semplificando al contempo l'esperienza dell'utente. Ad oggi, Google Chrome è l'unico browser principale che supporta SPC in qualche forma. Tuttavia, questo non sorprende, poiché lo standard è stato parzialmente avviato da Google. Da parte di altri browser principali come Safari di Apple e Mozilla Firefox, si nota una mancanza di impegno, senza segnali chiari sui loro piani di supporto a SPC. In particolare, Apple spinge il proprio standard proprietario Apple Pay e non sembra interessata ad altri standard di pagamento.

La connessione di SPC con WebAuthn ha reso il processo di sviluppo più difficile. Questo perché qualsiasi miglioramento o modifica nello standard SPC deve essere attentamente valutato per prevenire la ridondanza e garantire che forniscano miglioramenti genuini rispetto alle capacità esistenti. L'obiettivo è perfezionare SPC per soddisfare esigenze specifiche all'interno del processo di pagamento che non sono completamente coperte da WebAuthn, come l'integrazione diretta nel flusso di checkout e la fornitura di un'esperienza di autenticazione più user-friendly che possa funzionare senza problemi su diversi siti di merchant.

Mentre SPC continua a evolversi, la sua adozione da parte dei diversi browser sarà cruciale per un'implementazione diffusa. Il coinvolgimento di attori importanti come Google indica una direzione positiva, ma sarà necessario un supporto più ampio per stabilire SPC come standard in tutto il settore dei pagamenti online.

Le sfide delineate sopra, in particolare riguardo alla consapevolezza del pagatore, hanno spinto il WebAuthn Working Group a lavorare su una cosiddetta estensione di conferma (precedentemente nota come “txAuthSimple”) all'interno dello standard WebAuthN. Il suo scopo è consentire all'authenticator o al browser/OS (in un'interfaccia utente privilegiata) di visualizzare i dettagli della transazione all'utente e garantire che il relying party riceva una prova crittografica che l'utente ha effettivamente confermato tali dettagli. Questo affronta direttamente il problema della “mancanza di garanzia sulla consapevolezza dell'utente” descritto nella sezione 3.3.1.

Similmente a come la Secure Payment Confirmation (SPC) fornisce una finestra di dialogo dedicata e gestita dal browser, l'estensione di conferma affronta la questione del “What You See Is What You Sign” (WYSIWYS). I suoi obiettivi principali sono:

• Visualizzazione fidata dei dettagli della transazione: invece di lasciare che sia il contenuto web a mostrare l'importo e il beneficiario, l'estensione sfrutta lo schermo sicuro di un dispositivo o una finestra di dialogo dell'interfaccia utente del browser sotto il controllo del sistema operativo.
• Prova crittografica: l'authenticator (o la piattaforma client) firma una registrazione del testo esatto visualizzato. Verificando questa firma, il relying party può confermare che all'utente sono stati mostrati i dettagli corretti.
• Fallback se l'authenticator non supporta la visualizzazione: nei casi in cui un authenticator hardware non può mostrare testo, il browser può visualizzarlo e includerlo nei [=client data=]. Questa è una garanzia più debole ma consente una compatibilità più ampia.

L'estensione aggiunge un nuovo campo alle strutture di estensione WebAuthn esistenti. I Relying Party forniscono una semplice stringa di testo (con formattazione di base opzionale) chiamata confirmation:

partial dictionary AuthenticationExtensionsClientInputs {
  USVString confirmation;
};

Quando il client (browser) riceve questo, esso:

1. Richiede all'utente una speciale finestra di dialogo di conferma (in modo che sappia che si tratta di qualcosa di più di un semplice login).
2. Passa la stessa stringa all'authenticator come dati CBOR se l'authenticator supporta l'estensione.
3. Restituisce qualsiasi output dell'authenticator al Relying Party.

Se l'authenticator supporta la visualizzazione del testo, deve mostrare quel testo (ad esempio, sul proprio schermo o su un'interfaccia utente fidata) prima di completare la verifica dell'utente. Quindi include la stessa stringa nel suo output firmato.

Dal lato del Relying Party, i passaggi di verifica assicurano che il testo confirmation restituito corrisponda a quello inviato. Se l'output dell'estensione dell'authenticator manca ma la policy del Relying Party consente un fallback, il Relying Party può fare affidamento sul valore confirmation dai dati del client, indicando che il browser ha visualizzato il testo al posto dell'authenticator.

Incorporando il beneficiario e l'importo in questa estensione, l'utente vede precisamente ciò che sta autorizzando su un display fidato. La firma dell'utente ora riflette non solo una challenge con hash, ma anche il testo esatto della transazione. Ciò è particolarmente prezioso per il requisito di collegamento dinamico della PSD2, poiché:

• Qualsiasi discrepanza o modifica dei dettagli della transazione dopo la visualizzazione invalida la firma.
• Il Relying Party può dimostrare che all'utente sono stati forniti i dettagli corretti della transazione al momento della firma, soddisfacendo il requisito di “consapevolezza del pagatore” della PSD2 in modo molto più robusto rispetto al semplice hashing dei dati nella challenge.

Sebbene l'estensione di conferma sia ancora in discussione, rappresenta un passo cruciale verso flussi di transazione più sicuri e facili da usare. Essendo integrata direttamente nella specifica WebAuthn, offre:

• Interoperabilità: qualsiasi authenticator o client che implementa l'estensione seguirebbe lo stesso formato standardizzato.
• Flessibilità: i Relying Party possono applicare policy più restrittive (richiedendo la visualizzazione a livello di authenticator) o accettare un fallback a livello di browser se necessario.
• Allineamento più ampio dell'ecosistema: si allinea bene con i mandati normativi come la PSD2, in particolare per quanto riguarda un robusto collegamento dinamico.

Per maggiori dettagli tecnici, puoi dare un'occhiata alla discussione in corso: GitHub pull request #2020. In sintesi, l'estensione di conferma potrebbe anche colmare l'ultima grande lacuna nei flussi standard basati su passkey: fornire una prova crittografica di cosa esattamente l'utente ha visto quando ha dato il suo consenso, sebbene in modo meno strutturato rispetto alla Secure Payment Confirmation. Se dovesse guadagnare terreno tra i fornitori di browser e authenticator, potrebbe diventare un metodo altamente standardizzato per fornire la garanzia di sicurezza WYSIWYS necessaria per il collegamento dinamico della PSD2, e oltre.

Sebbene SPC e l'estensione di conferma condividano l'obiettivo comune di rafforzare il collegamento dinamico in WebAuthn, differiscono per ambito e approccio. La tabella seguente evidenzia alcune di queste differenze:

In sostanza, SPC tenta di offrire una soluzione di pagamento completa* e incorpora anche il collegamento dinamico* come parte del suo flusso. L'estensione di conferma*, nel frattempo, affronta il requisito “what you see is what you sign” all'interno dei messaggi WebAuthn standard senza imporre un flusso di pagamento completo. Entrambi gli approcci potrebbero facilitare la conformità alla PSD2, ma ciascuno dipende dal supporto di browser e authenticator per offrire vantaggi nel mondo reale.

La nostra raccomandazione per issuer, banche e istituzioni finanziarie è quindi di valutare attentamente quali casi d'uso devono essere coperti e monitorare lo sviluppo dell'ecosistema, poiché la facilità delle passkey eserciterà una pressione sostanziale sulle soluzioni esistenti di SCA e collegamento dinamico per migliorare la loro UX. I clienti richiederanno soluzioni biometriche sul web. Al momento, la nostra raccomandazione operativa è:

• ✔️ Passkey per pagamenti avviati sul sito web dell'issuer/banca: le passkey sono un'ottima soluzione per issuer/banche per implementare il collegamento dinamico direttamente nei loro siti web e app. Potrebbero essere combinate con altre opzioni di autenticazione come notifiche push, email/SMS OTP o TOTP per migliorare ulteriormente la sicurezza per i pagamenti ad alto rischio. Naturalmente, le considerazioni sulla conformità SCA dovrebbero sempre far parte di questa discussione (vedi anche la nostra serie in 4 parti su passkey e SCA).

  Una soluzione proposta può essere implementata dagli stessi issuer/banche, poiché le passkey si basano sullo standard aperto WebAuthn. Tuttavia, ciò richiede un notevole know-how, la gestione di casi limite e un aggiornamento continuo su tutte le nuove normative e gli sviluppi tecnici. L'alternativa è utilizzare un fornitore di autenticazione di terze parti. Ad esempio, Corbado Connect supporta il collegamento dinamico tramite la firma delle transazioni, sfruttando challenge WebAuthn modificate. Tutte le informazioni vengono registrate nel log di audit. Questo non è utile solo per le istituzioni finanziarie, ma può essere sfruttato per tutti i tipi di firme (ad es. firma di documenti, azioni utente ad alto rischio). Opzionalmente, è possibile utilizzare un SMS o un'e-mail OTP aggiuntiva per migliorare ulteriormente la sicurezza.

• ❌ Passkey per pagamenti sulle pagine dei merchant: l'implementazione delle passkey per i pagamenti sulle pagine dei merchant non è ancora possibile. I casi d'uso cross-origin sono ancora in fase di sviluppo, ma potrebbero diventare un'opzione praticabile alla fine del 2024. Utilizzare le passkey per l'autenticazione sulle pagine dei merchant, tuttavia, è già oggi un'ottima idea e può essere utilizzato anche per iniziare a raccogliere passkey che potranno poi essere utilizzate anche per i pagamenti in futuro.

• ❌ Passkey SPC o estensione di conferma per il collegamento dinamico: lo standard SPC non ha ancora raggiunto uno stato di maturità e supporto tale da poter essere utilizzato in ambienti di produzione.

Nel complesso, siamo felici di vedere che merchant e banche hanno iniziato a impegnarsi con lo standard e ad aggiungere i loro requisiti e il loro supporto all'ecosistema. Guardando al futuro, le istituzioni finanziarie e le piattaforme di e-commerce dovrebbero monitorare attentamente questi progressi tecnologici e considerare come potrebbero integrare le passkey nei loro sistemi. Poiché le normative continuano a evolversi, è fondamentale rimanere all'avanguardia, assicurando che i processi di autenticazione dei pagamenti siano in linea con i più recenti standard di sicurezza e forniscano un'esperienza utente sicura ed efficiente per i consumatori, che migliori la conversione e riduca l'attrito.

Perché le passkey sono importanti?

Le passkey per le aziende

Password e phishing mettono a rischio le aziende. Le passkey sono l'unica soluzione MFA che bilancia sicurezza e UX. Il nostro whitepaper tratta l'implementazione e l'impatto aziendale.

Download free whitepaper

Work email *

Name *

Company *

Job title *

Phone number

Get whitepaper

Analizzando le passkey per il collegamento dinamico, è evidente che, sebbene possano aiutare a rispettare la SCA e il collegamento dinamico, l'integrazione tecnica nei servizi di terze parti con lo standard WebAuthn, originariamente progettato per contesti di prima parte, presenta alcune sfide. Questi standard si stanno gradualmente evolvendo per supportare meglio gli scenari di terze parti, dimostrando un passaggio verso una maggiore flessibilità nella loro applicazione. La Secure Payment Confirmation (SPC) cerca di promuovere questo adattamento, mirando a migliorare i processi di autenticazione dei pagamenti incorporando interazioni più user-friendly e fluide su vari siti di merchant.

Tuttavia, l'avanzamento e l'accettazione più ampia dello standard SPC o dell'estensione di conferma dipendono fortemente dalla sua adozione da parte dei principali browser, un processo che è stato lento, con Google Chrome che attualmente è l'unico sostenitore. Questo lento tasso di adozione potrebbe potenzialmente impedire, soprattutto a SPC, di superare il suo stato attuale, a meno che più browser non inizino a integrarlo. Lo sviluppo continuo e la crescente trazione delle passkey suggeriscono una direzione promettente in cui anche i sistemi che si basano su moduli di sicurezza hardware (HSM) come secure enclave, TEE e TPM svolgeranno un ruolo importante per le applicazioni di pagamento, poiché queste tecnologie offrono una sicurezza avanzata che potrebbe rendere il collegamento dinamico dei pagamenti più pratico e comodo non solo per le transazioni avviate sui siti bancari, ma anche su piattaforme di merchant di terze parti.

Il potenziale delle passkey di estendere la loro utilità ai processi di pagamento online evidenzia un aspetto importante per la sicurezza delle transazioni basate sul web e per rendere Internet in generale un luogo più sicuro.