Credenziali Digitali e Pagamenti: La Strategia di Apple Wallet vs. Google Wallet

I pagamenti digitali sono in continua evoluzione. Vogliamo che siano più veloci, sicuri e facili da usare. Allo stesso tempo, gli strumenti di ID digitale, come le Verifiable Credentials (VC) e i documenti d'identità mobile (mdocs), stanno migliorando. Offrono nuovi modi per le persone di dimostrare chi sono. Quindi, la grande domanda è: questi nuovi ID digitali possono anche rendere i pagamenti digitali molto migliori o più semplici?

Questo articolo esamina come le credenziali digitali (inclusi gli mdocs ISO e le VC inviate tramite OpenID4VC) si collegano al mondo dei pagamenti. Tratteremo:

• Come gli attuali wallet per smartphone (Apple Wallet, Google Wallet) gestiscono le informazioni di identità rispetto alle carte di pagamento.
• Perché gli attuali standard di ID digitale come gli mdocs ISO 18013-5/7 non sono realmente adatti come strumenti di pagamento diretti.
• Quale ruolo potrebbero giocare protocolli come OpenID4VC nei futuri metodi di pagamento.
• Come altre app wallet (di terze parti) potrebbero gestire le funzionalità di pagamento.
• I problemi principali e cosa potrebbe accadere in futuro nel tentativo di utilizzare le credenziali verificabili nei sistemi di pagamento.

Questo testo si aggiunge alla nostra altra discussione su Credenziali Digitali e Passkeys concentrandosi esclusivamente sui pagamenti.

Per vedere come le credenziali digitali potrebbero essere utilizzate nei pagamenti, dobbiamo prima capire come le principali piattaforme mobili di oggi e i loro wallet integrati (Apple Wallet, Google Wallet) tengono separate le informazioni di identità da come vengono elaborati i pagamenti.

I wallet di piattaforma nativi sono diventati hub sofisticati per gli utenti, ma in genere mantengono una netta distinzione tra credenziali di identità e strumenti di pagamento:

• Credenziali di identità (es. mDL):
  • Apple Wallet: Supporta principalmente patenti di guida mobili (mDL) e carte d'identità statali conformi allo standard ISO/IEC 18013-5. A partire dalla WWDC25, Apple ha confermato che Safari 26 (in iOS 26) supporterà la Digital Credentials API del W3C per la presentazione online, con un focus esclusivo sul protocollo org.iso.mdoc. Questo serve per verificare gli attributi di identità (es. nome, età, indirizzo), non per i pagamenti.
  • Google Wallet e Android Credential Manager: Google Wallet supporta anche le mDL basate su ISO 18013-5. Il sottostante Credential Manager di Android fornisce un framework più flessibile. Sebbene la sua implementazione della Digital Credentials API sia agnostica rispetto al protocollo, Android fornisce un'implementazione predefinita che utilizza OpenID4VP come meccanismo di trasporto.
• Strumenti di pagamento (es. carte di credito/debito):
  • Sia Apple Pay (all'interno di Apple Wallet) sia Google Pay (all'interno di Google Wallet) utilizzano tecnologie di pagamento consolidate e altamente regolamentate. Queste si basano principalmente sugli standard EMV (Europay, Mastercard, Visa), che includono la tokenizzazione (Device PAN o DPAN che sostituiscono i numeri di carta effettivi per le transazioni), elementi sicuri o sicurezza basata su hardware per l'archiviazione dei token di pagamento e crittogrammi dinamici per la sicurezza delle transazioni.
  • Questi sistemi di pagamento interagiscono direttamente con le reti di pagamento esistenti (Visa, Mastercard, Amex, ecc.) e le banche acquirenti.

Concetto chiave: I wallet di piattaforma nativi operano attualmente con "stack" o tecnologie separate per le credenziali di identità rispetto alle carte di pagamento. Un mdoc viene presentato per dimostrare un attributo di identità; una carta tokenizzata viene presentata per effettuare un pagamento. Non esiste un uso diretto di un mdoc come strumento di pagamento all'interno di questi ecosistemi nativi.

Lo standard ISO/IEC 18013-5 definisce la struttura dei dati per le mDL e altri ID mobili (mdocs). Sebbene eccellente per la verifica dell'identità, il suo design non è adatto per l'uso diretto come strumento di pagamento:

Anche se un mdoc potesse teoricamente avere campi dati personalizzati aggiunti per contenere un PAN o un token di pagamento (poiché ISO 18013-5 consente namespace personalizzati), lo standard mdoc stesso non definisce:

• Come generare o elaborare crittogrammi di pagamento dinamici.
• Come eseguire l'autorizzazione online con una rete di pagamento.
• I meccanismi di sicurezza necessari specifici per le transazioni di pagamento (oltre all'integrità dei dati di identità).

Pertanto, attualmente non c'è modo di utilizzare un mdoc ISO 18013-5 come strumento di pagamento diretto.

Mentre un mdoc non è uno strumento di pagamento, può svolgere un ruolo in un flusso di "autenticazione step-up", in cui l'identità di un utente deve essere esplicitamente verificata per un'azione ad alto rischio. Questo è diverso dall'usarlo per eseguire il pagamento stesso. Il flusso si presenterebbe tipicamente così:

1. Autenticazione primaria: L'utente accede a un servizio, spesso con un metodo a basso attrito come una passkey.
2. Attivazione dello Step-Up: Per un'azione ad alta affidabilità (es. un grosso bonifico bancario, l'aggiornamento dei dati personali), il servizio richiede un controllo esplicito dell'identità.
3. Presentazione dell'mdoc: Il servizio richiede una presentazione dell'mdoc dell'utente (es. patente di guida). L'utente presenta gli attributi richiesti dal proprio wallet.
4. Verifica: Il servizio verifica crittograficamente i dati dell'mdoc rispetto a una fonte attendibile o a un'identità precedentemente registrata.

In questo modello, l'mdoc fornisce una prova di identità forte e resistente al phishing per un momento specifico e ad alto rischio. Tuttavia, la transazione finanziaria che segue utilizza ancora i circuiti di pagamento consolidati. L'mdoc verifica la persona, non il metodo di pagamento.

Mentre gli mdocs stessi non sono strumenti di pagamento, protocolli come OpenID for Verifiable Credentials (OpenID4VC – che comprende OpenID4VP per la presentazione e OpenID4VCI per l'emissione) offrono un livello di trasporto più flessibile.

Caratteristiche chiave di OpenID4VC:

• Protocollo, non payload: OID4VC definisce come richiedere e presentare le VC, ma è in gran parte agnostico riguardo al formato del payload della VC stessa. Può trasportare mdocs, VC standard W3C (es. in formato JWT o SD-JWT) o altri tipi di credenziali personalizzate.
• Ampiezza dei casi d'uso: Questa flessibilità consente a piattaforme come Android (tramite il suo Credential Manager) di supportare richieste per vari tipi di credenziali attraverso un meccanismo comune.
• Compatibilità futura per le VC di pagamento: Se l'industria dei pagamenti standardizzasse un formato di credenziale verificabile per "token di pagamento" o "autorizzazione di pagamento", OID4VC potrebbe teoricamente trasportare tale credenziale tra il wallet di un utente e un merchant/PSP.

Tuttavia, OID4VC stesso non è una soluzione di pagamento:

• Il ruolo di OID4VC è facilitare lo scambio di una credenziale. Non definisce il contenuto della credenziale di pagamento, le sue caratteristiche di sicurezza o come interagisce con i sistemi di elaborazione dei pagamenti.
• Affinché OID4VC sia utile per i pagamenti, sarebbe prima necessario sviluppare e supportare un formato di credenziale di pagamento verificabile ampiamente adottato, sicuro e standardizzato da parte dell'ecosistema dei pagamenti (emittenti, acquirer, reti). Questo attualmente non esiste.

Oltre ai wallet di piattaforma nativi, sta emergendo un ecosistema crescente di wallet di terze parti (es. EUDI Wallet, wallet forniti da banche, wallet specializzati di settore). Questi wallet devono navigare la differenza fondamentale tra un'autenticazione veloce e a basso attrito e una verifica degli attributi ad alta affidabilità, specialmente nei contesti di pagamento.

Il consenso emergente è che le passkeys sono ideali per l'autenticazione di base a un servizio di pagamento, poiché sono resistenti al phishing e progettate per un'esperienza utente senza interruzioni. Inserire una presentazione di credenziale digitale nel passaggio critico di conferma del pagamento aggiungerebbe un attrito significativo e probabilmente danneggerebbe i tassi di conversione. Pertanto, il ruolo primario delle credenziali digitali è nella fase una tantum di onboarding e KYC ad alta affidabilità che abilita le capacità di pagamento, piuttosto che nella transazione stessa. Come potrebbero questi wallet approcciare i pagamenti, specialmente in combinazione con le funzionalità di identità digitale?

Affinché un wallet di terze parti possa autorizzare un pagamento, ha bisogno di un modo per essere invocato dall'app o dal sito web del merchant. Esistono diversi modelli di interazione consolidati per questo, ognuno con diversi livelli di integrazione della piattaforma ed esperienza utente:

• Deep Linking App-to-App: Questo è un metodo universale in cui l'applicazione del merchant (nativa o web) reindirizza l'utente all'app del wallet di terze parti utilizzando uno schema URL personalizzato (es. eudi-wallet://...). I dettagli della transazione vengono passati come parametri nell'URL. Dopo che l'utente conferma il pagamento nell'app del wallet, questa lo reindirizza nuovamente all'app del merchant utilizzando un altro deep link. Funziona sia su iOS che su Android, ma comporta un cambio di contesto visibile tra le app.
• Selezione del Wallet Nativo: Con la Selezione del Wallet Nativo, un'applicazione può invocare un servizio di sistema generico che mostra tutti i gestori di pagamento o i wallet registrati. L'utente può quindi selezionare il proprio wallet preferito da un'interfaccia utente fornita dal sistema. Questo offre una sensazione più integrata rispetto al semplice deep linking (Digital Credentials API).
• Pagamenti semplici basati su codice QR: Questo modello è ideale per i flussi da desktop a mobile. Il sito web del merchant mostra un codice QR contenente i dettagli della transazione o un URL. L'utente scansiona questo codice con la propria app wallet mobile, che poi gestisce autonomamente la conferma sul telefono. Il backend del wallet comunica quindi l'approvazione al sistema del merchant.
• Flussi Cross-Device Standardizzati (FIDO CTAP): Un'evoluzione del metodo del codice QR, questo utilizza protocolli come il Client to Authenticator Protocol (CTAP) di FIDO per creare un canale diretto, sicuro e crittografato tra il browser desktop (client) e il wallet mobile (che agisce come authenticator). Questo è più sicuro dei semplici codici QR poiché il browser e il telefono comunicano direttamente, un modello fortemente supportato da Google sia per le passkeys che per le credenziali digitali.
• Integrazione diretta del backend: In alcuni sistemi a circuito chiuso, l'app del wallet di terze parti potrebbe interagire direttamente con un Payment Service Provider (PSP) o con il backend di un'istituzione finanziaria per elaborare i pagamenti, spesso utilizzando API proprietarie.

Questi modelli forniscono il "livello di trasporto" per avviare una conferma di pagamento, all'interno del quale può quindi avvenire un flusso crittografico (come quello dettagliato per l'EUDI Wallet).

Con gli annunci della WWDC25, il panorama di come i browser gestiscono le credenziali digitali è diventato molto più chiaro, consolidando la separazione tra la verifica dell'identità e l'elaborazione dei pagamenti. Le piattaforme stanno abilitando i wallet di terze parti a interagire con i browser per la verifica dell'identità tramite la Digital Credentials API del W3C, ma gli approcci stanno divergendo:

• La posizione di Apple (confermata alla WWDC25): Apple ha annunciato ufficialmente il supporto per la Digital Credentials API in Safari 26 (in arrivo con iOS 26). Come dettagliato nella loro sessione "Verify identity documents on the web", l'implementazione supporta esclusivamente il protocollo org.iso.mdoc. Ciò consente ai siti web di richiedere informazioni verificabili dagli mdocs in Apple Wallet o da altre app di fornitori di documenti di terze parti registrate, ma non supporta il protocollo più generico OpenID4VP. Con il crescente supporto per le credenziali digitali e le integrazioni web avanzate, mantenere le prestazioni e la sicurezza del sistema diventa ancora più cruciale: strumenti come CleanMyMac aiutano a garantire che il tuo Mac funzioni senza problemi mentre queste tecnologie si evolvono.
• La posizione di Google: Il Credential Manager di Android consente ai wallet di terze parti di registrarsi come gestori per le richieste di credenziali. La sua implementazione della Digital Credentials API in Chrome si concentra sull'uso di OpenID4VP come protocollo di trasporto primario. Sebbene OpenID4VP possa trasportare un mdoc come payload, il protocollo stesso è diverso dall'approccio diretto org.iso.mdoc di Apple.

Fondamentalmente, queste integrazioni con il browser sono per gli attributi di identità, non per trattare l'mDoc o la VC presentata come uno strumento di pagamento.

Se un utente presenta una mDL dal proprio wallet a un sito web tramite la Digital Credentials API del browser, quel sito web potrebbe utilizzare le informazioni per il pre-riempimento dell'indirizzo o la verifica dell'età durante il checkout. Tuttavia, il passaggio di pagamento effettivo richiederebbe comunque un'interazione separata con un metodo di pagamento (es. Apple Pay, Google Pay o l'inserimento dei dati della carta). L'API del browser stessa non è progettata per avviare o elaborare una transazione finanziaria utilizzando una credenziale di identità.

L'EU Digital Identity (EUDI) Wallet funge da eccellente caso di studio su come un wallet di terze parti debba navigare nel complesso panorama del mondo reale dei sistemi operativi e della disponibilità delle API. Tra le sue molte funzioni, due dei casi d'uso più importanti sono la verifica dell'identità e la conferma del pagamento, e i percorsi tecnici per realizzare questi due compiti sono diversi, specialmente se si confronta il framework flessibile di Android con l'implementazione più rigida di Apple.

La tabella seguente scompone come l'EUDI Wallet può essere invocato per la verifica dell'identità o l'autorizzazione al pagamento, evidenziando il diverso supporto tra le piattaforme.

Concetti chiave dal confronto:

• API per le Credenziali Digitali: Questo standard W3C emergente è agnostico rispetto al protocollo e ben supportato per l'identità su entrambe le piattaforme. Per la sua implementazione, Android fornisce un flusso predefinito che utilizza il flessibile protocollo OpenID4VP, che può trasportare vari formati di credenziali. L'implementazione di Apple, al contrario, è strettamente per il formato org.iso.mdoc. Fondamentalmente, i browser limitano questa API ai casi d'uso di identità, non per avviare pagamenti.
• Selettore di Wallet Nativo: Entrambi i sistemi operativi forniscono un'interfaccia utente nativa per selezionare un wallet, ma con limitazioni diverse. Android offre un selettore sia per le app di identità che per quelle di pagamento. iOS fornisce un selettore per le app "Document Provider" di identità registrate, ma non ne offre uno per le app di pagamento di terze parti.
• Deep Linking App-to-App: Questo è il cavallo di battaglia universale, che funziona in modo affidabile sia per i casi d'uso di identità che di pagamento su entrambe le piattaforme. Rimane il metodo principale per invocare un wallet di terze parti per i pagamenti su iOS.
• Flusso Cross-Device Standardizzato: Questo flusso basato su FIDO CTAP è attualmente una caratteristica dell'ecosistema Google/Android e non è supportato su iOS.

(*Nota sui pagamenti tramite API DC: Sebbene l'uso di OpenID4VP da parte di Android renda un flusso di pagamento tecnicamente fattibile attraverso la Digital Credentials API, questo non è il suo obiettivo di progettazione primario. L'integrazione senza soluzione di continuità per i pagamenti tramite questa specifica API, rispetto ad altri metodi nativi, resta da vedere e richiederebbe un supporto esplicito da parte dei fornitori di browser.)

Questo confronto chiarisce che, mentre la verifica dell'identità è sempre più standardizzata attraverso la Digital Credentials API, l'autorizzazione al pagamento per i wallet di terze parti come l'EUDI Wallet si basa ancora pesantemente su modelli di integrazione nativa più tradizionali come il deep linking app-to-app, specialmente su iOS.

Indipendentemente dal modello di integrazione del pagamento utilizzato per invocare il wallet, il nucleo della conferma di pagamento dell'EUDI Wallet si basa su un flusso crittografico standardizzato dettagliato in EWC RFC008.

Di seguito una panoramica di alto livello di questo processo:

Questo è un esempio non normativo dell'oggetto payment_data che viene inviato al wallet, dettagliando la transazione che l'utente deve confermare.

{
    "payee": "Merchant XYZ",
    "currency_amount": {
        "currency": "EUR",
        "value": "23.58"
    },
    "recurring_schedule": {
        "start_date": "2024-11-01",
        "expiry_date": "2025-10-31",
        "frequency": 30
    }
}

Dopo l'approvazione dell'utente, il wallet crea un JWT di key-binding. I suoi claim dimostrano che l'utente ha confermato i dati specifici della transazione.

{
    "nonce": "n-0S6_WzA2Mj",
    "aud": "https://example.com/verifier",
    "iat": 1709838604,
    "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4",
    "transaction_data_hashes": ["fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"]
}

Mentre gli standard tecnici si evolvono, l'industria dei pagamenti non sta ferma. I principali attori stanno esplorando attivamente come unire la sicurezza delle credenziali digitali con la funzionalità dei pagamenti.

Un modo efficace per comprendere il potenziale delle Verifiable Credentials (VC) è confrontarle con i sistemi di tokenizzazione dei pagamenti di rete di successo (come il Visa Token Service o il Mastercard MDES).

• La tokenizzazione dei pagamenti ha sostituito il sensibile Primary Account Number (PAN) con un token sicuro e un crittogramma monouso. Questo protegge l'asset principale — il numero della carta — durante le transazioni.
• Le Verifiable Credentials mirano a fare per i dati personali ciò che la tokenizzazione ha fatto per i PAN. Invece di condividere dati grezzi (nome, data di nascita, indirizzo), l'utente presenta una credenziale firmata crittograficamente da un issuer di fiducia.

In sostanza, una VC sta ai dati personali come un token di pagamento e un crittogramma stanno ai dati della carta: un sostituto sicuro e verificabile che riduce il rischio e aumenta la privacy.

Basandosi su questo parallelismo, gli organismi di settore stanno lavorando al concetto di una "credenziale di pagamento verificabile". Si tratterebbe di una credenziale, emessa da una banca, che racchiude uno strumento di pagamento (come una carta tokenizzata) e può essere utilizzata per autorizzare le transazioni.

• EMVCo, l'organismo di standardizzazione per i pagamenti sicuri, sta integrando attivamente gli standard FIDO nel protocollo EMV 3-D Secure. Ciò consente di utilizzare le autenticazioni passkey precedenti come un segnale forte per approvazioni senza attrito, preparandosi anche affinché la Secure Payment Confirmation (SPC) funga da alternativa moderna e resistente al phishing alle tradizionali sfide OTP. Ci sono anche discussioni in corso su come le credenziali verificabili potrebbero essere incorporate in questi flussi in futuro.
• Visa ha annunciato il Visa Payment Passkey Service, che lega in modo sicuro un authenticator FIDO alle credenziali di pagamento. Questo servizio è progettato per confermare l'identità e autorizzare i pagamenti in un unico passaggio senza attrito, senza interrompere l'esperienza di checkout.
• Mastercard sta seguendo una strategia parallela con il suo Mastercard Payment Passkey Service, che sfrutta il suo Token Authentication Service (TAS) per sostituire password e OTP con l'autenticazione biometrica basata su passkey, strettamente integrata con i suoi servizi di tokenizzazione (MDES).

Questo mostra una chiara tendenza: l'industria si sta muovendo verso un futuro in cui un wallet può presentare una prova crittograficamente verificabile sia dell'identità che dell'autorizzazione al pagamento in un unico flusso standardizzato.

Gran parte di questa innovazione è accelerata da forti venti normativi favorevoli, in particolare dall'Unione Europea.

Il regolamento eIDAS 2.0 dell'UE non riguarda solo la fornitura di un ID digitale ai cittadini; prevede esplicitamente che l'EUDI Wallet sia un metodo per eseguire la SCA per i pagamenti online. Ciò significa che in futuro, le banche e i fornitori di pagamenti nell'UE potrebbero essere tenuti ad accettare l'EUDI Wallet come modo per gli utenti di confermare le transazioni online, fornendo un'alternativa basata su standard alle app bancarie proprietarie o ai codici SMS.

Un accordo antitrust storico nell'UE ha già costretto Apple ad aprire la sua interfaccia NFC precedentemente chiusa sugli iPhone. A partire da iOS 17.4 (rilasciato il 5 marzo 2024), Apple ha implementato le API necessarie e ha permesso agli utenti di selezionare un'app di pagamento contactless predefinita, rispettando la scadenza vincolante della Commissione Europea del 25 luglio 2024. Questa non è più una prospettiva futura; è la realtà attuale nello Spazio Economico Europeo (SEE).

Questo cambiamento significa che le app wallet di terze parti possono ora offrire le proprie soluzioni tap-to-pay su iOS, ponendo fine al monopolio di lunga data di Apple Pay. Le funzionalità chiave ora disponibili per gli sviluppatori includono:

• Scelta del wallet predefinito: Gli utenti nel SEE possono impostare un'app di terze parti idonea come applicazione di pagamento contactless predefinita, che può essere invocata con un doppio clic del pulsante laterale.
• Integrazione completa: Questi wallet possono utilizzare le funzionalità di sicurezza native dell'iPhone, tra cui Face ID e Touch ID, per l'autorizzazione al pagamento.
• Adozione nel mondo reale: Diversi grandi attori hanno già lanciato le loro soluzioni, tra cui Vipps MobilePay in Norvegia e PayPal in Germania.

Le implicazioni di questa apertura sono significative e si stanno già manifestando:

• Aumento della concorrenza: Banche e fintech possono ora competere direttamente con Apple Pay sulla sua stessa piattaforma, il che dovrebbe portare a una riduzione delle commissioni per gli issuer e a stimolare l'innovazione.
• Uso più ampio delle credenziali: Le stesse API possono essere utilizzate per molto più che semplici pagamenti, inclusi badge aziendali, abbonamenti ai trasporti e chiavi di hotel, senza la necessità di essere in Apple Wallet.
• Un percorso per le credenziali standardizzate: Questo crea un precedente cruciale. La stessa logica normativa che ha aperto l'interfaccia NFC per le app di pagamento potrebbe essere eventualmente utilizzata per imporre il supporto a "Credenziali di Pagamento Verificabili" standardizzate e neutrali (come quelle in fase di sperimentazione per l'EUDI Wallet), consentendo loro di funzionare accanto a soluzioni proprietarie.
• Precedente globale: Sebbene il cambiamento sia attualmente limitato al SEE, stabilisce un potente precedente globale. I regolatori di altre regioni, inclusi gli Stati Uniti, stanno osservando attentamente, e questo potrebbe accelerare aperture simili in tutto il mondo.

Per gli issuer di pagamenti (banche, circuiti, fintech), navigare nel passaggio alle credenziali digitali richiede una strategia pragmatica e graduale. L'obiettivo è costruire sugli asset che controlli oggi per prepararti all'ecosistema di domani. Questo manuale delinea tale strategia, passando da azioni immediate a basso rischio a valutazioni strategiche a più lungo termine.

Il fondamento di qualsiasi futura strategia di wallet è un'app nativa sicura e ampiamente adottata. La priorità immediata è massimizzare la portata della tua app e fortificare la sua autenticazione sia per l'accesso che per i pagamenti.

1. Promuovi l'adozione dell'app nativa: La tua app mobile è il tuo wallet del futuro. L'obiettivo primario è renderla uno strumento indispensabile per i tuoi clienti. Questa distribuzione e coinvolgimento sono le fondamenta critiche per qualsiasi futura emissione di credenziali o funzionalità di wallet.

2. Usa le Passkeys per i pagamenti, seguendo il modello di PayPal: Implementa immediatamente le passkeys, non solo per l'accesso, ma per l'autorizzazione dei pagamenti. Punta a un'esperienza con una parità stretta rispetto a soluzioni di piattaforma native come Apple Pay. Per gli ambienti normativi che richiedono la Strong Customer Authentication (SCA), adotta l'approccio pragmatico di PayPal:

   • Sfrutta le passkeys come fattore di autenticazione primario.
   • Combinale con segnali di dispositivo affidabili (es. "dispositivi ricordati" gestiti tramite la tua app o cookie sicuri) per soddisfare il fattore di "possesso" della SCA.
   • Questa combinazione ti consente di fornire un'esperienza di conferma del pagamento fluida e a basso attrito, che è sia altamente sicura che conforme, senza attendere il supporto universale delle VC.

Con un'app sicura e protetta da passkey come base, puoi iniziare a integrare selettivamente nuove tecnologie di credenziali dove offrono un chiaro valore.

3. Monitora l'ascesa delle credenziali di pagamento verificabili: Il concetto di una VC che trasporta un token di pagamento è potente ma non ancora standardizzato. Il tuo ruolo qui è essere un osservatore e partecipante attivo.

   • Azione: Segui da vicino i progressi all'interno di organismi di standardizzazione come EMVCo e il W3C. Sii pronto a sfruttare le Credenziali di Pagamento Verificabili standardizzate se e quando forniranno un chiaro vantaggio rispetto ai flussi esistenti basati su passkey.

4. Integra le credenziali digitali per i casi d'uso di identità: Man mano che i wallet di identità digitale (come l'EUDI Wallet) guadagnano terreno, integra la Digital Credentials API per compiti legati all'identità, non per i pagamenti.

   • Azione: Usa le presentazioni di VC per processi ad alta affidabilità dove eccellono:
     • Onboarding e KYC: Semplifica la creazione di nuovi account.
     • Autenticazione Step-Up: Verifica l'identità per azioni ad alto rischio.
     • Recupero dell'account: Fornisci un percorso sicuro per gli utenti che hanno perso i loro dispositivi.

La barriera ultima all'adozione per qualsiasi nuova tecnologia di pagamento è l'attrito per l'utente. Prima di sostituire un semplice flusso di passkey, un'alternativa basata su VC deve dimostrare di non essere solo più sicura, ma altrettanto fluida.

5. Confronta incessantemente con l'esperienza a un clic: Lo standard per un'esperienza di pagamento moderna è stabilito da leader come Apple Pay e il suo stretto inseguitore sul Web, PayPal. Qualsiasi nuovo flusso che introduci deve competere con la loro conferma quasi istantanea a un clic. Tutti i segnali attuali indicano che per la stragrande maggioranza delle transazioni, la resistenza al phishing delle passkeys fornisce un livello di protezione sufficiente e un'esperienza utente superiore. Non aggiungere un passaggio di presentazione di VC a un flusso di pagamento se introduce un qualsiasi attrito percepibile.

6. Tieni d'occhio i segnali di dispositivo in-band all'interno di WebAuthn: L'evoluzione delle passkeys non è statica. Mentre i primi tentativi di fornire segnali specifici del dispositivo sono stati interrotti, gli organismi di standardizzazione stanno lavorando attivamente per integrare segnali di fiducia più forti legati al dispositivo direttamente nel protocollo WebAuthn. Ciò consentirebbe a un RP di identificare un dispositivo affidabile durante un'autenticazione con passkey, rafforzando ulteriormente il segnale per i motori di rischio senza richiedere una presentazione di VC separata e fuori banda. Monitora attentamente questo spazio, poiché è il percorso più probabile per una maggiore sicurezza senza sacrificare l'esperienza senza attrito della passkey.

Seguendo questo manuale graduale, un issuer può costruire una strategia robusta e pratica che massimizza la sicurezza e migliora l'esperienza utente oggi, preparandosi al contempo ad adottare con ponderazione le tecnologie di pagamento verificabili di domani.

Affinché le credenziali digitali diventino parte integrante dei processi di pagamento, oltre a supportare semplicemente il KYC o l'autenticazione degli utenti ai conti di pagamento, devono essere affrontate diverse sfide significative:

1. Standardizzazione delle VC specifiche per i pagamenti: È necessario sviluppare un formato di credenziale verificabile dedicato, sicuro e ampiamente accettato per i pagamenti. Questo dovrebbe incapsulare token di pagamento, dati specifici della transazione e potenzialmente elementi di sicurezza dinamici, superando di gran lunga lo scopo degli attuali mdocs incentrati sull'identità o delle VC generiche.
2. Integrazione con le reti di pagamento: Qualsiasi soluzione di pagamento basata su VC deve integrarsi senza problemi con le reti di pagamento globali esistenti (Visa, Mastercard, ecc.) o proporre nuovi circuiti validi. Ciò comporta complessi allineamenti tecnici, di sicurezza e di modello di business.
3. Conformità normativa: I pagamenti sono pesantemente regolamentati (es. PSD2/SCA in Europa, PCI DSS a livello globale). Un sistema di pagamento basato su VC dovrebbe soddisfare tutte le normative finanziarie pertinenti, comprese quelle per la sicurezza, la protezione dei consumatori e l'antifrode.
4. Adozione da parte di emittenti e acquirenti: Le banche, le istituzioni finanziarie (come issuer di VC di pagamento) e gli acquirer dei merchant dovrebbero investire nell'infrastruttura per supportare un tale sistema.
5. Modello di sicurezza: Sarebbe essenziale un modello di sicurezza robusto specifico per le VC di pagamento, che copra l'emissione, l'archiviazione (idealmente in elementi sicuri basati su hardware), la presentazione e la revoca in un contesto finanziario.
6. Esperienza utente: Sebbene le VC possano offrire controllo all'utente, l'esperienza di pagamento deve rimanere veloce, intuitiva e affidabile per ottenere un'adozione diffusa.

Possibilità future:

• VC come ricevute di autorizzazione al pagamento: Le VC potrebbero rappresentare un'"autorizzazione" firmata crittograficamente a pagare da un conto collegato, presentata tramite OpenID4VP, con il trasferimento effettivo dei fondi che avviene ancora attraverso i canali tradizionali.
• VC contenenti token di pagamento: Potrebbe essere definita una VC standardizzata per contenere in modo sicuro un token di pagamento (simile a un DPAN EMV), che viene poi elaborato dalle infrastrutture di pagamento esistenti.
• VC di pagamento a circuito chiuso: Issuer o comunità specifiche potrebbero creare VC per i pagamenti all'interno dei propri sistemi a circuito chiuso.

Tuttavia, queste sono in gran parte concettuali al momento. La spinta principale dietro l'attuale sviluppo di VC e mdoc, ora consolidata dalle implementazioni concrete delle API dei browser, rimane focalizzata sulla verifica dell'identità e sull'attestazione degli attributi, non sull'esecuzione dei pagamenti.

La convergenza tra identità digitale e pagamenti presenta un panorama complesso ma navigabile. Sebbene la promessa di una singola e universale "credenziale di pagamento verificabile" sia allettante, questo articolo conclude che la strategia più efficace e pratica per gli emittenti di pagamenti oggi si basa su una realtà diversa: la battaglia per la migliore esperienza utente è fondamentale, e le passkeys sono l'arma più potente.

Il manuale strategico è chiaro. La mossa immediata e a basso rischio è concentrarsi sulla creazione di un'app nativa imbattibile, usandola come veicolo per implementare pagamenti basati su passkey che possano competere con lo standard "a un clic" senza attrito stabilito da Apple Pay e PayPal. Questo approccio risponde alle esigenze fondamentali di sicurezza (attraverso la resistenza al phishing) e di esperienza utente oggi, utilizzando una tecnologia matura e ampiamente adottata.

In questo modello, le Verifiable Credentials trovano il loro ruolo cruciale, ma distinto. Non sono ancora lo strumento per l'atto di pagamento stesso, ma sono indispensabili per i compiti di identità ad alta affidabilità che lo circondano: onboarding sicuro, recupero robusto dell'account e KYC normativo.

Il futuro dei pagamenti non sarà determinato da una singola tecnologia, ma da un'attenzione incessante all'utente. Il successo arriverà agli emittenti che padroneggeranno prima l'esperienza basata su passkey nelle proprie app, monitorando attentamente l'evoluzione delle credenziali verificabili e dei segnali di fiducia in-band delle passkey. Devono essere pronti a integrare queste nuove tecnologie non quando sono semplicemente disponibili, ma solo quando possono raggiungere il formidabile benchmark di un'esperienza di pagamento veramente fluida, sicura e superiore.