Uno dei messaggi più forti emersi al Global Digital Collaboration Conference 2026 è che l’Age Verification non è più soltanto un esercizio architetturale, piuttosto un caso d'uso concreto: una fonte affidabile verifica l’età, un issuer genera una credenziale, il wallet la conserva e un Relying Party riceve esclusivamente l’informazione necessaria per autorizzare l’accesso a un servizio o l’acquisto di un prodotto
La domanda è molto semplice: per dimostrare di avere più di 18 anni, è davvero necessario comunicare la propria identità e la propria data di nascita? La risposta è: no.
Il collegamento con l’approccio dell’Unione Europea
Quanto mostrato a Ginevra si inserisce direttamente nel percorso descritto dalla Commissione europea. Il 14 luglio 2025 la Commissione ha reso disponibile il Blueprint della soluzione europea di Age Verification; il 15 aprile 2026 la soluzione è diventata “feature ready”, quindi personalizzabile dagli Stati membri e dagli operatori di mercato.
Nel modello presentato dalla Commissione europea, l’obiettivo non è necessariamente quello di condividere un documento di identità completo.
La verifica può partire da diverse fonti affidabili: identità elettronica nazionale, futuro EUDI Wallet, carta d’identità, passaporto, dati NFC del documento, informazioni già verificate da una banca o persino processi face-to-face. Queste fonti consentono a un issuer affidabile di generare un’attestazione relativa all’età. Il punto fondamentale è la data minimisation.
Un servizio che deve verificare se una persona può accedere a un prodotto o servizio riservato ai maggiorenni non ha necessariamente bisogno di conoscere nome, cognome, data di nascita, indirizzo o numero del documento. Ha bisogno soltanto di sapere: Age > 18 = TRUE
La stessa logica può essere applicata ad altre soglie: 13+, 15+, 16+, 18+, 60+, 65+ e così via.
È un cambiamento importante: si passa dalla condivisione dell’identità alla dimostrazione di un attributo.
Privacy by design: privacy yes, surveillance no
Uno degli aspetti più interessanti della soluzione europea è l'utilizzo delle Zero-Knowledge Proof (ZKP).
L'obiettivo è permettere all'utente di dimostrare di soddisfare una determinata condizione — ad esempio avere almeno 18 anni — senza rivelare ulteriori informazioni personali.
Durante la sessione è stato mostrato come una ZKP possa consentire al Relying Party di verificare esclusivamente il risultato della condizione richiesta, evitando al tempo stesso che diverse presentazioni della credenziale possano essere facilmente collegate allo stesso individuo.
La soluzione è infatti progettata affinché:
- venga condivisa soltanto l'informazione relativa alla soglia di età;
- l'issuer non possa vedere dove la credential viene utilizzata;
- visite separate non possano essere facilmente correlate allo stesso utente;
- il sistema non diventi uno strumento di monitoraggio della navigazione.
È quindi un approccio molto diverso da una verifica tradizionale basata sull'upload della carta d'identità.
Banche come issuer di attributi verificati
Una banca possiede già informazioni affidabili sull'identità dei propri clienti perché deve effettuare processi di onboarding, KYC e controlli AML.
Perché quindi chiedere nuovamente al cliente di mostrare un documento quando la banca ha già verificato quella stessa informazione?
La banca assume un ruolo differente da quello tradizionale: diventa un issuer di attributi verificati.
Le informazioni già validate durante il processo di onboarding vengono trasformate in una Electronic Attestation of Attributes (EAA) o, più genericamente, di una verifiable credential firmata crittograficamente dall'issuer. Il merchant non deve interrogare ogni volta la banca. La fiducia diventa portabile!
Google Wallet come contenitore della credenziale
Dall'online banking, il cliente richiede la propria Age Credential. Dopo una strong authentication, il processo di emissione della credenziale viene avviato Android Credential Manager richiama il wallet, la credenziale viene firmata e l’utente conferma l’aggiunta a Google Wallet
Il wallet non è più soltanto il luogo in cui conservare carte di pagamento, boarding pass o loyalty card: diventa progressivamente un container per digital identity credentials.
Il punto di vista del Relying Party
La seconda parte della demo ha ribaltato la prospettiva. Google ha mostrato il funzionamento non come wallet provider, ma come Relying Party che deve verificare l'età dell'utente.
Quando un servizio Google richiede una verifica, l'utente può selezionare la propria digital credential. Il browser mostra:
chi sta richiedendo l'informazione → quale credential può essere utilizzata → quale attributo viene richiesto.
L'utente autorizza quindi la presentazione.
Dietro questa esperienza apparentemente molto semplice viene verificata la Zero-Knowledge Proof e controllato che la credential provenga da un issuer trusted. Il dato ricevuto dal Relying Party è però soltanto quello necessario: 18+.
Open standards come fattore abilitante
Google ha evidenziato investimenti sull'intero stack delle digital credentials — Wallet, Android e Chrome Digital Credentials API — basandosi su standard e iniziative provenienti da ecosistemi come ISO, W3C e FIDO.
Il vantaggio non è soltanto tecnologico. L'utilizzo di standard comuni consente di riutilizzare la stessa infrastruttura per credential differenti, riducendo significativamente l'effort necessario per introdurre nuovi use case. In altre parole, l'Age Verification potrebbe essere soltanto uno dei primi casi d'uso visibili di un'infrastruttura destinata a gestire molti altri attributi verificabili.
Dall'online al mondo fisico
La stessa Age Credential presente nel wallet è stata utilizzata sia in un e-commerce sia presso un distributore automatico fisico.
Nel primo caso, durante il checkout l'utente seleziona Google Wallet come metodo per verificare l'età. Il merchant riceve esclusivamente Age over 18 e non gli altri dati personali dell'utente.
Nel secondo caso, la stessa credentiale viene presentata attraverso un terminale NFC. Il sistema verifica l'età e autorizza l'operazione senza memorizzare l'identità del cliente.
Il dato industriale più interessante è che l'infrastruttura hardware necessaria esiste già. Supermercati, stazioni di servizio, negozi e kiosk dispongono già di milioni di terminali NFC utilizzati quotidianamente per i pagamenti. In prospettiva, gli stessi terminali potrebbero diventare anche punti di verifica delle credenziali digitali.
Ciò che deve evolvere è soprattutto il software e la trust infrastructure che permette di sapere quali issuer e quali credential possano essere considerate affidabili.
Il prossimo tassello: governance e trust model europeo
La Commissione ha raccomandato agli Stati membri di preparare il rollout delle soluzioni di age verification entro la fine del 2026, utilizzando il blueprint, predisponendo piani di implementazione e cooperando con Commissione, Digital Services Coordinators, ricerca e società civile. Sono inoltre richiesti elevati livelli di cybersecurity e privacy, sottoposti a valutazione indipendente.
Il passaggio decisivo sarà l’EU Age Verification Scheme, destinato a definire governance, modello di fiducia e requisiti per gli operatori che vogliono agire come issuer di proof-of-age o offrire soluzioni di verifica. La Commissione prevede anche elenchi europei di provider e soluzioni trusted. È qui che la demo tecnica incontra la realtà regolatoria: l’interoperabilità non dipende soltanto dal formato della credenziale, ma anche da regole condivise su chi può emetterla e su come viene riconosciuto.
Implicazione per l’EUDI Wallet Age verification è un caso d’uso anticipatore: dimostra oggi una logica — issuer, wallet, presentazione, Relying Party e trust registry — destinata a diventare centrale nell’ecosistema EUDI.
La vera sfida è l’adozione
La tecnologia è ormai abbastanza matura per sperimentazioni concrete, ma rimangono due ostacoli: disponibilità delle credenziali ed educazione dell’utente. L’esperienza è fluida quando la prova è già nel wallet; lo è meno quando l’utente deve interrompere il processo per procurarsela.
Un’evoluzione naturale è l’issuance contestuale: nel momento in cui il servizio richiede una prova, l’utente dovrebbe poter individuare un issuer idoneo, ottenere la credenziale e riprendere il flusso. Questo trasforma la verifica da punto di attrito a porta d’ingresso nell’ecosistema wallet.
Invece di mostrare “No ID found” il servizio potrebbe permettere all'utente di ottenere immediatamente la credential necessaria e proseguire nella stessa esperienza.
Il momento della verifica diventerebbe così anche un momento di onboarding al wallet ecosystem
Cosa significa per l'EUDI Wallet ecosystem
Pur essendo focalizzata sull'Age Verification, la sessione mostra qualcosa di molto più ampio.
Stiamo iniziando a vedere materializzarsi un ecosistema nel quale:
trusted issuer → credential → wallet → presentation → relying party → trust infrastructure
non è più soltanto un diagramma architetturale.
Banche e soggetti pubblici possono diventare issuer; wallet differenti possono conservare e presentare credential; browser e sistemi operativi possono fornire le API di presentazione; merchant e piattaforme digitali diventano Relying Party.
E la privacy by design non viene aggiunta alla fine del processo, ma diventa una caratteristica dell'architettura stessa.
Dalla sperimentazione al mercato
L’Age Verification è un caso d’uso circoscritto, ma rende visibile il cambiamento di paradigma: dal documento completo alla prova selettiva di un attributo; da integrazioni bilaterali a credenziali portabili; da un’identità esposta a una verifica privacy-preserving.
La sessione di Ginevra mostra che il wallet può diventare un’infrastruttura quotidiana per lo scambio affidabile di attributi. Il blueprint europeo fornisce una base comune, la compatibilità con l’EUDI Wallet evita soluzioni isolate e il futuro scheme europeo dovrà dare consistenza al modello di fiducia. La prossima fase non sarà soltanto costruire i wallet, ma rendere disponibili credenziali utili e convincere i Relying Party a richiedere meno dati, con più fiducia
