---
url: 'https://www.corbado.com/it/blog/collegamento-dinamico-passkey-spc'
title: 'Dynamic Linking con le Passkey: Secure Payment Confirmation (SPC)'
description: 'Scopri come il collegamento dinamico, le passkey e la Secure Payment Confirmation (SPC) possono migliorare i pagamenti digitali. Impara a usare le passkey per il collegamento dinamico.'
lang: 'it'
author: 'Vincent Delitz'
date: '2025-07-15T13:23:27.189Z'
lastModified: '2026-03-25T10:05:50.226Z'
keywords: 'collegamento dinamico, secure payment confirmation, spc'
category: 'Passkeys Strategy'
---
# Dynamic Linking con le Passkey: Secure Payment Confirmation (SPC)
## 1. Introduzione
Nella nostra serie completa in quattro parti (parte 1, parte 2, parte 3 e parte 4) sulla
[PSD2](https://www.corbado.com/blog/psd2-passkeys), abbiamo analizzato come le passkey si integrano con le misure
di **strong customer authentication (SCA)** introdotte dalla [PSD2](https://www.corbado.com/blog/psd2-passkeys).
Ci siamo concentrati in particolare sugli elementi di
[autenticazione](https://www.corbado.com/it/blog/come-passare-autenticazione-completamente-passwordless)
richiesti dalla [SCA](https://www.corbado.com/it/blog/psd2-passkey) per accedere alle applicazioni bancarie. I
requisiti della [SCA](https://www.corbado.com/it/blog/psd2-passkey) non si applicano solo all'accesso alle
applicazioni, ma anche all'avvio e alla firma di transazioni di
[pagamento](https://www.corbado.com/passkeys-for-payment) 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.
## 2. Cos'è il collegamento dinamico nella PSD2?
Il **collegamento dinamico** è un requisito di
[sicurezza](https://www.corbado.com/it/blog/come-abilitare-passkey-su-android) previsto dalla direttiva
[PSD2](https://www.corbado.com/blog/psd2-passkeys) e dalla sua appendice di attuazione, i Regulatory Technical
Standards (RTS). Il concetto è stato introdotto per aumentare la
[sicurezza](https://www.corbado.com/it/blog/come-abilitare-passkey-su-android) dei
[pagamenti](https://www.corbado.com/it/blog/credenziali-digitali-pagamenti-apple-vs-google-wallet) elettronici,
garantendo che ogni transazione sia collegata in modo univoco a un importo specifico e a
un beneficiario specifico tramite un codice di
[autenticazione](https://www.corbado.com/it/blog/come-passare-autenticazione-completamente-passwordless). Questo
collegamento impedisce qualsiasi modifica dei dettagli della transazione una volta che è
stata autenticata dal pagatore, riducendo così il rischio di frode. I
[pagamenti](https://www.corbado.com/it/blog/credenziali-digitali-pagamenti-apple-vs-google-wallet) elettronici
includono i bonifici bancari nei software di online [banking](https://www.corbado.com/passkeys-for-banking), ma
anche i [pagamenti](https://www.corbado.com/it/blog/credenziali-digitali-pagamenti-apple-vs-google-wallet) con
carta di credito sui siti dei [merchant](https://www.corbado.com/glossary/merchant).
### 2.1 Definizione e importanza nella PSD2
Secondo la direttiva PSD2 e i relativi RTS, il collegamento dinamico è definito come un
processo che garantisce che "il codice di
[autenticazione](https://www.corbado.com/it/blog/come-passare-autenticazione-completamente-passwordless) generato
sia specifico per l'importo e il beneficiario concordati dal pagatore al momento
dell'avvio della transazione di [pagamento](https://www.corbado.com/passkeys-for-payment) elettronico" (articolo
97, paragrafo 2, della PSD2). Ciò significa che qualsiasi modifica ai dettagli del
[pagamento](https://www.corbado.com/passkeys-for-payment) invaliderebbe il codice di autenticazione, richiedendo
una nuova autenticazione.
Il collegamento dinamico è fondamentale nella PSD2, poiché affronta direttamente i rischi
per la [sicurezza](https://www.corbado.com/it/blog/come-abilitare-passkey-su-android) 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.
### 2.2 Requisiti per il collegamento dinamico nelle transazioni finanziarie
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.
## 3. Come si possono usare le passkey per il collegamento dinamico?
Analizziamo innanzitutto le diverse opzioni su come le passkey possono essere utilizzate
nel collegamento dinamico.
### 3.1 Opzione 1: uso standard delle passkey nel collegamento dinamico
In questo approccio, la passkey stessa funge da [assertion](https://www.corbado.com/glossary/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.
### 3.2 Opzione 2: prova crittografica avanzata tramite la challenge WebAuthn
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](https://www.w3.org/2024/Talks/Fime_W3C_6feb24.pdf)).
### 3.3 Limiti e sfide delle opzioni standard con passkey
Analizziamo i limiti e le sfide di queste due opzioni.
#### 3.3.1 La consapevolezza del pagatore non può essere garantita
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.
#### 3.3.2 Caso d'uso: contesto di pagamento di prima parte e di terza parte
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](https://www.corbado.com/glossary/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](https://www.corbado.com/passkeys-for-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](https://www.corbado.com/blog/mastercard-passkeys) 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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/merchant) mostra un [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) dove
può avvenire l'autenticazione con la passkey. L'[IFRAME](https://www.corbado.com/blog/iframe-passkeys-webauthn)
è mostrato dal processo sottostante [3-D Secure](https://www.corbado.com/glossary/3d-secure) 2 (3DSS/EMV 3DS),
già in uso per le transazioni con carta di credito che devono supportare
[SCA](https://www.corbado.com/it/blog/psd2-passkey) e collegamento dinamico.
- ❌ **Caso 2 – L'utente non ha una passkey dal proprio issuer/banca:** Anche in questo
caso, il merchant mostra l'[iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn). Poiché non sono
ancora disponibili passkey, l'utente viene autenticato con i fattori di autenticazione
esistenti (ad es. SMS OTP o l'[app nativa](https://www.corbado.com/it/blog/app-native-passkey) di
[banking](https://www.corbado.com/passkeys-for-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](https://www.corbado.com/blog/iframe-passkeys-webauthn)
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](https://www.corbado.com/blog/iframe-passkeys-webauthn) è già
incorporato nella specifica [WebAuthn Level 3](https://www.corbado.com/blog/passkeys-prf-webauthn) in corso di
sviluppo (che sarà resa disponibile a livello generale entro la fine del 2024). Tuttavia,
i browser devono ancora adeguarsi alla specifica:
| **Browser/Standard** | **Contesto di prima parte** | **Contesto di terza parte** |
| ---------------------------------------------------------------------------------- | ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| **Registrare passkey** **in iframe cross-origin:** | | |
| Richiesto in WebAuthn Level 2 | ✔️ [Dettagli](https://issues.chromium.org/issues/40258856) | ❌ |
| Richiesto in WebAuthn Level 3 | ✔️ [Dettagli](https://issues.chromium.org/issues/40258856) | ✔️ [Dettagli](https://issues.chromium.org/issues/40258856) |
| Implementato in Chrome | ✔️ [Dettagli](https://issues.chromium.org/issues/40258856) | ✔️ [Dettagli](https://issues.chromium.org/issues/40258856) |
| Implementato in Firefox | ✔️ [Dettagli](https://issues.chromium.org/issues/40258856) | [Segnale positivo](https://github.com/mozilla/standards-positions/issues/964) per l'implementazione |
| Implementato in [Safari](https://github.com/WebKit/standards-positions/issues/304) | ✔️ [Dettagli](https://issues.chromium.org/issues/40258856) | In attesa di un segnale per l'implementazione |
| **Autenticarsi usando passkey** **in iframe cross-origin:** | | |
| Richiesto in WebAuthn Level 2 | ✔️ | ✔️ |
| Richiesto in WebAuthn Level 3 | ✔️ | ✔️ |
| Implementato in Chrome | ✔️ | ✔️ |
| Implementato in Firefox | ✔️ | ✔️ |
| Implementato in Safari | ✔️ | ✔️ |
Ad oggi, sembra che entro il 2024 la copertura per la registrazione
[cross-origin](https://www.corbado.com/blog/iframe-passkeys-webauthn) delle passkey potrebbe diventare una realtà
nei principali browser, il che eliminerebbe la più significativa limitazione tecnica
nell'uso delle passkey per i pagamenti.
## 4. Opzione futura: Secure Payment Confirmation (SPC)
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](https://www.corbado.com/passkeys-for-e-commerce) 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.
### 4.1 Quali sono gli obiettivi dello standard SPC?
La [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (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](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) sfrutta
il browser per fornire un'esperienza di autenticazione coerente e semplificata su
diversi siti di merchant e [relying party](https://www.corbado.com/glossary/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/](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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/authenticator) deve
avvenire in un contesto di prima parte, [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-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](https://www.corbado.com/blog/dynamic-linking-passkeys-spc).
- **Autenticazione cross-origin dei pagamenti:** SPC estende l'utilità di WebAuthn
consentendo a qualsiasi origine di generare un'[assertion](https://www.corbado.com/glossary/assertion) per una
transazione, anche se sfrutta le credenziali di un altro
[Relying Party](https://www.corbado.com/glossary/relying-party) (senza la necessità di lasciare la pagina). In
questo caso, non è necessario nemmeno un iframe dal merchant/[issuer](https://www.corbado.com/glossary/issuer).
Questa funzione è particolarmente utile in scenari in cui più parti (merchant +
[issuer](https://www.corbado.com/glossary/issuer)/banca) sono coinvolte nel processo di autenticazione e
l'assertion può quindi essere trasportata al [Relying Party](https://www.corbado.com/glossary/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](https://www.corbado.com/it/blog/passkey-visa), mirando a semplificare
l'autenticazione mantenendo elevati standard di sicurezza in tutto il panorama dei
pagamenti digitali.
### 4.2 Come sarebbero i flussi delle passkey SPC?
Esaminiamo tutti i possibili flussi che SPC consentirebbe e confrontiamoli con le passkey
standard, in modo da comprenderne i vantaggi.
| | **Passkey SPC** | **Passkey** |
| ----------------------------------------------------- | --------------- | ----------- |
| **Autenticazione/registrazione sul sito dell'issuer** | ✔️ | ✔️ |
| **Registrazione sul sito del merchant in iframe** | ✔️ | ❌/✔️ |
| **Autenticazione sul sito del merchant in iframe** | ✔️ | ✔️ |
| **Autenticazione cross-origin sul sito del merchant** | ✔️ | ❌ |
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.
#### 4.2.1 Passkey SPC: registrazione/autenticazione direttamente sul sito web dell'issuer/banca
Ecco un esempio di mockup della registrazione di una passkey SPC direttamente sulla pagina
di [Mastercard](https://www.corbado.com/blog/mastercard-passkeys). 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](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).
#### 4.2.2 Passkey SPC: registrazione/autenticazione su un sito di un merchant durante il pagamento
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](https://www.corbado.com/glossary/3d-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](https://www.corbado.com/it/blog/passkey-fornitori-pagamento-sdk-terze-parti)
o dalla banca emittente (ad es. [mastercard](https://www.corbado.com/blog/mastercard-passkeys).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](https://www.corbado.com/it/blog/passkey-fornitori-pagamento-sdk-terze-parti)
(ad es. [PayPal](https://www.corbado.com/blog/paypal-passkeys)) 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](https://developer.chrome.com/docs/payments/register-secure-payment-confirmation)_
Su [https://spc-merchant.glitch.me/](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](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.
#### 4.2.3 Passkey SPC: autenticazione cross-origin
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](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](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.
### 4.3 Qual è lo stato dello standard Secure Payment Confirmation?
Lo standard [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (SPC) è uno
sviluppo interessante nel mondo dell'autenticazione dei
[pagamenti online](https://www.corbado.com/it/blog/passkey-visa), 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](https://www.corbado.com/it/blog/passkey-visa).
## 5. Opzione futura 2: l'estensione di conferma
Le sfide delineate sopra, in particolare riguardo alla **consapevolezza del pagatore**,
hanno spinto il [WebAuthn Working Group](https://github.com/w3c/webauthn/pull/2020) a
lavorare su una cosiddetta **estensione di conferma** (precedentemente nota come
“txAuthSimple”) all'interno dello standard WebAuthN. Il suo scopo è consentire
all'[authenticator](https://www.corbado.com/glossary/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](#331-payer-awareness-cannot-be-assured).
### 5.1 Quali sono gli obiettivi dell'estensione di conferma?
Similmente a come la [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc)
(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](https://www.corbado.com/glossary/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.
### 5.2 Come funziona l'estensione di conferma?
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`:
```webidl
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](https://www.corbado.com/glossary/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.
### 5.3 Perché è importante per il collegamento dinamico
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.
### 5.4 Stato attuale dell'estensione di conferma
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](https://github.com/w3c/webauthn/pull/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.
### 5.5 Confronto: le differenze tra SPC e l'estensione di conferma
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:
| **Criteri di confronto** | **SPC** | **Estensione di conferma** |
| ---------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| **Flusso di pagamento integrato**
_(Gestisce l'intero checkout, importi, beneficiario, UI, ecc.)_ | ✔️ Include una finestra di dialogo standardizzata del browser per i pagamenti | ❌ Si concentra solo sulla visualizzazione e la firma di una stringa di testo |
| **Visualizzazione fidata della transazione**
_(Garantisce che l'utente veda il beneficiario/importo corretto)_ | ✔️ Il flusso basato sul browser garantisce una UX coerente | ✔️ Visualizzazione tramite authenticator o browser |
| **Gestione del fallback**
_(Se l'authenticator ha capacità di visualizzazione limitate o nulle)_ | ❌ Non progettato specificamente per percorsi di fallback | ✔️ Il Relying Party può accettare la visualizzazione a livello di client se necessario |
| **Scopo oltre il collegamento dinamico**
_(Obiettivi più ampi, ad es. flussi con un solo clic, autenticazione cross-origin)_ | ✔️ Progettato per semplificare l'intero processo di checkout | ❌ È strettamente un'estensione della challenge/response standard di WebAuthn |
| **Maturità e adozione attuali**
_(Prontezza cross-browser)_ | Bassa adozione oltre a Chrome; tempistiche incerte | In discussione nel [WebAuthn WG](https://github.com/w3c/webauthn/pull/2020) ma promettente |
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.
## 6. Raccomandazioni per issuer e banche
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](https://issues.chromium.org/issues/40258856):**
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](https://www.corbado.com/passkeys-for-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.
## 6. Conclusione
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](https://www.corbado.com/glossary/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.