Nessuno standard singolo sostituirà il Permesso Internazionale di Guida (IDP) cartaceo. Il vero successore è uno stack di standard che lavorano insieme — e comprendere questo stack è la chiave per capire dove stanno davvero andando le credenziali digitali di guida transfrontaliere.
Perché Nessuno Standard Singolo Sostituirà l’IDP Cartaceo
La maggior parte delle discussioni sul futuro IDP inizia con la domanda sbagliata: quale standard sostituirà il permesso cartaceo? Questa impostazione presuppone che una sola specifica possa svolgere l’intero lavoro. Non può.
Il lavoro del NIST sull’mDL (patente di guida mobile) nota esplicitamente che nuovi standard per le credenziali digitali stanno emergendo in aree problematiche separate. La famiglia ISO 18013 stessa è già suddivisa in più parti che coprono il design fisico, la sicurezza, la presentazione mobile e le estensioni internet. Una futura credenziale di guida transfrontaliera non è quindi un’unica specifica — è uno stack coordinato di specifiche, ognuna delle quali gestisce una problematica distinta.
Lo Stack del Futuro IDP in Sintesi
Ecco gli otto livelli che, presi insieme, definiscono come apparirà un futuro IDP:
- Livello 0 — Base fisica e dei dati: ISO/IEC 18013-1
- Livello 1 — Sicurezza della credenziale: ISO/IEC 18013-3
- Livello 2 — Presentazione di prossimità (di persona): ISO/IEC 18013-5
- Livello 3 — Presentazione remota / via internet: ISO/IEC 18013-7
- Livello 4 — Semantica della credenziale: W3C Verifiable Credentials Data Model 2.0
- Livello 5 — Protocollo di emissione: OpenID4VCI
- Livello 6 — Protocollo di richiesta e presentazione: OpenID4VP
- Livello 7 — Distribuzione della fiducia e autorizzazione del verificatore: Registri di fiducia (modello VICAL di AAMVA, modello EUDI basato su certificati per le parti facenti affidamento)
Ogni livello è fondato su standard attuali o documentazione attiva dell’ecosistema. Le sezioni seguenti spiegano cosa fa ciascun livello — e, altrettanto importante, cosa non fa.
Livello 0 — ISO/IEC 18013-1: La Fondazione Fisica e Semantica
La Parte 1 è più importante di quanto la maggior parte delle persone realizzi, perché non riguarda solo il design della carta.
ISO/IEC 18013-1 definisce le caratteristiche fisiche e il set di dati di base di una patente di guida conforme agli standard ISO, creando una base comune per l’uso internazionale e il riconoscimento reciproco. È costruita attorno a una carta sicura di formato ID-1 abbinata a un libretto per uso internazionale, sostituendo il vecchio modello IDP cartaceo. L’ISO sottolinea inoltre che, in molti casi, una singola carta può sostituire la necessità di due documenti separati.
L’implicazione pratica è semplice: il futuro IDP non può partire dal livello del portafoglio digitale. Se la struttura del documento sottostante, il modello dei dati e il layout non vengono prima standardizzati, ogni livello digitale superiore diventa una correzione di compatibilità applicata su formati nazionali frammentati. La Parte 1 è la fondazione da cui dipende il resto dello stack.
Livello 1 — ISO/IEC 18013-3: Sicurezza della Credenziale
La Parte 3 è dove la credenziale passa dall’essere un dato su un documento a diventare un oggetto di sicurezza. L’ISO descrive 18013-3 come la parte che specifica i meccanismi per:
- Controllo degli accessi ai dati leggibili da macchina
- Autenticazione del documento
- Validazione dell’integrità
L’ISO è tuttavia esplicita nel precisare che la Parte 3 non affronta le questioni di privacy relative all’uso successivo dei dati — e questo confine è importante.
In sintesi, 18013-3 garantisce la sicurezza della credenziale, non la governance completa dell’ecosistema. Aiuta a rispondere a domande come: Questa credenziale è stata emessa dall’autorità dichiarata? I dati sono stati alterati? Non risponde pienamente a: Questo verificatore dovrebbe richiedere questo campo? Questa richiesta dovrebbe essere consentita in questo contesto?
Questo è anche un livello attivo piuttosto che un prodotto finito. L’ISO elenca un emendamento del 2022 per il protocollo PACE, un emendamento del 2023 per gli aggiornamenti all’autenticazione passiva, e una nuova bozza di 18013-3 attualmente in fase di sviluppo.
Livello 2 — ISO/IEC 18013-5: Presentazione Mobile di Persona
Se la Parte 1 definisce il documento e la Parte 3 lo protegge, la Parte 5 trasforma la patente in una credenziale mobile.
L’ISO specifica che 18013-5 copre l’interfaccia tra l’mDL e il lettore, e tra il lettore e l’infrastruttura dell’autorità emittente. Consente inoltre a terze parti — incluse autorità e verificatori di altri paesi — di:
- Ottenere dati mDL tramite macchina
- Collegare tali dati al titolare
- Autenticarne l’origine
- Verificarne l’integrità
Ciò che 18013-5 non copre è altrettanto importante. L’ISO elenca esplicitamente gli elementi fuori ambito, tra cui le modalità per ottenere il consenso del titolare alla condivisione dei dati e i requisiti per la conservazione dei dati mDL e delle chiavi private. La Parte 5 non è un prodotto wallet completo, non è un modello completo di consenso dell’utente, e non è un sistema di governance completo. È il livello di trasporto e verifica per la presentazione mobile.
Le linee guida di implementazione di AAMVA precisano ulteriormente questa distinzione tra due modelli di recupero:
- Recupero dal dispositivo, in cui i dati vengono letti direttamente dal dispositivo del titolare.
- Recupero dal server, che può consentire all’autorità emittente di osservare quando viene utilizzato l’mDL, quali dati vengono condivisi, e persino stimare la posizione fisica tramite analisi IP.
Questo secondo punto non è un motivo per rifiutare lo standard — è un motivo per essere precisi su quale modello di recupero un futuro IDP dovrebbe utilizzare per impostazione predefinita. AAMVA richiede inoltre che il wallet offra al titolare il pieno controllo su quali elementi di dati vengono condivisi, il che si adatta molto meglio a un futuro IDP rispetto al vecchio modello “mostra l’intero documento”.
Livello 3 — ISO/IEC 18013-7: Presentazione via Internet
La Parte 5 risolve il problema della presentazione di persona. La Parte 7 estende tale modello all’uso remoto.
L’ISO descrive 18013-7:2025 come un’estensione di 18013-5 per la presentazione via internet di un mDL a un lettore. Internet non è una considerazione secondaria in questa architettura; è una parte esplicita dello standard.
Il manuale europeo sulla patente di guida mobile tratta già la presentazione via internet come qualcosa di pratico piuttosto che teorico, descrivendo scenari quali:
- Check-in per il noleggio auto, in cui gli utenti condividono il proprio mDL di persona o da remoto in anticipo
- Controlli su strada da parte della polizia
- Un profilo di utilizzo generale dell’mDL basato su ISO/IEC 18013-5 e 18013-7
Detto questo, le attuali linee guida di AAMVA sono oneste riguardo ai limiti: l’uso dell’mDL via internet è altamente auspicabile, ma alcuni standard di supporto sono ancora in fase di maturazione. Esistono lacune reali nell’attuale integrazione wallet-browser, e senza un elenco di lettori affidabili, il lato mdoc potrebbe non avere un modo affidabile per confermare determinate proprietà di sicurezza. La presentazione remota è reale — e ancora in sviluppo.
Anche con queste riserve, 18013-7 è la prima risposta seria a un problema che l’IDP cartaceo non ha mai nemmeno tentato di risolvere: presentare le autorizzazioni di guida da remoto, prima che la persona raggiunga lo sportello o il posto di controllo.
Livello 4 — W3C VC Data Model 2.0: Il Livello Semantico
Il Verifiable Credentials Data Model 2.0 del W3C non è uno standard per patenti di guida — ed è precisamente per questo che è importante.
La Raccomandazione definisce un modello di dati estensibile per le credenziali verificabili, spiega come possono essere protette da modifiche, e descrive l’ecosistema in termini di tre ruoli fondamentali: emittenti, titolari e verificatori. La patente di guida compare come uno dei suoi esempi principali.
Per un futuro IDP, VC 2.0 contribuisce un vocabolario generale per attestazioni, presentazioni e registri di dati verificabili. Il W3C è esplicito nel dire che tali registri possono assumere diverse forme, tra cui:
- Database affidabili
- Database di identità governativi
- Database decentralizzati
- Registri distribuiti
Questo rompe la falsa dicotomia tra un approccio basato esclusivamente sulla blockchain e uno completamente proprietario. Il modello di dati è più ampio di entrambi.
VC 2.0 è anche chiaro riguardo alla divulgazione selettiva. Il W3C osserva che una patente di guida può contenere più dati di quanti siano necessari per un determinato caso d’uso, e raccomanda di suddividere le informazioni in parti più piccole oppure di utilizzare meccanismi che consentano la divulgazione selettiva. Per un futuro IDP, questa non è una comodità di privacy opzionale — è la differenza tra una credenziale moderna e una fotocopia digitale di una carta plastificata.
VC 2.0 non è tuttavia una sostituzione completa di ISO 18013. Il W3C sottolinea che il modello di dati non richiede un modello tradizionale di catena di fiducia basato su autorità di certificazione. In pratica, VC 2.0 è un solido livello semantico, ma livelli espliciti di distribuzione della fiducia e governance dei verificatori devono comunque essere posizionati sopra di esso.
Livello 5 — OpenID4VCI: Il Protocollo di Emissione
Un futuro IDP ha bisogno di un modo standard per trasferire una credenziale da un emittente a un wallet. Questo è il ruolo di OpenID for Verifiable Credential Issuance (OpenID4VCI) 1.0.
La specifica definisce un’API protetta da OAuth per l’emissione di credenziali verificabili, ed è intenzionalmente indipendente dal formato. Tra i formati di credenziali supportati:
- ISO mdoc
- SD-JWT VC
- Credenziali W3C VCDM
Supporta inoltre il binding del titolare e le presentazioni successive senza ulteriore coinvolgimento dell’emittente. OpenID4VCI 1.0 è stato approvato come Specifica Finale nel settembre 2025.
Questo rende OpenID4VCI strategicamente importante per un futuro ecosistema IDP. Invece di costruire pipeline su misura da emittente a wallet per ogni giurisdizione o fornitore di wallet, l’ecosistema può definire un profilo di emissione governato sopra un framework di emissione standard — scegliendo comunque se la credenziale risultante sia codificata come mdoc, VC o un altro formato supportato. Questa flessibilità è uno degli argomenti più forti a favore della modularità dello stack del futuro IDP.
Livello 6 — OpenID4VP: Il Protocollo di Richiesta e Presentazione
Se OpenID4VCI sposta la credenziale nel wallet, OpenID for Verifiable Presentations (OpenID4VP) la estrae in modo controllato.
La specifica definisce un meccanismo per richiedere e presentare credenziali. La sua implementazione di base utilizza messaggi e reindirizzamenti HTTPS, ma supporta anche l’uso tramite la W3C Digital Credentials API invece dei flussi di reindirizzamento. OpenID4VP 1.0 ha raggiunto lo status di Specifica Finale nel luglio 2025.
Questo è importante perché offre allo stack del futuro IDP un livello di presentazione nativo per il web che siti web, applicazioni e verificatori online possono implementare direttamente. Diversi sviluppi recenti lo confermano:
- Nell’agosto 2025, l’OpenID Foundation ha annunciato un’analisi formale della sicurezza di OpenID4VP utilizzato tramite la Digital Credentials API, senza che siano state riscontrate nuove vulnerabilità nel modello di protocollo verificato.
- L’attuale bozza NIST sull’mDL costruisce il proprio modello di minacce attorno alla richiesta e presentazione di mDL tramite OpenID4VP sulla W3C Digital Credentials API, con FIDO CTAP utilizzato per garantire la prossimità e resistere al phishing nei flussi pertinenti.
Il lato web dello stack e il lato mDL stanno convergendo. OpenID4VP non dovrebbe essere interpretato come un concorrente di ISO 18013-7 — è il livello di protocollo web che rende pratica la presentazione via internet in ambienti reali di browser, wallet e verificatori.
Livello 7 — Registri di Fiducia: Dove lo Stack Diventa un Ecosistema
Questo è il livello che molte discussioni saltano — e il livello che determina se l’intero sistema funziona davvero.
Un verificatore non può fare molto con una credenziale firmata a meno che non conosca tre cose:
- Quali emittenti sono legittimi
- Quali chiavi pubbliche sono attuali
- Se la parte richiedente è essa stessa autorizzata
Sul lato degli emittenti, il Digital Trust Service di AAMVA offre una risposta concreta. Fornisce un modo unico, sicuro e resiliente per le parti facenti affidamento di ottenere le chiavi pubbliche delle autorità emittenti, distribuite attraverso la Verified Issuer Certificate Authority List (VICAL). Le linee guida di AAMVA descrivono il ruolo del fornitore VICAL in termini pratici: raccogliere le chiavi pubbliche dalle autorità emittenti legittime, verificare che tali autorità gestiscano le proprie chiavi in modo sicuro, combinare le chiavi in un unico VICAL e consegnarle ai verificatori.
Sul lato dei verificatori, l’Europa affronta il problema della fiducia da un’altra direzione. Nell’Architettura e Framework di Riferimento EUDI, le parti facenti affidamento si registrano, ottengono certificati di accesso e li utilizzano per autenticarsi alle applicazioni wallet quando richiedono attributi. Il wallet verifica poi la catena di certificati, controlla lo stato di revoca, presenta la richiesta all’utente e rilascia solo gli attributi approvati.
Il modello VC del W3C contribuisce anche qui, trattando i registri di dati verificabili come un ruolo distinto dell’ecosistema. Come già detto, tali registri possono essere database affidabili, database di identità governativi, database decentralizzati o registri distribuiti. Un registro di fiducia per un futuro IDP non deve necessariamente essere costruito su blockchain. Deve essere governato, verificabile e leggibile da macchina.
Se ISO 18013 definisce come appare e viaggia la credenziale, i registri di fiducia decidono se chiunque debba crederci.
Come Funziona una Transazione del Futuro IDP dall’Inizio alla Fine
Ecco lo stack in funzione, suddiviso nei quattro momenti chiave del ciclo di vita di una credenziale.
1. Emissione. Un’autorità nazionale — o un emittente autorizzato e strettamente governato — verifica il record della patente sottostante ed emette una credenziale nel wallet del titolare. OpenID4VCI è il livello di emissione più pratico disponibile oggi, perché supporta già i formati ISO mdoc, SD-JWT VC e W3C VCDM. ISO 18013-5 stesso esclude dal proprio ambito la raccolta del consenso e la conservazione delle chiavi private, motivo per cui l’emissione e la governance del wallet devono operare al di sopra del livello di trasporto ISO di base.
2. Presentazione di persona. A un controllo su strada o a uno sportello di noleggio, il wallet presenta la credenziale utilizzando un flusso di prossimità basato su 18013-5. Il lettore convalida l’origine e l’integrità utilizzando le chiavi dell’emittente ottenute da un registro di fiducia — anziché prendere decisioni di fiducia in modo autonomo. Il titolare approva solo i campi necessari per quella specifica situazione.
3. Presentazione remota. Per controlli pre-noleggio o altri processi online, il verificatore richiede un insieme minimo di attributi tramite un flusso abilitato a internet usando 18013-7 e/o OpenID4VP. Il wallet mostra quali attributi vengono richiesti, il titolare approva e il verificatore riceve una presentazione strutturata invece di una scansione o un upload di PDF. L’attuale architettura NIST, costruita attorno a OpenID4VP più la Digital Credentials API, dimostra che questo è ora un percorso ingegneristico pratico.
4. Fiducia e autorizzazione del verificatore. Il wallet non si fida ciecamente di ogni richiedente. Un ecosistema maturo autentica la parte facente affidamento, convalida le catene di certificati, controlla lo stato di revoca e offre all’utente visibilità su chi sta richiedendo quali dati. Il modello EUDI è particolarmente solido su questo punto, trattando la registrazione del verificatore e i certificati di accesso come parti essenziali del sistema piuttosto che come componenti opzionali.
Questo flusso completo è esattamente il motivo per cui un futuro IDP deve essere uno stack. Nessun singolo livello può realizzarlo da solo. Non ISO da solo. Non VC da solo. Non OpenID da solo. E certamente non un PDF allegato a un modulo.
Cosa Manca Ancora nello Stack del Futuro IDP
Il problema più difficile che rimane non è più la creazione di nuova crittografia — è il raggiungimento di un’interoperabilità governata.
Si consideri la situazione attuale dell’ecosistema:
- Il NIST ha descritto il panorama attuale degli standard come in sviluppo in aree separate.
- AAMVA ha costruito un servizio di fiducia regionale per il Nord America.
- L’Europa sta integrando nella propria architettura wallet una fiducia delle parti facenti affidamento basata su certificati.
- OpenID ha finalizzato le specifiche di emissione e presentazione e sta ampliando l’infrastruttura di conformità.
Queste sono ancora risposte specifiche per singoli ecosistemi. Non esiste ancora un unico livello di fiducia transfrontaliera globale per le credenziali dei conducenti. Il lavoro rimanente consiste nel definire:
- Quali parti dello stack sono obbligatorie
- Quali formati di credenziali sono accettabili
- Come viene distribuita la fiducia tra emittenti e verificatori
- Come viene testata la conformità
- Come viene governato il riconoscimento transfrontaliero senza compromettere la privacy
Conclusione: Il Futuro IDP È uno Stack, Non un Documento
Un futuro IDP non apparirà perché un’organizzazione di standardizzazione scrive un unico documento. Emergerà quando uno stack coerente sarà definito, governato e adottato in tutte le giurisdizioni. Quello stack ha già livelli identificabili:
- ISO/IEC 18013-1 per la base del documento
- ISO/IEC 18013-3 per la sicurezza della credenziale
- ISO/IEC 18013-5 per la presentazione mobile di persona
- ISO/IEC 18013-7 per la presentazione remota
- W3C VC 2.0 per la semantica portabile
- OpenID4VCI per l’emissione
- OpenID4VP per la richiesta e la presentazione
- Registri di fiducia per la fiducia automatizzata e l’autorizzazione del verificatore
Questa è l’architettura alla base di un futuro IDP. Non un libretto. Non un’app. Uno stack.
Pubblicato Maggio 11, 2026 • 14m da leggere
