Polizia, Noleggio Auto, Datori di Lavoro, Assicuratori: Perché Non Devono Vedere gli Stessi Dati

Il più grande errore di progettazione in un futuro Permesso Internazionale di Guida (PIG) sarebbe trattare ogni verificatore allo stesso modo. Un agente di polizia, uno sportello di noleggio auto, un datore di lavoro e un assicuratore non pongono la stessa domanda — quindi non dovrebbero ricevere la stessa risposta.

Un solo guidatore. Un solo diritto fondamentale di guidare. Un solo portafoglio digitale. Ma quattro verificatori molto diversi tra loro:

• Un agente di polizia sul ciglio della strada
• Uno sportello di noleggio auto al momento del ritiro
• Un datore di lavoro che verifica l’idoneità alla guida di veicoli aziendali
• Un assicuratore che esamina un sinistro

Se il futuro PIG mostra gli stessi dati a tutti e quattro, il sistema ha già fallito. Non perché la credenziale sia insicura, ma perché il modello di divulgazione è troppo semplicistico.

La comunità degli standard si sta già allontanando da questo modello semplicistico. Il lavoro del W3C sulle credenziali verificabili descrive l’ecosistema di emittenti, titolari e verificatori, utilizzando datori di lavoro e siti web come esempi di verificatori. Il lavoro dell’UE sulla patente di guida mobile tratta già i controlli a bordo strada e i noleggi auto come scenari di verifica distinti, inclusa la condivisione anticipata da remoto per i noleggi e i controlli in presenza per la polizia. L’architettura è già progettata per gestire più tipi di verificatori. L’errore sarebbe progettare l’esperienza utente come se ne esistesse uno solo.

Perché la Tessera Fisica Ci Ha Insegnato a Ragionare in Modo Errato

Una patente fisica ci ha abituati a un approccio del tipo “mostra tutto”. Si consegna la tessera. L’altra persona vede ciò che è riportato sulla tessera. Questa è l’intera interazione.

Tale approccio è accettabile in un mondo cartaceo perché non esistono alternative. Diventa inaccettabile in un mondo digitale.

Il W3C VC Data Model 2.0 afferma esplicitamente: una patente di guida può contenere numero identificativo, altezza, peso, data di nascita e indirizzo di residenza — ma tutto ciò può comunque eccedere di gran lunga le informazioni necessarie per una determinata transazione. Punti chiave degli standard attuali:

• Buona prassi W3C: supportare la divulgazione selettiva e richiedere solo ciò che è strettamente necessario
• Linee guida UE sulla protezione dei dati: il trattamento deve essere limitato a finalità specificate, e i dati trattati devono essere necessari e proporzionati
• Il primo principio di un futuro PIG: stessa credenziale non significa stesso diritto di ispezione

Il Modello Corretto È la Divulgazione Basata su Policy

Se si desidera un’architettura seria, il modello corretto è più vicino al controllo degli accessi basato sugli attributi che alla presentazione di una tessera digitale.

Il NIST SP 800-205 definisce le decisioni di controllo degli accessi come valutazioni degli attributi associati al soggetto, all’oggetto, all’operazione richiesta e alle condizioni ambientali, rispetto a una policy. Questa è esattamente la struttura giusta per un futuro PIG:

• Soggetto: il guidatore
• Oggetto: i campi dati richiesti
• Azione: non “vedere la patente” in senso astratto, ma qualcosa di specifico come “verificare il diritto a guidare veicoli di categoria B a bordo strada” oppure “verificare l’idoneità al noleggio per una prenotazione”
• Contesto: bordo strada, sportello noleggio, pre-verifica da remoto, inserimento in flotta aziendale e revisione del sinistro post-perdita sono ambienti diversi e devono portare a decisioni diverse

Il NIST osserva inoltre che i sistemi basati sugli attributi necessitano di granularità, governance e meccanismi per la riduzione, il raggruppamento e la minimizzazione degli attributi.

Quindi il futuro PIG non dovrebbe chiedersi: Questo verificatore può leggere la patente? Dovrebbe chiedersi: Quali attestazioni può ricevere questo verificatore, per quale uso previsto, in quale contesto, con quali regole di conservazione?

Un Verificatore Deve Identificarsi Prima di Richiedere Qualsiasi Cosa

Il futuro PIG non dovrebbe iniziare con il portafoglio digitale che mostra i dati. Dovrebbe iniziare con il verificatore che dimostra la propria identità.

L’architettura EUDI è chiara in proposito. Le parti facenti affidamento devono:

• Registrare gli attributi che intendono richiedere e per quale finalità
• Ricevere certificati di accesso
• Autenticarsi presso il portafoglio digitale prima di qualsiasi divulgazione
• Essere verificate rispetto all’ambito registrato, laddove siano disponibili informazioni di registrazione

L’utente può quindi vedere chi sta chiedendo, cosa viene richiesto e se la richiesta rientra nell’ambito registrato.

Il lavoro attuale di ETSI sui certificati delle parti facenti affidamento sui portafogli rende tutto ciò più concreto. Un certificato di registrazione della parte facente affidamento sul portafoglio può descrivere l’uso previsto dalla parte stessa e gli attributi che ha registrato per richiedere. Il relativo certificato di accesso esiste per garantire che la richiesta provenga da una parte legittima e autorizzata. ETSI include anche i metadati della parte facente affidamento, come:

• Nome commerciale
• URI di supporto
• Uso previsto
• Diritti
• URI del registro
• Informazioni sull’autorità di vigilanza

Il secondo principio di un futuro PIG: nessuna identità del verificatore, nessuna divulgazione.

Perché le Schermate di Consenso Non Sono Sufficienti

C’è un altro errore: trattare l’approvazione dell’utente come se fosse equivalente alla legittimità giuridica.

L’architettura EUDI afferma esplicitamente che l’approvazione dell’utente a presentare attributi non deve essere considerata come base giuridica per il trattamento dei dati personali da parte della parte facente affidamento. Quest’ultima deve comunque disporre di una propria base giuridica legittima. EUDI richiede inoltre l’approvazione dell’utente in tutti i casi d’uso, compresi quelli in cui la parte facente affidamento potrebbe far parte delle forze dell’ordine o di un altro ente governativo.

Una buona interfaccia del portafoglio digitale può essere d’aiuto, ma da sola non può risolvere il problema del comportamento eccessivo del verificatore. La regola deve esistere prima dell’interfaccia.

Un futuro PIG necessita quindi di entrambi gli elementi:

• Autenticazione crittografica del verificatore per confermare chi sta facendo la richiesta
• Vincoli di policy su ciò che quella categoria di verificatore può richiedere

Senza entrambi, la “scelta dell’utente” diventa un modo per scaricare sull’individuo il fallimento delle policy.

1. Polizia: Verificare il Diritto alla Guida, Non l’Intera Identità

Lo scenario del controllo stradale da parte della polizia è il più focalizzato.

Il manuale UE sulla patente di guida mobile lo descrive direttamente: la polizia o altri funzionari verificano la patente quando richiesto, incluse la validità della patente e le abilitazioni al veicolo. Nel percorso utente, l’agente verifica la patente tramite un flusso attivato da QR code, Bluetooth, Wi-Fi Aware o NFC. Si tratta di un compito di verifica focalizzato:

• Questa persona è il titolare?
• La credenziale è valida?
• Quali abilitazioni e restrizioni veicolari si applicano?

Consentito per impostazione predefinita:

• Nome
• Foto
• Stato della patente
• Date di rilascio e scadenza
• Categorie
• Restrizioni rilevanti per la guida
• Emittente e giurisdizione
• Risultato di aggiornamento/stato

Non consentito per impostazione predefinita:

• Indirizzo di residenza
• Identificatori interni non necessari per l’uso a bordo strada
• Attributi non pertinenti provenienti da altre attestazioni
• Registri storici delle presentazioni
• Metadati commerciali

Le linee guida di implementazione dell’AAMVA rafforzano il punto relativo alla foto: se la foto viene richiesta e viene divulgato qualsiasi altro elemento, la foto dovrebbe essere condivisa affinché il verificatore possa collegare i dati alla persona che li presenta. Le stesse linee guida affermano che le parti interessate non devono tracciare i titolari di patente mobile o il relativo utilizzo, salvo ove richiesto dalla legge.

Il caso della polizia non riguarda lo Stato che riceve tutto. Riguarda lo Stato che riceve i dati specifici alla guida necessari per il controllo a bordo strada. Questa è una differenza importante.

2. Noleggio Auto: Idoneità, Corrispondenza d’Identità e Nulla di Superfluo

Il caso del noleggio è più articolato perché vi sono in realtà due momenti distinti: la pre-verifica da remoto prima dell’arrivo e il ritiro quando una persona o un chiosco consegna le chiavi.

Il manuale UE sulla patente di guida mobile modella già entrambi gli scenari. Un servizio di noleggio auto può richiedere la patente mobile insieme alla prova d’identità durante la prenotazione, convalidare le attestazioni e successivamente verificare il cliente di persona al momento del ritiro prima di consegnare il veicolo. Gli utenti possono condividere le proprie patenti mobili con le società di noleggio auto sia di persona che da remoto in anticipo.

Uno sportello di noleggio non ha principalmente bisogno di indagare su un incidente. Ha bisogno di decidere: Posso noleggiare questo veicolo a questo cliente nell’ambito di questa prenotazione e policy?

La pre-verifica da remoto dovrebbe includere:

• Collegamento d’identità
• Foto o elemento equivalente di associazione all’identità
• Categoria del veicolo pertinente
• Date di rilascio e scadenza
• Validità attuale
• Eventualmente una soglia d’età o una fascia d’età

Il ritiro dovrebbe confermare:

• Che il titolare è la stessa persona che ha completato la pre-verifica
• La validità attuale
• Le abilitazioni pertinenti

Non necessario per impostazione predefinita:

• Indirizzo completo di residenza quando un profilo di prenotazione contiene già i dati di contatto
• Data di nascita completa quando è sufficiente un’indicazione “maggiore di” o una fascia d’età
• Attributi d’identità non pertinenti
• Ripresentazione ripetuta della credenziale completa se esiste già un’attestazione di prenotazione

L’attuale architettura mDL del NIST mostra la parte facente affidamento che utilizza DCQL per richiedere solo gli attributi necessari, e afferma esplicitamente che ciò supporta la minimizzazione dei dati e il consenso del titolare strutturando la richiesta anziché trattare la credenziale come un’unità singola. AAMVA aggiunge che l’applicazione dovrebbe mostrare chiaramente quali dati sono stati richiesti e se il verificatore intende conservare le informazioni.

3. Datori di Lavoro: Una Categoria di Verificatori, Non un Accesso all’Identità Completa

La panoramica del W3C utilizza il sistema digitale di un datore di lavoro che verifica un titolo universitario come esempio di verificatore. Questo ci ricorda che la verifica da parte del datore di lavoro è già un modello riconosciuto negli ecosistemi di credenziali.

Un datore di lavoro o un operatore di flotta può legittimamente aver bisogno di sapere:

• Se un lavoratore ha attualmente il diritto di guidare determinate categorie di veicoli
• Se esistono restrizioni rilevanti
• Se l’abilitazione rimane valida

Si tratta di una reale esigenza aziendale. Tuttavia, ciò non giustifica automaticamente l’accesso permanente all’intera credenziale di guida, a tutti i dati d’identità, o a un flusso continuo di presentazioni ripetute.

Il NIST avverte che trasmettere frequentemente un identificatore riutilizzabile e abituare gli utenti a presentare ripetutamente una credenziale contenente dati d’identità è indesiderabile, e afferma che l’autenticazione quotidiana dovrebbe affidarsi a tecnologie progettate per l’autenticazione, come le passkey. Il NIST preferisce l’autenticazione biometrica locale sul dispositivo rispetto all’abbinamento biometrico lato server perché tutela meglio la privacy.

Un futuro PIG non dovrebbe diventare un badge di accesso sul luogo di lavoro.

Per l’utilizzo da parte di datori di lavoro e flotte aziendali, il modello corretto è di solito:

• Una verifica dell’abilitazione pertinente al lavoro
• Forse un’attestazione periodica di conformità
• Forse un’attestazione che il titolare rimane valido per le categorie specificate
• Ma non un trasferimento predefinito di tutti i dati della patente ogni volta che il dipendente accede a un sistema o inizia un turno

La conformità della flotta aziendale è una categoria separata di parte facente affidamento, con un uso previsto separato e un profilo di divulgazione separato.

4. Assicuratori: I Sinistri Non Sono un’Autorizzazione alla Visibilità Continua

Il caso assicurativo è spesso reale. Nel materiale sui casi d’uso della patente di guida mobile dell’UE, gli assicuratori compaiono indirettamente nello scenario del noleggio: le compagnie assicurative richiedono alle società di noleggio auto di verificare se la persona che noleggia il veicolo ha il diritto di guidare. L’assicurazione influenza già il flusso di verifica della guida.

Tuttavia, ciò non significa che un assicuratore debba ricevere gli stessi dati della polizia, né un diritto permanente di accesso alla credenziale.

Un futuro PIG dovrebbe trattare gli assicuratori come una categoria separata di verificatori con finalità d’uso distinte:

• Sottoscrizione
• Verifica del rischio di noleggio
• Gestione dei sinistri post-perdita
• Revisione delle frodi

Queste non sono la stessa finalità. In base ai principi europei di protezione dei dati, i dati personali devono essere raccolti per finalità specificate e limitati a ciò che è necessario e proporzionato rispetto a tale finalità. Le linee guida del W3C sulle credenziali verificabili giungono alla stessa conclusione sul piano tecnico: i verificatori dovrebbero richiedere solo ciò che è strettamente necessario.

Esempi legittimi e specifici all’evento:

• Prova che la patente era valida al momento rilevante
• Prova dell’abilitazione al veicolo pertinente
• Prova del collegamento d’identità ove necessario per un sinistro
• Divulgazione specifica al sinistro

Non consentito per impostazione predefinita:

• Accesso permanente alla credenziale sottostante
• Verifica generica ripetuta ogni volta che il cliente interagisce con l’assicuratore
• Utilizzo della credenziale di guida come token di accesso
• Raccolta di attributi non pertinenti

Una credenziale di guida non è un abbonamento di monitoraggio. E non dovrebbe diventarlo silenziosamente.

Perché gli Intermediari Devono Essere Visibili

I mercati reali prevedono intermediari. Le piattaforme di noleggio, i fornitori di flotte aziendali, i sistemi HR dei datori di lavoro e gli elaboratori di sinistri assicurativi agiscono spesso attraverso terze parti.

L’architettura EUDI gestisce questo aspetto:

• Trattando gli intermediari come parti facenti affidamento
• Richiedendo loro di registrarsi
• Richiedendo che gli attributi richiesti per la parte facente affidamento intermediata siano registrati
• Mostrando all’utente sia l’intermediario che la parte facente affidamento finale
• Vietando agli intermediari di conservare dati sul contenuto della transazione

Un futuro PIG non dovrebbe mai consentire uno scenario in cui l’utente crede di divulgare dati alla società di noleggio, mentre in realtà li sta divulgando a una catena invisibile composta da un broker di verifica, un processore di analisi e un fornitore di servizi sinistri.

ETSI è di aiuto in questo senso. Il suo modello di certificati per le parti facenti affidamento sui portafogli include URI di supporto, uso previsto, URI del registro e metadati dell’autorità di vigilanza. Questo è il tipo di infrastruttura leggibile dalle macchine necessaria affinché gli utenti possano comprendere chi si trova effettivamente dall’altra parte della richiesta e dove rivolgersi quando desiderano la cancellazione o la rettifica dei dati.

La Conservazione È Parte del Controllo degli Accessi

La maggior parte delle discussioni sulla divulgazione selettiva termina troppo presto. Si concentrano su cosa viene divulgato. Non si concentrano abbastanza su quanto a lungo tali dati rimangono disponibili in seguito.

Le linee guida attuali stanno già convergendo:

• AAMVA: il portafoglio deve indicare chiaramente al titolare quali dati sono stati richiesti e se il verificatore intende conservarli; le parti interessate non devono tracciare i titolari o l’utilizzo della patente mobile salvo ove richiesto dalla legge
• W3C: il software del titolare dovrebbe fornire registri delle informazioni condivise con i verificatori, affinché possano essere identificate richieste eccessive
• EUDI: gli utenti dovrebbero poter accedere ai registri delle transazioni, segnalare richieste sospette e richiedere la cancellazione dei dati

La classe di conservazione dovrebbe far parte della policy di divulgazione stessa:

• Controllo stradale della polizia: nessuna conservazione per impostazione predefinita oltre il registro operativo previsto dalla legge
• Pre-verifica noleggio: registro della transazione legato alla prenotazione, non una copia d’identità riutilizzabile
• Conformità flotta aziendale del datore di lavoro: registro di conformità o risultato dell’attestazione, non dati grezzi della credenziale
• Sinistro assicurativo: registro del sinistro limitato al sinistro stesso, non accesso permanente

Un futuro PIG che ignora la conservazione dei dati è solo parzialmente rispettoso della privacy.

Cosa Dovrebbe Effettivamente Decidere il Portafoglio Digitale

Se dovessi ridurre l’intero articolo a una sola regola di implementazione, sarebbe questa:

Il portafoglio digitale non dovrebbe rispondere a “Posso presentare questa credenziale?” Dovrebbe rispondere a “Posso presentare questo insieme di attestazioni a questo verificatore autenticato, per questo uso previsto, in questo contesto, in base a questa classe di conservazione?”

Tale decisione dovrebbe essere guidata almeno dai seguenti elementi:

• Identità del verificatore
• Categoria del verificatore
• Uso previsto
• Ambito degli attributi registrati
• Policy di divulgazione dell’emittente, se presente
• Contesto (bordo strada, ritiro, da remoto, flotta aziendale, sinistro)
• Approvazione del titolare
• Policy di conservazione applicabile

Gli standard contengono già gran parte degli strumenti necessari: divulgazione selettiva, autenticazione della parte facente affidamento, uso previsto registrato, certificati di accesso, valutazione della policy di divulgazione e richieste vincolate alla finalità. Ciò che manca ancora è la disciplina di trattare questi elementi come un’unica architettura di divulgazione coerente.

L’Argomento Centrale

Il futuro PIG non dovrebbe chiedersi se i dati possono essere divulgati. Dovrebbe chiedersi:

• Chi sta chiedendo?
• Per quale finalità?
• In base a quale autorità?
• In quale contesto?
• Con quali conseguenze in termini di conservazione?

Polizia, sportelli di noleggio, datori di lavoro e assicuratori non sono quattro loghi all’altra estremità di una richiesta. Sono quattro modelli di rischio diversi, quattro contesti giuridici diversi, quattro ragioni diverse per fare una richiesta — e dovrebbero produrre quattro insiemi di divulgazione diversi.

Questa non è una complessità inutile. È l’aspetto che assume una credenziale di guida moderna quando smette di trattare ogni verificatore come lo stesso verificatore.