Un futuro Permesso Internazionale di Guida (PIG) ha bisogno di trasparenza, ancoraggi di fiducia e responsabilità pubblica. Ciò di cui non ha bisogno — per impostazione predefinita — è inserire i guidatori stessi in un registro distribuito.
Ogni discussione seria su un PIG digitale e transfrontaliero attira inevitabilmente la stessa proposta: “Basta metterlo su blockchain.” Il fascino è comprensibile. Le blockchain offrono prove di integrità, visibilità condivisa e una cronologia append-only. Queste sono proprietà reali. Ma nel contesto dell’identità dei conducenti transfrontalieri, vengono molto spesso applicate al livello sbagliato.
Questo articolo spiega perché, illustra cosa dicono effettivamente gli standard e delinea un modello architetturale migliore.
Cosa Dicono Effettivamente gli Standard sulla Blockchain
Il W3C Verifiable Credentials Data Model afferma esplicitamente che un registro di dati verificabili può assumere molte forme, tra cui:
- Database affidabili
- Database decentralizzati
- Database di identità governativi
- Registri distribuiti
Il DID Core è ugualmente chiaro: molti metodi DID utilizzano la tecnologia a registro distribuito, ma non tutti. In altre parole, gli standard rigettano già l’idea che la blockchain sia una base obbligatoria per le credenziali digitali.
Questo è il punto di partenza corretto per un futuro PIG. La domanda utile non è “blockchain sì o blockchain no?” Bensì:
Quale livello necessita davvero di trasparenza, e quale livello non dovrebbe assolutamente diventare infrastruttura pubblica per impostazione predefinita?
La Blockchain È un Insieme di Proprietà, Non un Requisito
Il primo errore è trattare la “blockchain” come un singolo requisito. Non lo è. È un insieme di possibili proprietà, tra cui:
- Pubblicazione condivisa
- Cronologia append-only
- Operatività distribuita
- Generazione di ricevute
- Resistenza alle modifiche unilaterali
Alcune di queste sono utili per un futuro PIG. Altre sono irrilevanti. E alcune sono attivamente pericolose se applicate a soggetti titolari di credenziali. Il modello di registro W3C consente deliberatamente implementazioni multiple, poiché ecosistemi diversi richiedono compromessi diversi.
Tre Problemi che Non Devono Essere Combinati
Il secondo errore è quello di fondere tre problemi distinti in un unico sistema. Per un futuro PIG, questi devono rimanere separati:
- Dove risiede la verità legale. Il diritto di guidare appartiene ai registri patenti nazionali autorevoli.
- Come viene distribuito il materiale fiduciario. Le chiavi degli emittenti e i certificati dei verificatori appartengono a registri di fiducia controllati.
- Come l’ecosistema verifica le modifiche. Questo appartiene a un livello di trasparenza.
Gli ecosistemi reali funzionano già in questo modo. Il Digital Trust Service dell’AAMVA distribuisce le chiavi pubbliche degli emittenti in un elenco scaricabile prima che un verificatore interagisca con un mDL. Il manuale europeo per la patente di guida mobile specifica che gli Stati Membri notificano alla Commissione Europea gli emittenti mDL autorizzati, e la Commissione pubblica un elenco di verifica di tali autorità. Questa è distribuzione della fiducia senza blockchain.
Cosa ci Insegna la Certificate Transparency
Il modello di trasparenza più efficace sulla rete Internet pubblica non è una blockchain di consumo. È la Certificate Transparency (CT).
L’RFC 9162 descrive la CT come un protocollo per la registrazione pubblica dei certificati server TLS, in modo che chiunque possa:
- Verificare l’attività delle autorità di certificazione
- Rilevare certificati problematici o emessi erroneamente
- Controllare i log stessi
La lezione chiave di progettazione dalla CT: la trasparenza è più preziosa quando registra il comportamento degli emittenti e il materiale fiduciario — non l’attività degli utenti finali.
Applicato a un futuro PIG, ciò significa registrare elementi come:
- Emissione e rotazione delle chiavi degli emittenti
- Pubblicazione degli ancoraggi di fiducia
- Registrazione delle categorie di verificatori
- Modifiche alle politiche
- Dichiarazioni di conformità
- Eventi rilevanti per la sicurezza
Ciò che non significa è creare un registro pubblico o semi-pubblico di titolari, identificatori di credenziali o eventi di presentazione. Questa non è trasparenza. È raccolta eccessiva di dati.
SCITT: Perché Trasparenza Non Equivale a Verità
La bozza dell’architettura IETF SCITT estende questo ragionamento. SCITT definisce un Servizio di Trasparenza che mantiene una struttura dati verificabile ed emette ricevute crittografiche che provano l’inclusione di dichiarazioni firmate. L’identità del Servizio di Trasparenza è catturata da una chiave pubblica nota alle parti che fanno affidamento su di essa, e gli ancoraggi di fiducia e le politiche di registrazione sono resi a loro volta trasparenti.
Questo è un modello potente per l’infrastruttura PIG perché trasforma la trasparenza in un servizio verificabile attorno al materiale fiduciario e alle politiche — non attorno agli eventi di viaggio personali.
SCITT è anche chiaro sui limiti della trasparenza:
- Una dichiarazione registrata dimostra solo che un emittente l’ha prodotta e registrata — non che la dichiarazione sia corretta indefinitamente.
- Una dichiarazione firmata successiva può sostituirne una precedente.
- La trasparenza non impedisce agli emittenti disonesti o compromessi di agire; li rende responsabili.
Per l’identità dei conducenti, questa distinzione è di enorme importanza: un log di trasparenza è prova e cronologia di audit, non lo stato legale autorevole del diritto di guida di qualcuno.
SCITT osserva inoltre che un servizio di trasparenza può proteggere la propria sequenza append-only mediante una combinazione di hardware affidabile, protocolli di consenso e prove crittografiche. Anche il livello di trasparenza non richiede un unico specifico design blockchain. Il consenso è una delle opzioni, non l’unica.
La Corretta Separazione Architetturale per un Futuro PIG
Un futuro PIG dovrebbe separare le responsabilità in quattro livelli distinti:
- Registri autorevoli su chi può guidare (autorità nazionali di rilascio patenti)
- Registri di fiducia per le chiavi degli emittenti e dei verificatori
- Infrastruttura di stato per l’aggiornamento e la revoca
- Un livello di trasparenza opzionale per la verifica pubblica di politiche, ancoraggi di fiducia, ricevute e dichiarazioni di conformità

Una volta separati questi livelli, la questione blockchain diventa molto più nitida. Non è più “il futuro PIG dovrebbe essere su una blockchain?” Diventa:
Quale livello, se esiste, trae effettivamente beneficio da un audit pubblico append-only?
Cinque Motivi per cui l’Identità del Conducente On-Chain è la Scelta Predefinita Sbagliata
1. Crea Segnali di Tracciamento Duraturi
Il lavoro sulla privacy dell’EUDI spiega che le presentazioni di attestazioni possono contenere valori univoci come:
- Salt crittografici
- Valori hash
- Identificatori di revoca
- Chiavi pubbliche di binding del dispositivo
- Firme digitali
- Timestamp
Poiché tali valori sono fissi per la stessa attestazione, consentono alle parti che vi fanno affidamento di collegare transazioni diverse e costruire un profilo comportamentale dell’utente. L’EUDI avverte esplicitamente che ciò viola la ragionevole aspettativa che le attività separate del wallet non vengano combinate.
Se si pubblicano su un registro pubblico identificatori stabili del titolare, identificatori stabili delle credenziali, hash riutilizzabili o eventi di revoca individualmente tracciabili, non si sta risolvendo il problema del tracciamento — lo si sta rendendo permanente.
2. Espone gli Eventi di Revoca e Aggiornamento
La Raccomandazione W3C Bitstring Status List descrive chiaramente il problema: se esiste una mappatura uno a uno tra una credenziale e l’URL dove viene pubblicato il suo stato, il publisher può collegare il titolare, il verificatore e il momento del controllo. La specifica utilizza un esempio di patente di guida per illustrare perché essere tracciati dall’emittente al momento dell’accesso a un locale viola una comune aspettativa di privacy.
L’impostazione predefinita migliore proposta da Bitstring Status List:
- Elenchi di stato grandi e comprimibili in cui molte credenziali condividono una sola risorsa di stato
- Una lunghezza predefinita dell’elenco di 131.072 voci
- Le parti che vi fanno affidamento scaricano nuove versioni separatamente, senza autenticarsi
- Indici randomizzati e garanzie di privacy di gruppo
Questo è l’opposto delle tracce di revoca individualizzate on-chain.
3. Confonde lo Stato della Credenziale con lo Stato Legale di Guida
Una credenziale digitale può essere revocata perché il suo meccanismo di firma è stato compromesso — anche mentre il diritto di guida nel mondo reale rimane valido. Un registro pubblico di eventi sulle credenziali non è un sostituto affidabile dello stato autorevole di un registro patenti nazionale.
SCITT rafforza il concetto: una dichiarazione registrata può essere successivamente sostituita da una nuova, e le parti che vi fanno affidamento decidono cosa considerare attendibile in base alle politiche e alla cronologia. Il log non è una verità permanente. È prova di chi ha detto cosa, quando e in base a quale politica. L’autorità nazionale di rilascio patenti rimane la radice della verità legale.
4. Affronta il Problema di Governance Sbagliato
L’identità transfrontaliera dei conducenti non è principalmente un problema di consenso. È un problema di governance:
- Chi è autorizzato a emettere?
- Quali chiavi pubbliche sono attuali?
- Quali verificatori sono autorizzati?
- Quali richieste di dati corrispondono allo scopo dichiarato?
- Quale versione della politica era in vigore al momento?
Gli ecosistemi reali rispondono già a queste domande attraverso un’infrastruttura di fiducia governata, non attraverso un consenso decentralizzato:
- Il Digital Trust Service dell’AAMVA pubblica le chiavi pubbliche delle autorità emittenti in un elenco scaricabile.
- Il manuale europeo per la patente di guida mobile afferma che la Commissione Europea pubblica l’elenco degli emittenti mDL autorizzati.
- Il lavoro dell’ETSI sui certificati per le parti che fanno affidamento sul wallet fornisce l’autenticazione del verificatore leggibile automaticamente, con l’uso previsto e gli attributi richiesti registrati.
Questa è un’amministrazione esplicita della fiducia pubblica — non governance decentralizzata.
5. Non Risolve la Realtà sul Campo
Molte proposte blockchain assumono implicitamente che l’accesso alla rete in tempo reale sia un vantaggio. Per le credenziali dei conducenti — in particolare a bordo strada o durante i viaggi — spesso non lo è.
Le linee guida di implementazione dell’AAMVA specificano che:
- Il recupero dal dispositivo funziona senza connettività esterna sia per il titolare che per il lettore al momento della transazione.
- ISO/IEC 18013-5 richiede il supporto per il recupero dal dispositivo.
- L’accesso del verificatore alle chiavi pubbliche dell’emittente non deve avvenire al momento della transazione. Le chiavi possono essere scaricate in anticipo.
Se un verificatore può già convalidare localmente utilizzando materiale fiduciario memorizzato nella cache, una dipendenza blockchain in tempo reale non è essenziale. Nel migliore dei casi, è una scelta implementativa per alcune funzioni di audit nel back-end.
Cosa Dovrebbe Essere Trasparente in un Futuro PIG
Un futuro PIG ha assolutamente bisogno di trasparenza — nel posto giusto.
Rendere questi elementi trasparenti per impostazione predefinita:
- Chiavi pubbliche degli emittenti ed eventi di rotazione delle chiavi
- Ancoraggi di fiducia ed elenchi degli emittenti autorizzati
- Certificati di accesso dei verificatori e metadati sullo scopo registrato
- Versioni delle politiche e regole di registrazione
- Dichiarazioni di conformità e attestazioni di rilascio software rilevanti per la sicurezza
- Ricevute verificabili che provano la registrazione di tali dichiarazioni
Non rendere questi elementi pubblici per impostazione predefinita:
- Identificatori dei titolari su un registro pubblico
- Identificatori stabili di credenziali riutilizzati presso più verificatori
- Eventi di presentazione singoli
- Voci di revoca grezze che isolano una singola persona
- Dichiarazioni firmate complete contenenti dati personali quando hash o metadati sarebbero sufficienti
SCITT avverte esplicitamente gli emittenti di esaminare l’inclusione di informazioni private, riservate o personalmente identificabili prima di inviare dichiarazioni a un servizio di trasparenza. Nota inoltre che i servizi di trasparenza possono conservare solo metadati crittografici come gli hash — non dichiarazioni firmate complete.
Un Modello Migliore: Trasparenza Attorno all’Ecosistema, Non Attraverso la Persona
Un’architettura pulita per un futuro PIG si presenta così:
- Registro nazionale autorevole — rimane la fonte legale di verità per il diritto di guida.
- Livello credenziale — porta titoli di guida verificabili automaticamente al wallet del titolare.
- Livello del registro di fiducia — distribuisce chiavi degli emittenti, certificati dei verificatori ed elenchi degli emittenti autorizzati.
- Livello di stato — utilizza attestazioni di breve durata o elenchi di stato che preservano la privacy, aggiornati separatamente.
- Livello di trasparenza — può utilizzare o meno internamente il consenso, e registra ancoraggi di fiducia, modifiche alle chiavi, aggiornamenti delle politiche, ricevute e dichiarazioni dell’ecosistema che beneficiano di un audit pubblico append-only.
Questa architettura cattura le parti utili del pensiero blockchain — verificabilità append-only, scrutinio pubblico, prove di integrità, ricevute — senza trasformare il conducente nel soggetto pubblico del sistema. Corrisponde inoltre a ciò che gli standard descrivono già: i registri possono assumere forme diverse, i DID non richiedono registri distribuiti, i registri di fiducia esistono già e i meccanismi di stato che preservano la privacy sono già standardizzati.
L’Argomento Fondamentale
Il futuro PIG dovrebbe adottare la migliore idea della blockchain — la responsabilità pubblica per l’infrastruttura — senza adottarne il peggior default per le persone: il tracciamento duraturo e globalmente visibile.
In pratica, ciò significa:
- Trasparenza per gli emittenti, non esposizione dei titolari
- Ancoraggi di fiducia verificabili, non registri pubblici di viaggi
- Ricevute per politiche e registrazioni, non cronologie permanenti dell’utilizzo delle credenziali
- Prove append-only per la governance dell’ecosistema, non identità del conducente on-chain come impostazione predefinita
Questo non è un argomento contro la blockchain. È un argomento contro l’applicazione della blockchain al livello sbagliato.
Un futuro PIG potrebbe benissimo utilizzare servizi di trasparenza basati sul consenso da qualche parte nell’ecosistema. Ma se il design inizia mettendo il conducente, la credenziale o il percorso delle presentazioni su un registro, ha già scelto la scelta predefinita sbagliata.
Pubblicato Maggio 18, 2026 • 12m da leggere