Il 24 dicembre 2026 è una data importante per la governance digitale europea: è la scadenza entro cui ogni Stato membro dell’Unione deve mettere a disposizione dei propri cittadini almeno un European Digital Identity Wallet (EUDI Wallet). Si tratta di un’applicazione che consente di archiviare attributi di identità verificati, come nome, data di nascita, codice fiscale, titoli di studio, patente di guida, tessera sanitaria e di condividerli selettivamente con servizi pubblici e privati in tutta l’Unione.
Rispetto al modello attuale, frammentato tra SPID, CIE, sistemi bancari di identità e infinite credenziali proprietarie, l’EUDI Wallet introduce tre miglioramenti strutturali: l’interoperabilità europea; la portabilità degli attributi e – per lo meno sulla carta – il principio di minimizzazione selettiva, ossia la possibilità di dimostrare un attributo (ad esempio “sono maggiorenne”) senza rivelare il dato sottostante (dunque, la data di nascita).
La parola d’ordine della comunicazione istituzionale del progetto è “self-sovereign identity“: il cittadino sovrano della propria identità digitale. Ma l’espressione merita un’analisi critica, perché nasconde possibili zone d’ombra che chi si occupa di data protection non può ignorare.
Indice degli argomenti
L’architettura dell’EUDI Wallet: dove nascono i rischi per i dati personali
Per comprendere i rischi di privacy, è necessario ripercorrere come funziona il wallet a livello architetturale. Il sistema si articola in tre strati, ciascuno dei quali coinvolge uno specifico attore.
Il wallet provider è l’entità che distribuisce l’applicazione: tipicamente lo Stato membro, attraverso un ente pubblico (in Italia, AgID con IT Wallet), oppure un soggetto privato certificato. È lui a certificare l’identità del titolare del portafoglio digitale e a garantire l’integrità delle credenziali.
L’attestatore di attributi, invece, è l’entità che emette l’attestazione elettronica di attributi, le c.d. credenziali verificabili. Si pensi alla motorizzazione che emette la patente digitale, al ministero dell’istruzione che emette il titolo di studio, alla banca che certifica il conto corrente. Ogni attributo ha il proprio attestatore, con le proprie politiche di trattamento dei dati.
La relying party, infine, è il soggetto pubblico o privato che riceve gli attributi presentati dall’utente attraverso l’EUDI Wallet: un hotel che verifica l’età, un’agenzia di noleggio che controlla la patente, un sito di e-commerce che richiede l’identità per un acquisto, una procedura istituzionale che richiede il titolo di studi. Si ha a che fare con un universo variegato di soggetti politiche di conservazione dei dati anche molto diverse tra loro.
Fino a qui, il modello è lineare e privacy-preserving. I problemi emergono nei livelli di dettaglio che questa descrizione semplificata non mostra.
Chi è il titolare del trattamento nel sistema EUDI Wallet e GDPR
La prima domanda giuridica fondamentale da porsi è: quando un cittadino usa il wallet per autenticarsi su un servizio, chi è il titolare del trattamento dei suoi dati personali? La risposta non può che essere “dipende”: la complessità è strutturale, perché ogni attore del sistema solleva interrogativi propri.
Il wallet provider tratta i dati dell’utente per gestire l’account, verificare l’identità iniziale e garantire la continuità del servizio: per queste attività è indubbiamente titolare del trattamento. Ma la sua natura, pubblica o privata, incide anche sulla politica di conservazione dei dati.
L’attestatore di attributi tratta i dati per emettere la credenziale verificabile. Ma li tratta anche per registrare l’utilizzo della credenziale? Sa quante volte e con quali relying parties è stato condiviso l’attributo? A fare chiarezza interviene l’Architecture and Reference Framework (ARF): il documento con cui la Commissione europea, insieme agli Stati membri e agli esperti del settore, traduce gli obblighi del regolamento eIDAS 2.0 in specifiche operative che wallet provider e attestatori devono rispettare per essere interoperabili a livello europeo. Secondo l’ARF, il design del wallet prevede che l’attestatore non venga notificato a ogni presentazione della credenziale rilasciata: sulla carta, una garanzia solida. Nella pratica, però, è più fragile: l’unlinkability, ancora in fase di sviluppo, sembra valere soprattutto per la relying party, non necessariamente per il wallet provider.
La relying party riceve gli attributi dell’utente e, in qualità di titolare, li tratta per le proprie finalità. Tuttavia, il regolamento eIDAS 2.0 non risolve esplicitamente il tema della data retention né chiarisce la possibilità di combinazione con altri dati: stabilisce le responsabilità tecniche e di sicurezza, ma non mappa in modo sistematico le titolarità del trattamento ai sensi del GDPR.
Il problema invisibile dei metadati di utilizzo del wallet
Esiste, inoltre, una categoria di dati che la narrazione ufficiale sul wallet tende a trascurare: i metadati di utilizzo. Non il contenuto delle credenziali presentate, ma le informazioni contestuali sull’utilizzo del portafoglio digitale stesso.
Ogni volta che un utente usa il wallet, si genera potenzialmente una traccia: quando è avvenuto l’utilizzo, con quale relying party, quale credenziale è stata presentata, da quale dispositivo e da quale posizione geografica. Questi dati non rivelano il nome o il codice fiscale dell’utente, ma nella loro aggregazione rivelano i pattern di vita di una persona. Un esempio concreto: se un wallet registra che l’utente ha usato la propria credenziale di età adulta alle 23:47 di sabato sera in una determinata area geografica, poi ha presentato la propria identità in una struttura sanitaria il lunedì mattina, poi ha usato il wallet per accedere a un sito di ricerca di lavoro, questi metadati aggregati disegnano un profilo comportamentale dettagliato senza che nessuna singola credenziale sia stata “abusata”.
eIDAS 2.0 e GDPR: complementarità sulla carta, frizioni nella pratica
Resta da considerare il rapporto tra eIDAS 2.0 e GDPR: in teoria i due regolamenti convivono per complementarità; in pratica, il GDPR si applica integralmente al wallet, ma alcuni profili di eIDAS 2.0 creano frizioni con la disciplina sulla protezione dei dati personali.
Infatti, alcune implementazioni del wallet prevedono credenziali a divulgazione zero-knowledge (ZKP) che permettono di provare attributi senza rivelare il dato sottostante. Tale approccio sarebbe del tutto coerente con la pseudonimizzazione descritta dal GDPR, ma nella pratica le ZKP sono computazionalmente costose, il che ne limita l’effettiva implementazione.
Un secondo profilo di frizione riguarda il fatto che il wallet si presenti come single point of identity. Se da un lato il GDPR promuove la minimizzazione dei dati e la distribuzione del rischio, dall’altro il wallet europeo crea per definizione un punto centralizzato di gestione dell’identità. Tale strumento non crea un database centrale, poiché le credenziali restano sul dispositivo dell’utente; genera, tuttavia, rischi che crescono su tre livelli. A livello individuale, un solo fattore di sblocco (PIN, dato biometrico) protegge contemporaneamente tutti gli attributi di un soggetto, con un raggio d’azione ben più ampio di una singola credenziale rubata. A livello infrastrutturale, una compromissione della catena di certificazione o delle liste di trust nazionali su cui si basa eIDAS 2.0 non resta un incidente isolato, ma si propaga potenzialmente a livello nazionale o europeo. A livello normativo, infine, l’obbligatorietà de facto del wallet, unita alla sua natura di punto unico di autenticazione, crea le condizioni perché un intervento legislativo relativamente limitato – come l’espansione delle finalità d’uso a scopi di ordine pubblico o la condivisione di metadati con autorità governative – trasformi la stessa infrastruttura di fiducia in uno strumento di sorveglianza.
Raccomandazioni per cittadini, DPO, aziende e legislatore
Le criticità individuate finora possono essere tradotte in comportamenti concreti e raccomandazioni per ciascuno dei soggetti che, a vario titolo, dovranno interagire con questo sistema.
Cittadini
Per i cittadini, la raccomandazione più immediata è di natura comportamentale prima ancora che giuridica: prima di attivare l’account vale la pena dedicare qualche minuto a leggere la politica di trattamento dei dati del wallet provider nazionale, esattamente come si dovrebbe fare con qualunque app che chiede accesso a dati personali. Nell’uso quotidiano il principio guida dovrebbe essere la parsimonia: se un servizio chiede solo la conferma della maggiore età, non ha senso condividere l’intera credenziale di identità, anche quando l’interfaccia lo rende comodo. È, inoltre, buona prassi consultare periodicamente il log delle transazioni che il wallet è tenuto a rendere disponibile, non per sospetto ma per abitudine, e considerare i diritti di accesso e cancellazione previsti dal GDPR come strumenti da esercitare con regolarità, non solo in risposta ad un incidente.
DPO delle pubbliche amministrazioni
Per i DPO delle pubbliche amministrazioni, l’adozione dell’EUDI Wallet come sistema di autenticazione non è un evento tecnico da recepire passivamente, ma un trattamento che va mappato come tale: significa aggiornare il registro dei trattamenti con una voce dedicata, definire sin da subito una policy di retention che eviti di conservare gli attributi ricevuti oltre lo stretto necessario e rivedere le informative privacy affinché menzionino esplicitamente il wallet tra i canali di autenticazione. A questo si aggiunge un compito meno scontato: valutare se l’introduzione di tale strumento, per volumi o natura dei dati trattati, faccia scattare l’obbligo di DPIA, una verifica che rischia di essere rimandata se il wallet viene percepito, erroneamente, solo come un metodo di login.
Aziende private come relying party
Per le aziende private che agiranno da relying party, la raccomandazione centrale riguarda la necessità di rispettare rigorosamente il principio di minimizzazione e di limitazione delle finalità. Il fatto che il wallet renda la raccolta di dati verificati particolarmente semplice, non attenua gli obblighi connessi a tali principi.
Wallet provider e attestatori di attributi
Per i wallet provider e gli attestatori di attributi, la sfida principale è di trasparenza verso l’utente e verso l’autorità di controllo: rendere conto pubblicamente delle proprie politiche di conservazione dei metadati di utilizzo, adottare di default le implementazioni di divulgazione selettiva e di unlinkability previste dalle specifiche ARF ove tecnicamente disponibili.
Legislatore
Per il legislatore, infine, il compito è colmare gli spazi che eIDAS 2.0 lascia volutamente aperti: fissare per legge limiti espliciti alla raccolta di metadati da parte dei wallet provider, istituire un meccanismo di audit indipendente sull’utilizzo dei dati del portafoglio elettronico e, soprattutto, garantire che la volontarietà dell’adesione resti sostanziale e non solo formale, mantenendo canali di autenticazione alternativi per i servizi pubblici essenziali. È su questo punto che si gioca la differenza tra uno strumento di autodeterminazione informativa e uno strumento che lo diventa solo a parole.
Conclusioni: la self-sovereign identity è un obiettivo, non ancora una realtà
L’EUDI Wallet è un progetto ambizioso e strutturalmente valido. Le critiche possibili non riguardano tanto la direzione di marcia – un sistema di identità digitale interoperabile, portabile e user-centric è preferibile al caos attuale – quanto la distanza tra la narrazione e la realtà giuridica attuale.
La “self-sovereign identity” presuppone che l’individuo sia davvero sovrano, che controlli quali dati condivide, con chi, quando e che possa esercitare i propri diritti in modo effettivo su ciascuno dei nodi del sistema. Questa condizione non pare garantita dall’architettura tecnica di eIDAS 2.0, né può esserlo automaticamente per effetto della sola applicazione del GDPR a un sistema multi-actor in cui le titolarità del trattamento restano ancora in parte indefinite.
La scadenza del 24 dicembre 2026 si avvicina. L’Italia sta sviluppando IT Wallet. I cittadini italiani si troveranno presto con un portafoglio digitale nelle tasche probabilmente senza aver avuto la possibilità di comprendere appieno cosa contiene, chi vi accede e di cosa i diversi attori hanno visibilità. È forse compito di giuristi, DPO e giornalisti specializzati colmare questo deficit informativo prima, e non dopo, il deployment.
Partecipa alla community