EMV 3DS Access Control Server: Passkeys, FIDO e SPC

Il panorama dell'autenticazione dei pagamenti online sta subendo una trasformazione significativa, spinta dalla duplice esigenza di rafforzare la sicurezza contro le frodi sofisticate e di migliorare l'esperienza utente per ridurre l'attrito e l'abbandono del carrello. Il protocollo EMV® 3-D Secure (3DS), in particolare le sue versioni più recenti (EMV 3DS 2.x), funge da tecnologia fondamentale per l'autenticazione delle transazioni senza carta presente (Card-Not-Present, CNP) a livello globale. Gestito da EMVCo, questo protocollo facilita lo scambio di dati tra merchant, issuer (tramite il loro Access Control Server - ACS) e il dominio di interoperabilità (Directory Server gestiti dagli schemi di pagamento) per verificare l'identità del titolare della carta.

All'interno di questo quadro, stanno emergendo due importanti progressi tecnologici legati agli standard della FIDO (Fast Identity Online) Alliance:

1. L'uso dei dati di autenticazione FIDO generati durante precedenti interazioni dell'utente (ad esempio, il login presso un merchant) per arricchire la valutazione del rischio per il flusso frictionless di EMV 3DS.
2. L'integrazione della Secure Payment Confirmation (SPC), uno standard web del W3C basato su FIDO/WebAuthn, come metodo di "challenge" semplificato e resistente al phishing all'interno del flusso EMV 3DS.

Questo articolo offre una panoramica del mercato globale delle soluzioni EMV 3DS Access Control Server (ACS) fornite alle banche emittenti. Identifica i principali fornitori e cerca di valutare il loro attuale supporto sia per le strutture di dati FIDO non-SPC sia per la Secure Payment Confirmation (SPC) per i flussi di challenge. Inoltre, chiarisce il meccanismo attraverso il quale gli issuer possono sfruttare le proprie passkey FIDO per la verifica crittografica all'interno del flusso di challenge 3DS tramite SPC e discute l'applicabilità globale di questo standard.

EMV 3DS opera principalmente attraverso due distinti percorsi di autenticazione:

• Flusso Frictionless: è il percorso preferito, che mira a un'esperienza utente senza interruzioni. L'ACS dell'issuer esegue una valutazione del rischio basata su un ricco set di dati scambiati durante l'avvio della transazione (tramite la richiesta di autenticazione, o messaggio AReq). Questi dati includono dettagli della transazione, informazioni sul merchant, caratteristiche del dispositivo, dati del browser (potenzialmente raccolti tramite il JavaScript 3DSMethod) e, eventualmente, informazioni di autenticazione precedenti. Se il rischio è considerato basso, la transazione viene autenticata senza richiedere alcuna interazione diretta o "challenge" da parte del titolare della carta. Questo flusso rappresenta la maggior parte delle transazioni 3DS, in particolare dove i motori di rischio sono ben calibrati.
• Flusso con Challenge: se l'ACS determina che il rischio della transazione è elevato, se richiesto da normative (come la PSD2 SCA in Europa) o dalle policy dell'issuer, al titolare della carta viene attivamente richiesto di verificare la propria identità. I metodi di challenge tradizionali includono One-Time Passcode (OTP) inviati via SMS, domande basate sulla conoscenza o autenticazione Out-of-Band (OOB) tramite un'app di banking. L'obiettivo delle versioni più recenti di 3DS e delle tecnologie correlate come SPC è rendere questo flusso di challenge più sicuro e meno macchinoso rispetto ai metodi legacy.

EMVCo e la FIDO Alliance hanno collaborato per definire un modo standardizzato con cui i merchant possono trasmettere informazioni sulle precedenti autenticazioni FIDO (dove il merchant ha agito come Relying Party, ad esempio durante il login dell'utente) all'ACS dell'issuer all'interno del messaggio AReq standard di 3DS. Questo meccanismo, supportato per la prima volta in EMV 3DS v2.1, sfrutta campi specifici all'interno dell'AReq, principalmente la struttura threeDSRequestorAuthenticationInfo, che contiene sottocampi come threeDSRequestorAuthenticationData.

La Nota Tecnica della FIDO Alliance e il relativo white paper di EMVCo specificano una struttura JSON per questo campo threeDSRequestorAuthenticationData quando si trasmettono i dettagli di una precedente autenticazione FIDO. Questo oggetto JSON include dettagli come l'ora dell'autenticazione (authTime), l'ID del Relying Party FIDO (rpId o appId) e informazioni sull'authenticator utilizzato, inclusa la chiave pubblica, l'AAGUID/AAID e indicatori di presenza dell'utente (UP) e di verifica dell'utente (UV).

La logica è che se un merchant ha recentemente eseguito una forte autenticazione FIDO (ad esempio, utilizzando la biometria o una passkey) per la sessione utente che avvia l'acquisto, questa informazione può servire come un prezioso segnale di rischio aggiuntivo per l'ACS dell'issuer. Ricevendo ed elaborando questi dati FIDO standardizzati, l'ACS può potenzialmente ottenere una maggiore fiducia nella legittimità della transazione, aumentando la probabilità di un'approvazione frictionless e riducendo la necessità di una challenge separata. È importante notare che in questo scenario, il merchant è il FIDO RP e l'issuer consuma questi dati come input per il suo motore di rischio; l'issuer non verifica crittograficamente l'assertion FIDO stessa all'interno di questo flusso frictionless. L'ACS mantiene l'opzione di ignorare questi dati se non è configurato per elaborarli it.

La Secure Payment Confirmation (SPC) rappresenta un'integrazione distinta degli standard FIDO all'interno del flusso di challenge EMV 3DS. SPC è uno standard web del W3C, sviluppato in collaborazione con FIDO ed EMVCo, basato su WebAuthn. È formalmente supportato all'interno di EMV 3DS a partire dalla versione 2.3.

Quando SPC viene utilizzato come metodo di challenge:

1. L'issuer (o una parte esplicitamente delegata dall'issuer, come uno schema di pagamento) funge da FIDO Relying Party (RP). Questo è fondamentalmente diverso dal flusso di dati FIDO non-SPC descritto in precedenza, in cui il merchant agisce tipicamente come RP per i propri scopi di login/autenticazione.
2. Durante la challenge 3DS, l'ACS segnala la necessità di SPC e fornisce gli identificatori di credenziali FIDO necessari e una challenge crittografica al merchant/3DS Server.
3. Il sistema del merchant invoca l'API SPC del browser, presentando i dettagli della transazione (importo, valuta, beneficiario, strumento) all'utente in una finestra di dialogo sicura controllata dal browser.
4. L'utente si autentica utilizzando il proprio authenticator FIDO (ad esempio, biometria del dispositivo, PIN, chiave di sicurezza), che firma i dettagli della transazione e la challenge utilizzando la chiave privata associata alla passkey registrata dall'issuer.
5. L'assertion FIDO risultante (prova crittografica di autenticazione e consenso) viene trasmessa attraverso il protocollo 3DS (tipicamente tramite un secondo messaggio AReq) all'ACS dell'issuer.
6. L'ACS, in qualità di RP, convalida crittograficamente l'assertion utilizzando la chiave pubblica corrispondente, confermando l'identità del titolare della carta e il consenso ai dettagli specifici della transazione.

SPC mira a fornire un'esperienza di challenge che sia più sicura (resistente al phishing, collegamento dinamico dell'autenticazione ai dati della transazione) e potenzialmente a minor attrito (spesso più veloce dell'inserimento di un OTP) rispetto ai metodi tradizionali.

I due percorsi per l'integrazione FIDO — uno che sfrutta i dati di autenticazione precedenti del merchant per la valutazione del rischio frictionless, l'altro che utilizza credenziali gestite dall'issuer per una challenge diretta basata su FIDO tramite SPC — offrono approcci distinti per migliorare la sicurezza e l'esperienza utente all'interno del framework EMV 3DS. Comprendere il supporto dei fornitori per ciascuno è cruciale per gli issuer e i PSP che pianificano le loro strategie di autenticazione.

Questa sezione analizza le capacità dei fornitori globali di soluzioni ACS EMV 3DS, concentrandosi sulla loro presenza sul mercato e sul supporto per i dati FIDO (non-SPC) e la Secure Payment Confirmation (SPC). Le cifre precise sulla quota di mercato sono proprietarie e difficili da ottenere pubblicamente; pertanto, la presenza viene valutata sulla base delle dichiarazioni dei fornitori, delle certificazioni, delle partnership, della portata geografica e dei rapporti di mercato.

• Presenza sul mercato: Entersekt, in particolare dopo l'acquisizione del business software 3DS di Modirum nel dicembre 2023, si posiziona come fornitore leader a livello globale di soluzioni EMV 3DS, puntando a una posizione tra i primi cinque del mercato. Modirum aveva oltre 20 anni di esperienza nel 3DS. Entersekt evidenzia una crescita record trainata da nuovi clienti, soprattutto in Nord America, e da partnership strategiche, inclusa una relazione ampliata con Mastercard. Affermano di proteggere oltre 2,5 miliardi di transazioni all'anno (dati FY24) e sono classificati al primo posto nella prevenzione dell'ATO nel banking da Liminal. Il loro ACS è disponibile in hosting (da Entersekt o dal cliente) o on-premise. Servono issuer e processori a livello globale.
• Supporto dati FIDO non-SPC (Frictionless): Entersekt enfatizza la sua Context Aware™ Authentication, l'analisi comportamentale e del dispositivo per i segnali di rischio e l'integrazione con vari servizi di risk-scoring. Il loro ACS è certificato FIDO EMVCo 2.2. Sebbene evidenzino lo sfruttamento dei dati di intelligence sul rischio e sul comportamento per la RBA, una conferma esplicita dell'elaborazione dei dati di attestazione FIDO standardizzati da precedenti autenticazioni del merchant all'interno del campo threeDSRequestorAuthenticationInfo per il potenziamento del flusso frictionless non è esplicitamente dichiarata nei materiali online. Tuttavia, il loro focus sull'autenticazione avanzata e sui segnali di rischio suggerisce tale capacità.
• Supporto SPC (Challenge): Forti indicatori suggeriscono che Entersekt supporti SPC. Modirum, di cui Entersekt ha acquisito il business 3DS, ha fornito componenti per il progetto pilota SPC di Visa utilizzando 3DS 2.2 con estensioni. Entersekt elenca esplicitamente il supporto per la conformità SPC come parte delle sue capacità di conformità normativa. Il loro ACS supporta l'autenticazione biometrica, è certificato per EMV 3DS 2.2 e probabilmente incorpora le capacità derivanti dal coinvolgimento di Modirum nel progetto pilota. La combinazione dell'acquisizione di Modirum, la menzione esplicita della conformità SPC e la certificazione FIDO indicano fortemente il supporto SPC nella loro offerta attuale.

• Presenza sul mercato: Arcot di Broadcom è un attore fondamentale nel mercato 3DS, avendo co-inventato il protocollo originale con Visa. Si posizionano come leader globale riconosciuto, servendo oltre 5.000 istituzioni finanziarie in tutto il mondo e processando transazioni da 229 paesi. Il loro Arcot Network enfatizza un vasto approccio basato sui dati del consorzio (dichiarando oltre 600 milioni di firme di dispositivi, 150 trilioni di punti dati) per alimentare i loro motori di scoring delle frodi e di rischio. Hanno una forte presenza in Europa, Australia e Nord America.
• Supporto dati FIDO non-SPC (Frictionless): Broadcom enfatizza pesantemente la ricchezza della sua rete di dati e l'uso di AI/reti neurali per il rilevamento delle frodi e la valutazione basata sul rischio, andando oltre gli elementi di dati standard di EMV 3DS. Dichiarano esplicitamente che la loro soluzione sfrutta i dati che fluiscono attraverso più issuer e incorpora dati digitali come quelli del dispositivo e la geolocalizzazione. Sebbene non menzionino esplicitamente l'elaborazione della specifica struttura JSON FIDO da threeDSRequestorAuthenticationData, il loro focus sull'acquisizione di diversi punti dati per la RBA suggerisce fortemente che potrebbero consumare tali dati se forniti, in linea con l'intento delle linee guida EMVCo/FIDO. La loro piattaforma mira a massimizzare le approvazioni frictionless attraverso una valutazione del rischio superiore.
• Supporto SPC (Challenge): La documentazione di Broadcom conferma il supporto per gli authenticator FIDO (Security Key, Biometric, Passkey) all'interno della loro più ampia suite VIP Authentication Hub / Identity Security. Il loro 3DS ACS supporta vari metodi di challenge, tra cui OTP e notifiche push, e menzionano il supporto per la biometria. Offrono anche capacità di Autenticazione Delegata e hanno introdotto funzionalità di valutazione del rischio post-challenge. Tuttavia, una conferma esplicita che il loro prodotto EMV 3DS ACS supporti attualmente SPC come metodo di challenge specifico (richiedendo capacità EMV 3DS v2.3+ e il flusso a due AReq) è assente nella documentazione fornita. Sebbene siano un attore importante probabilmente in grado di implementarlo, il materiale pubblico attuale si concentra maggiormente sul loro motore RBA e sui metodi di challenge tradizionali/OOB.

• Presenza sul mercato: Netcetera si posiziona come un importante attore internazionale nel settore dei pagamenti, particolarmente forte in Europa e nel Medio Oriente. Dichiarano che il loro ACS è utilizzato da oltre 800 banche/issuer, proteggendo oltre 50 milioni di carte in tutto il mondo. Enfatizzano le certificazioni con tutti i principali circuiti di carte (Visa, Mastercard, Amex, Discover, JCB, UnionPay, ecc.) e la conformità PCI. Sono stati il primo fornitore di ACS al mondo a ottenere la certificazione EMV 3DS 2.3.1.
• Supporto dati FIDO non-SPC (Frictionless): La documentazione di Netcetera evidenzia l'importanza dei dati raccolti tramite il 3DSMethod per la valutazione del rischio dell'ACS al fine di aumentare l'autenticazione frictionless. Offrono l'integrazione con strumenti di rischio. Tuttavia, una conferma specifica dell'elaborazione dei dati di autenticazione FIDO precedenti del merchant (da threeDSRequestorAuthenticationInfo) per la valutazione del rischio non è esplicitamente menzionata nei materiali esaminati.
• Supporto SPC (Challenge): Netcetera dimostra un forte supporto per SPC. Sono stati il primo fornitore a livello globale certificato per EMV 3DS 2.3.1, la versione che incorpora SPC. Hanno partecipato al progetto pilota SPC di Visa, fornendo i componenti v2.3.1. La documentazione del loro prodotto definisce esplicitamente SPC. Hanno tenuto webinar discutendo l'integrazione di FIDO e SPC e pubblicato articoli che evidenziano i benefici di SPC. Questa combinazione di certificazione, partecipazione a progetti pilota e documentazione esplicita conferma il loro supporto per le challenge SPC.

• Presenza sul mercato: Worldline si posiziona come leader europeo nei servizi di pagamento e transazionali e come uno dei principali attori globali (dichiarando lo status di 4° attore mondiale nel settore dei pagamenti). Processano miliardi di transazioni all'anno ed enfatizzano la conformità garantita, il controllo delle frodi tramite AI/ML e la scalabilità. Il loro ACS è dichiarato certificato EMV 3DS e conforme ai principali schemi (Visa Secure, Mastercard Identity Check) e alla PSD2. Riferiscono di processare oltre 2,4 miliardi di transazioni 3DS all'anno per oltre 100 issuer.
• Supporto dati FIDO non-SPC (Frictionless): L'offerta ACS di Worldline include un motore di regole RBA che consente agli issuer di configurare flussi frictionless o con challenge in base al rischio. La loro soluzione più ampia "Trusted Authentication" sfrutta l'intelligence del dispositivo e l'analisi comportamentale. Sebbene supportino FIDO in generale, una conferma esplicita dell'elaborazione dei dati FIDO precedenti del merchant (non-SPC) all'interno dell'ACS per la valutazione del rischio non è dettagliata negli estratti forniti.
• Supporto SPC (Challenge): Worldline mostra chiare indicazioni di supporto a SPC. La loro documentazione riconosce l'evoluzione di EMV 3DS 2.3 per includere SPC/FIDO. Commercializzano esplicitamente la loro soluzione "WL Trusted Authentication" come supporto all'autenticazione FIDO e offrono un "WL FIDO Server" adatto per "casi d'uso 3DS, con emvCO2.3 e SPC.

• Presenza sul mercato: GPayments posiziona ActiveAccess come una "piattaforma Access Control Server (ACS) robusta e leader di mercato" con oltre 20 anni di esperienza nel settore 3D Secure. Sono certificati con i principali circuiti di carte (Visa Secure, Mastercard Identity Check, JCB J/Secure) sia per 3DS1 che per EMV 3DS. La loro soluzione può essere implementata on-premise o in cloud-hosting. I rapporti di mercato identificano GPayments come un attore di rilievo che offre soluzioni ACS.
• Supporto dati FIDO non-SPC (Frictionless): ActiveAccess supporta l'integrazione con soluzioni RBA di terze parti e utilizza vari parametri per la propria valutazione del rischio. Tuttavia, la documentazione fornita non menziona esplicitamente il supporto per l'acquisizione o l'uso di dati di autenticazione FIDO precedenti del merchant (non-SPC) per la valutazione del rischio frictionless.
• Supporto SPC (Challenge): La documentazione esaminata per ActiveAccess non menziona esplicitamente il supporto per Secure Payment Confirmation (SPC), challenge WebAuthn o challenge FIDO come parte delle sue capacità di flusso di challenge. Sebbene supportino vari metodi di autenticazione, incluso l'OOB (che può includere la biometria), il supporto specifico per SPC non è chiaro dalle informazioni disponibili.

• Presenza sul mercato: Visa, in qualità di principale rete di pagamento globale, definisce il programma Visa Secure basato sullo standard EMV 3DS. Hanno aperto la strada al protocollo 3DS originale. Piuttosto che agire principalmente come fornitore diretto di ACS allo stesso modo di aziende tecnologiche come Entersekt o Broadcom, Visa gestisce il programma e si affida a un elenco di fornitori 3DS approvati (inclusi i fornitori di ACS) i cui prodotti sono certificati conformi a EMV 3DS e alle regole di Visa Secure. Gli issuer di solito acquistano soluzioni ACS da questi fornitori certificati. Visa stessa si concentra sulla rete (Directory Server), definendo le regole del programma, promuovendo l'adozione e guidando l'innovazione come i progetti pilota SPC.
• Supporto dati FIDO non-SPC (Frictionless): Visa Secure, basato su EMV 3DS, supporta intrinsecamente lo scambio di dati ricchi per la valutazione del rischio al fine di abilitare il flusso frictionless. Il framework EMVCo/FIDO per la trasmissione dei dati FIDO precedenti opera all'interno dell'ecosistema Visa Secure se il fornitore ACS scelto ne supporta l'elaborazione.
• Supporto SPC (Challenge): Visa è attivamente coinvolta nella sperimentazione e promozione di SPC. Stanno lavorando con partner (come Netcetera e Modirum/Entersekt nei progetti pilota) per testare e perfezionare il flusso SPC all'interno del protocollo 3DS. Questo forte impegno indica un supporto strategico per SPC come metodo di challenge all'interno del programma Visa Secure, subordinato alla preparazione dell'ecosistema (supporto di ACS, merchant, browser).

• Presenza sul mercato: Similmente a Visa, Mastercard gestisce il programma Mastercard Identity Check basato su EMV 3DS. Forniscono opzioni per issuer e merchant, inclusa l'elaborazione stand-in e potenzialmente sfruttando partner o sussidiarie come NuData. Mastercard ha acquisito NuData Security, un'azienda di biometria comportamentale, nel 2017, migliorando le sue capacità di valutazione del rischio. Enfatizzano anche l'innovazione continua in biometria, RBA e AI. Come Visa, si affidano a fornitori certificati per i componenti principali dell'ACS, ma possono offrire servizi in bundle o sfruttare la tecnologia acquisita.
• Supporto dati FIDO non-SPC (Frictionless): Mastercard Identity Check sfrutta il ricco scambio di dati di EMV 3DS 2.x per migliorare le decisioni sul rischio e il flusso frictionless. La loro acquisizione di NuData suggerisce un forte focus sull'analisi comportamentale come parte di questa valutazione del rischio. Il supporto per l'elaborazione dei dati FIDO precedenti del merchant dipenderebbe dalla specifica implementazione ACS utilizzata dall'issuer all'interno del programma Identity Check.
• Supporto SPC (Challenge): Mastercard è un membro chiave di EMVCo ed è coinvolta nello sviluppo degli standard EMV 3DS, inclusa la v2.3 che supporta SPC. Stanno anche promuovendo l'adozione delle passkey in modo più ampio. Maggiori dettagli possono essere trovati qui. Sono un forte sostenitore di SPC e spingono verso metodi di autenticazione moderni.

Il mercato degli ACS EMV 3DS presenta numerosi fornitori oltre a quelli dettagliati sopra. Fornitori come /n software, RSA, 2C2P, 3dsecure.io, Adyen, ACI Worldwide, Computop e altri offrono anche soluzioni certificate o svolgono ruoli significativi in regioni o segmenti specifici. Questa analisi mira a coprire i principali attori globali ma non è esaustiva a causa della natura dinamica del mercato. Le capacità dei fornitori, in particolare per quanto riguarda gli standard emergenti come SPC, evolvono rapidamente. Se notate imprecisioni o avete informazioni aggiornate sul supporto dei fornitori per i dati FIDO o la Secure Payment Confirmation, vi preghiamo di contattarci per garantire che questa panoramica rimanga attuale e accurata.

Un principio fondamentale dell'utilizzo della Secure Payment Confirmation (SPC) all'interno del flusso di challenge EMV 3DS è che l'issuer della carta (o una parte esplicitamente delegata dall'issuer, come uno schema di pagamento) funge da FIDO Relying Party (RP). Questo è fondamentalmente diverso dal flusso di dati FIDO non-SPC descritto in precedenza, in cui il merchant agisce tipicamente come RP per i propri scopi di login/autenticazione.

Affinché SPC funzioni in una challenge 3DS, sono coinvolti i seguenti passaggi:

1. Registrazione: il titolare della carta deve prima registrare un authenticator FIDO (ad esempio, biometria del dispositivo come impronta digitale/riconoscimento facciale, PIN del dispositivo o una chiave di sicurezza roaming) presso la propria banca emittente. Questo processo crea una passkey, in cui la chiave pubblica e un identificatore di credenziale univoco vengono memorizzati dall'issuer e associati all'account del titolare della carta o a una specifica carta di pagamento. La registrazione potrebbe avvenire all'interno dell'app mobile della banca, del portale di banking online o potenzialmente essere offerta dopo una challenge 3DS tradizionale andata a buon fine. Fondamentalmente, affinché SPC possa essere invocato da una terza parte come un sito web di un merchant, la credenziale deve essere tipicamente creata con il consenso esplicito dell'utente che ne consente l'uso in tali contesti, spesso coinvolgendo estensioni WebAuthn specifiche durante la registrazione.
2. Autenticazione (durante la challenge 3DS):
   • Quando una transazione 3DS attiva una challenge e l'issuer/ACS supporta e seleziona SPC, l'ACS identifica l'ID credenziale FIDO pertinente collegato al titolare della carta e al dispositivo.
   • L'ACS include questi ID credenziale, insieme a una challenge crittografica univoca e ai dettagli della transazione (importo, valuta, nome/origine del beneficiario, icona/nome visualizzato dello strumento), nella risposta di autenticazione (ARes) inviata al 3DS Server/Requestor.
   • Il componente 3DS Requestor del merchant utilizza queste informazioni dall'ARes per invocare l'API SPC del browser.
   • Il browser presenta una finestra di dialogo standardizzata e sicura che mostra i dettagli della transazione forniti dall'ACS.
   • L'utente conferma la transazione e si autentica utilizzando il proprio authenticator FIDO registrato (ad esempio, toccando un sensore di impronte digitali, riconoscimento facciale, inserendo il PIN del dispositivo, toccando una chiave di sicurezza). Questa azione sblocca la chiave privata memorizzata in modo sicuro sul dispositivo/authenticator.
   • L'authenticator firma i dettagli della transazione presentati e la challenge crittografica ricevuta dall'ACS.
   • Il browser restituisce l'assertion FIDO risultante (il payload di dati firmato) al 3DS Requestor del merchant.
   • Il 3DS Requestor trasmette questa assertion all'ACS dell'Issuer, tipicamente incapsulata in un secondo messaggio AReq.
   • L'Issuer/ACS, agendo come Relying Party autorevole, utilizza la chiave pubblica del titolare della carta precedentemente memorizzata per verificare crittograficamente la firma sull'assertion. Una verifica riuscita conferma che il legittimo titolare della carta, utilizzando il suo authenticator registrato, ha approvato i dettagli specifici della transazione presentati.

L'integrazione di SPC nel flusso di challenge EMV 3DS richiede modifiche alla sequenza di messaggi standard, coinvolgendo tipicamente due scambi AReq/ARes:

1. Richiesta di Autenticazione Iniziale (AReq #1): Il merchant/3DS Server avvia il processo 3DS inviando un AReq contenente i dati della transazione e del dispositivo. Per segnalare la capacità di supportare SPC, la richiesta può includere un indicatore come threeDSRequestorSpcSupport impostato su 'Y' (o simile, a seconda dell'implementazione del fornitore ACS).
2. Risposta di Autenticazione Iniziale (ARes #1): Se l'ACS determina che è necessaria una challenge e opta per SPC, risponde con un ARes che lo indica. Il transStatus potrebbe essere impostato su 'S' (indicando che è richiesto SPC) o un altro valore specifico. Questo ARes contiene il payload di dati necessario per la chiamata all'API SPC.
3. Invocazione dell'API SPC e Autenticazione FIDO: Il componente 3DS Requestor del merchant riceve l'ARes #1 e utilizza il payload per invocare l'API SPC del browser. L'utente interagisce con il proprio authenticator tramite l'interfaccia utente sicura del browser.
4. Restituzione dell'Assertion FIDO: Dopo l'autenticazione riuscita dell'utente, il browser restituisce i dati dell'assertion FIDO al 3DS Requestor.
5. Seconda Richiesta di Autenticazione (AReq #2): Il 3DS Requestor costruisce e invia un secondo messaggio AReq all'ACS. Lo scopo principale di questo messaggio è trasportare i dati dell'assertion FIDO. Tipicamente include:
   • ReqAuthData: Contenente l'assertion FIDO.
   • ReqAuthMethod: Impostato su '09' (o il valore designato per l'assertion SPC/FIDO).
   • Potenzialmente il valore AuthenticationInformation dall'ARes #1 per collegare le richieste.
   • Opzionalmente, un SPCIncompletionIndicator se la chiamata all'API SPC è fallita o è andata in timeout.
6. Risposta di Autenticazione Finale (ARes #2): L'ACS riceve l'AReq #2, convalida l'assertion FIDO utilizzando la chiave pubblica del titolare della carta e determina l'esito finale dell'autenticazione. Invia un ARes #2 contenente lo stato definitivo della transazione (ad esempio, transStatus = 'Y' per Autenticazione Riuscita, 'N' per Fallita).

Questo flusso a due AReq rappresenta una deviazione dai metodi di challenge 3DS tradizionali (come OTP o OOB gestiti tramite messaggi CReq/CRes o RReq/RRes) che tipicamente si completano all'interno del ciclo iniziale AReq/ARes dopo la ricezione di un transStatus = 'C'. Mentre la parte di interazione dell'utente di SPC (scansione biometrica, inserimento del PIN) è spesso significativamente più veloce della digitazione di un OTP, l'introduzione di un secondo round trip completo AReq/ARes aggiunge latenza di rete tra il 3DS Server, il Directory Server e l'ACS. Gli implementatori e i fornitori devono ottimizzare attentamente questo flusso e gestire i potenziali timeout per garantire che il tempo complessivo della transazione end-to-end rimanga competitivo e soddisfi le aspettative degli utenti.

La Secure Payment Confirmation è posizionata per un'adozione globale grazie alla sua duplice standardizzazione. È formalmente definita come standard web dal World Wide Web Consortium (W3C), avendo raggiunto lo stato di Candidate Recommendation a metà del 2023, con lavori in corso per diventare una Recommendation completa. Contemporaneamente, SPC è stata integrata nelle specifiche EMV® 3-D Secure a partire dalla versione 2.3, gestita da EMVCo, l'organismo tecnico globale per gli standard di pagamento. Questa integrazione garantisce che SPC funzioni all'interno del framework globale consolidato per l'autenticazione delle transazioni CNP. La collaborazione tra W3C, FIDO Alliance ed EMVCo sottolinea lo sforzo a livello di settore per creare standard interoperabili per pagamenti online sicuri e di facile utilizzo.

Sebbene il design di SPC, in particolare la sua capacità di collegare crittograficamente l'autenticazione dell'utente a dettagli specifici della transazione ("collegamento dinamico"), aiuti a soddisfare i requisiti di Autenticazione Forte del Cliente (SCA) secondo normative come la Direttiva sui Servizi di Pagamento (PSD2) europea, la sua utilità non è confinata a queste regioni con obblighi normativi. SPC è uno standard tecnico globale applicabile in qualsiasi mercato, inclusi Stati Uniti e Canada, a condizione che i componenti necessari dell'ecosistema siano presenti.

Nei mercati senza mandati SCA espliciti per ogni transazione, i principali motori per l'adozione di SPC sono:

• Migliore esperienza utente: Offrire un metodo di challenge potenzialmente più veloce e conveniente (ad esempio, utilizzando la biometria del dispositivo) rispetto agli OTP tradizionali o alle domande basate sulla conoscenza, riducendo potenzialmente l'abbandono del carrello. I progetti pilota hanno mostrato riduzioni significative del tempo di autenticazione rispetto alle challenge tradizionali.
• Maggiore sicurezza: L'autenticazione basata su FIDO, intrinseca in SPC, è resistente agli attacchi di phishing, al credential stuffing e ad altre minacce comuni che colpiscono password e OTP.

Pertanto, gli issuer e i merchant in regioni come il Nord America possono scegliere di implementare SPC strategicamente per migliorare la sicurezza e fornire una migliore esperienza cliente, anche senza un requisito normativo che lo imponga per tutte le transazioni.

L'implementazione di successo e l'adozione diffusa della Secure Payment Confirmation (SPC) dipendono fortemente da una preparazione coordinata tra i molteplici componenti dell'ecosistema dei pagamenti. Mentre gli standard FIDO sottostanti e la tecnologia delle passkey stanno maturando rapidamente, il supporto specifico a livello di browser per l'API SPC e la piena integrazione lungo tutta la catena di pagamento rimangono ostacoli critici. Gli altri attori dell'ecosistema stanno generalmente facendo buoni progressi.

Riepilogo della preparazione dell'ecosistema (Stato Maggio 2025)

Cosa significa in pratica (Maggio 2025)

Il principale fattore limitante per l'adozione di SPC è il livello dello user-agent (browser):

• Safari (macOS e iOS): ❌ WebKit manca ancora del metodo di Payment Request secure-payment-confirmation. Qualsiasi sito visitato in Safari deve ripiegare su altri metodi di autenticazione (OTP, OOB, potenzialmente esperienze WebAuthn non-SPC). Apple non ha espresso interesse a implementare l'estensione.
• Chrome / Edge (Chromium): ⚠️ La versione base di SPC (creazione e autenticazione delle credenziali) è stabile, ma le chiavi non sono ancora memorizzate negli authenticator hardware e sono state utilizzate solo in progetti pilota. Gli implementatori dovrebbero aspettarsi potenziali modifiche che potrebbero rompere la compatibilità e essere pronti a limitare la funzionalità in base a controlli di disponibilità delle API (ad es. canMakePayment()) o a feature flag.
• Firefox: ❌ Il team ha segnalato interesse ma non ha una tempistica di implementazione definita; i merchant devono pianificare percorsi di fallback graduali.

Poiché l'infrastruttura degli issuer (ACS, server FIDO) e i directory server degli schemi sono in gran parte pronti o in rapida evoluzione, e gli strumenti per merchant/PSP stanno diventando disponibili, la barriera principale all'uso diffuso di SPC è il supporto dei browser. Una volta che la copertura dei browser migliorerà, i compiti rimanenti riguarderanno principalmente l'integrazione da parte di merchant/PSP (aggiornamento a EMV 3DS v2.3+, aggiunta della logica di invocazione SPC, gestione del flusso a due AReq) e l'aumento della registrazione di passkey da parte degli issuer specificamente per contesti di pagamento.

Per ora, aspettiamoci che SPC appaia solo per una fetta limitata di transazioni. Finché Safari (e quindi l'intero ecosistema iOS) non fornirà supporto, SPC non potrà raggiungere il supporto di mercato.

L'analisi rivela una netta divergenza nella preparazione delle due principali integrazioni FIDO all'interno di EMV 3DS a maggio 2025. Mentre gli elementi fondamentali per la Secure Payment Confirmation (SPC) come metodo di challenge stanno avanzando – in particolare le capacità degli issuer/ACS e la preparazione degli schemi – la sua adozione diffusa è significativamente ostacolata dal collo di bottiglia critico del supporto dei browser, in particolare la mancanza di implementazione in Safari di Apple (che blocca tutti i dispositivi iOS/iPadOS) e Firefox, insieme alle limitazioni nelle attuali implementazioni di Chromium. SPC rimane uno stato futuro promettente, ma non è una soluzione pratica e onnipresente oggi.

Sulla base dello stato attuale dell'ecosistema, sono in vigore le seguenti raccomandazioni:

• Merchant:
  • Dare priorità all'adozione delle Passkey: Implementare le passkey per il login e l'autenticazione degli utenti. Oltre a migliorare la propria sicurezza e l'esperienza utente (fattori non dettagliati qui), questo crea i dati necessari per i flussi frictionless 3DS.
  • Trasmettere i dati FIDO: Assicurarsi che la propria integrazione 3DS popoli correttamente il campo threeDSRequestorAuthenticationInfo con i dettagli delle precedenti autenticazioni con passkey andate a buon fine durante la sessione di checkout. Lavorare con il proprio fornitore di PSP/3DS Server per abilitare questa funzione.
• Issuer:
  • Registrare le Passkey degli utenti: Iniziare a offrire e incoraggiare i titolari di carta a registrare le passkey direttamente con voi (per l'accesso all'app bancaria, future SPC, ecc.). Costruire l'infrastruttura FIDO Relying Party necessaria.
  • Sfruttare ora i dati delle Passkey dei Merchant: Istruire il proprio fornitore di ACS a recepire e utilizzare i dati FIDO trasmessi dai merchant (threeDSRequestorAuthenticationInfo) come un forte segnale positivo all'interno del proprio motore RBA. Mantenere registri delle passkey di merchant fidati associate agli utenti, ove possibile. Puntare ad aumentare significativamente le approvazioni frictionless per le transazioni precedute da una forte autenticazione con passkey del merchant.
  • Prepararsi per SPC, monitorare attivamente: Assicurarsi che la roadmap del proprio ACS includa il pieno supporto a EMV 3DS v2.3.1+ SPC, ma trattarlo come un miglioramento futuro. Monitorare continuamente gli sviluppi dei browser (specialmente Safari) per valutare quando SPC potrebbe diventare praticabile su larga scala.
• Fornitori di ACS:
  • Potenziare la RBA con l'intelligence delle Passkey: Investire massicciamente nella capacità del proprio motore RBA di elaborare e fidarsi dei dati FIDO/passkey forniti dai merchant. Sviluppare una logica per tracciare l'uso delle passkey attraverso gli acquisti dei merchant per un dato utente/dispositivo. Memorizzare le chiavi pubbliche (dalla registrazione diretta dell'issuer) per verificare l'integrità crittografica dei dati di autenticazione del merchant, se forniti. Collegare l'uso riuscito delle passkey direttamente a tassi di approvazione frictionless più elevati.
  • Costruire capacità SPC robuste: Continuare a sviluppare e certificare il pieno supporto al flusso di challenge SPC (EMV 3DS v2.3.1+) in preparazione per la futura adozione del mercato.
• Schemi/Reti di pagamento:
  • Promuovere i dati FIDO per il frictionless: Promuovere attivamente e potenzialmente incentivare la trasmissione e l'utilizzo dei dati di autenticazione FIDO del merchant (threeDSRequestorAuthenticationInfo) all'interno del flusso 3DS. Fornire una guida chiara e supporto agli issuer e ai fornitori di ACS su come sfruttare efficacemente questi dati per la RBA.
  • Continuare la promozione di SPC e l'impegno con i browser: Mantenere gli sforzi per standardizzare e promuovere SPC, impegnandosi criticamente con i fornitori di browser (Apple, Mozilla, Google) per incoraggiare un'implementazione completa e interoperabile dello standard API SPC.

L'opportunità immediata e tangibile risiede nel potenziare il flusso frictionless sfruttando la crescente adozione delle passkey a livello di merchant. Tutti i partecipanti all'ecosistema dovrebbero dare la priorità all'abilitazione della creazione, trasmissione e consumo intelligente di questi dati di autenticazione precedenti all'interno del framework EMV 3DS esistente. Questo percorso offre benefici a breve termine nella riduzione dell'attrito e potenzialmente delle frodi, senza attendere il supporto universale dei browser per SPC. Allo stesso tempo, preparare le basi per SPC – in particolare la registrazione delle passkey da parte degli issuer e la preparazione degli ACS – assicura che l'ecosistema sia posizionato per adottare questo metodo di challenge superiore una volta risolto il collo di bottiglia dei browser.