L’error de disseny més gran en un futur Permís de Conducció Internacional (PCI) seria tractar tots els verificadors com si fossin el mateix. Un agent de policia, un mostrador de lloguer de vehicles, un empresari i una asseguradora no fan la mateixa pregunta — de manera que no haurien de rebre la mateixa resposta.
Un conductor. Un dret subjacent a conduir. Una cartera digital. Però quatre verificadors molt diferents:
- Un agent de policia a la via pública
- Un mostrador de lloguer de vehicles en el moment de recollida
- Un empresari que comprova l’elegibilitat per a la flota
- Una asseguradora que revisa una reclamació
Si el futur PCI mostra les mateixes dades als quatre, el sistema ja ha fracassat. No perquè la credencial sigui insegura, sinó perquè el model de divulgació és massa simple.
La comunitat d’estàndards ja s’està allunyant d’aquest model simplista. El treball del W3C sobre credencials verificables descriu l’ecosistema al voltant d’emissors, titulars i verificadors, utilitzant empresaris i llocs web com a exemples de verificadors. El treball de la UE sobre el permís de conducció mòbil ja tracta els controls a la via pública i els lloguers de vehicles com a escenaris de verificació separats, incloent-hi la compartició remota anticipada per als lloguers i els controls presencials per a la policia. L’arquitectura ja està dissenyada per a múltiples tipus de verificadors. L’error seria dissenyar l’experiència d’usuari com si només n’existís un.
Per Què la Targeta Física Ens Va Ensenyar a Pensar Incorrectament
Un permís físic ens va acostumar a un enfocament de mostrar-ho tot. Entregues la targeta. L’altra persona veu el que hi ha a la targeta. Aquesta és tota la interacció.
Aquest enfocament és acceptable en un món en paper perquè no hi ha alternativa. Es torna inacceptable en un món digital.
El W3C VC Data Model 2.0 afirma directament: un permís de conducció pot contenir número d’identificació, alçada, pes, data de naixement i adreça domiciliària — però tot plegat pot seguir sent molt més del necessari per a una transacció concreta. Punts clau dels estàndards actuals:
- Millor pràctica del W3C: donar suport a la divulgació selectiva i sol·licitar només el que és estrictament necessari
- Orientació de protecció de dades de la UE: el tractament ha d’estar limitat a finalitats especificades, i les dades tractades han de ser necessàries i proporcionals
- El primer principi d’un futur PCI: la mateixa credencial no implica el mateix dret d’inspecció
El Model Correcte és la Divulgació Basada en Polítiques
Si es vol una arquitectura seriosa, el model correcte s’assembla més al control d’accés basat en atributs que a la presentació d’una targeta digital.
El NIST SP 800-205 defineix les decisions de control d’accés com a avaluacions d’atributs associats al subjecte, l’objecte, l’operació sol·licitada i les condicions de l’entorn, en relació amb la política. Aquesta és exactament l’estructura correcta per a un futur PCI:
- Subjecte: el conductor
- Objecte: els camps de dades sol·licitats
- Acció: no “veure el permís” de manera abstracta, sinó alguna cosa concreta com ara “verificar el dret a conduir la categoria B a la via pública” o “verificar l’elegibilitat de lloguer per a una reserva”
- Entorn: la via pública, el mostrador de lloguer, la comprovació prèvia remota, l’incorporació a la flota i la revisió de sinistres posteriors a la pèrdua són entorns diferents i haurien de conduir a decisions diferents
El NIST també assenyala que els sistemes d’atributs necessiten granularitat, governança i mecanismes per a la reducció, agrupació i minimització d’atributs.
Per tant, el futur PCI no hauria de preguntar: Pot aquest verificador llegir el permís? Hauria de preguntar: Quines afirmacions pot rebre aquest verificador, per a quin ús previst, en aquest entorn, amb quines normes de retenció?
Un Verificador S’Ha d’Identificar Abans de Sol·licitar Res
El futur PCI no hauria de començar amb la cartera mostrant dades. Hauria de començar amb el verificador demostrant qui és.
L’arquitectura EUDI és clara en aquest punt. Les parts que confien han de:
- Registrar els atributs que pretenen sol·licitar i amb quina finalitat
- Rebre certificats d’accés
- Autenticar-se davant la cartera digital abans de qualsevol divulgació
- Ser verificades en relació amb el seu àmbit registrat, quan la informació de registre estigui disponible
L’usuari pot llavors veure qui demana, què s’està demanant i si la sol·licitud s’emmarca dins l’àmbit registrat.
El treball actual de l’ETSI sobre certificats de parts que confien en carteres digitals concreta això encara més. Un certificat de registre de part que confia en una cartera digital pot descriure l’ús previst de la part i els atributs que ha registrat per sol·licitar. El certificat d’accés relacionat existeix per garantir que la sol·licitud prové d’una part legítima i autoritzada. L’ETSI també inclou metadades de la part que confia, com ara:
- Nom comercial
- URI de suport
- Ús previst
- Drets
- URI de registre
- Informació de l’autoritat de supervisió
El segon principi d’un futur PCI: sense identitat del verificador, sense divulgació.
Per Què les Pantalles de Consentiment No Són Suficients
Hi ha un altre error aquí: tractar l’aprovació de l’usuari com si fos el mateix que la legitimitat legal.
L’arquitectura EUDI diu explícitament que l’aprovació de l’usuari per presentar atributs no s’ha de tractar com a base legal per al tractament de dades personals per part de la part que confia. La part que confia ha de tenir encara la seva pròpia base legal. EUDI també requereix l’aprovació de l’usuari en tots els casos d’ús, inclosos aquells en què la part que confia pugui ser part de les forces de l’ordre o d’una altra agència governamental.
Una bona interfície de cartera digital pot ajudar, però no pot resoldre per si sola els abusos del verificador. La norma ha d’existir abans que la interfície.
Un futur PCI necessita, per tant, les dues coses:
- Autenticació criptogràfica del verificador per confirmar qui demana
- Restriccions de política sobre el que aquella categoria de verificador pot sol·licitar
Sense les dues, “l’elecció de l’usuari” es converteix en una manera de traslladar el fracàs de la política a l’individu.
1. Policia: Verificar el Dret a Conduir, No Tota la Persona
L’escenari de control policial a la via pública és el més centrat.
El manual mDL de la UE ho descriu directament: la policia o altres funcionaris comproven el permís quan és necessari, incloent-hi la validesa del permís i els drets sobre el vehicle. En el recorregut de l’usuari, l’agent verifica el permís mitjançant un flux activat per codi QR, Bluetooth, Wi-Fi Aware o NFC. Aquesta és una tasca de verificació centrada:
- És aquesta persona la titular?
- És vàlida la credencial?
- Quins drets sobre el vehicle i restriccions s’apliquen?
Permès per defecte:
- Nom
- Fotografia
- Estat del permís
- Dates d’expedició i caducitat
- Categories
- Restriccions rellevants per a la conducció
- Emissor i jurisdicció
- Resultat d’actualitat/estat
No permès per defecte:
- Adreça domiciliària
- Identificadors interns no necessaris per a l’ús a la via pública
- Atributs no relacionats d’altres attestacions
- Registres històrics de presentació
- Metadades comercials
La guia d’implementació de l’AAMVA reforça el punt relatiu a la fotografia: si es sol·licita la fotografia i s’allibera qualsevol altre element, la fotografia s’ha de compartir perquè el verificador pugui vincular les dades a la persona que les presenta. La mateixa guia també diu que les parts interessades no han de fer un seguiment dels titulars de permisos mòbils ni del seu ús, excepte quan ho exigeixi la llei.
El cas de la policia no tracta que l’Estat ho rebi tot. Tracta que l’Estat rebi les dades específiques de conducció necessàries per a la vigilància a la via pública. Aquesta és una diferència important.
2. Mostradors de Lloguer: Elegibilitat, Verificació d’Identitat i Res Innecessari
El cas del lloguer és més detallat perquè hi ha realment dos moments: la comprovació prèvia remota abans de l’arribada i la recollida quan una persona o quiosc lliura les claus.
El manual mDL de la UE ja modela totes dues situacions. Un servei de lloguer de vehicles pot sol·licitar el permís mòbil juntament amb una prova d’identitat durant la reserva, validar les attestacions i posteriorment verificar el client en persona en el moment de la recollida abans de lliurar el vehicle. Els usuaris poden compartir els seus permisos mòbils amb empreses de lloguer de vehicles tant en persona com de manera remota per avançat.
Un mostrador de lloguer no necessita principalment investigar un incident. Necessita decidir: Puc llogar aquest vehicle a aquest client en el marc d’aquesta reserva i política?
La comprovació prèvia remota hauria d’incloure:
- Vincle d’identitat
- Fotografia o element equivalent de vinculació d’identitat
- Categoria de vehicle rellevant
- Dates d’expedició i caducitat
- Validesa actual
- Possiblement un llindar d’edat o franja d’edat
La recollida hauria de confirmar:
- Que el titular és la mateixa persona que va completar la comprovació prèvia
- La validesa actual
- Els drets rellevants
No necessari per defecte:
- Adreça domiciliària completa quan un perfil de reserva ja conté les dades de contacte
- Data de naixement completa quan un indicador de “major de” o franja d’edat és suficient
- Atributs d’identitat no relacionats
- Representació repetida de la credencial completa si ja existeix una attestació de reserva
L’arquitectura mDL actual del NIST mostra la part que confia usant DCQL per sol·licitar només els atributs necessaris, i diu explícitament que això dona suport a la minimització de dades i al consentiment del titular estructurant la sol·licitud en lloc de tractar la credencial com una unitat única. L’AAMVA afegeix que l’aplicació hauria de mostrar clarament quines dades es van sol·licitar i si el verificador té intenció de conservar la informació.
3. Empresaris: Una Categoria de Verificador, No una Porta d’Accés a la Identitat Completa
La visió general del W3C utilitza el sistema digital d’un empresari que comprova un títol universitari com a exemple de verificador. Això ens recorda que la verificació per part de l’empresari ja és un patró reconegut en els ecosistemes de credencials.
Un empresari o operador de flota pot legítimament necessitar saber:
- Si un treballador té dret en aquest moment a conduir determinades categories de vehicles
- Si existeixen restriccions clau
- Si el dret segueix sent vàlid
Aquesta és una necessitat empresarial real. Però no justifica automàticament l’accés permanent a tota la credencial de conducció, a totes les dades d’identitat o a un flux continu de presentacions repetides.
El NIST adverteix que transmetre freqüentment un identificador reutilitzable i condicionar els usuaris a presentar repetidament una credencial que conté dades d’identitat és indesitjable, i diu que l’autenticació diària hauria de basar-se en tecnologies dissenyades per a l’autenticació, com ara les claus de pas. El NIST prefereix l’autenticació local al dispositiu per sobre de la verificació biomètrica al servidor perquè preserva millor la privadesa.
Un futur PCI no s’hauria de convertir en una targeta d’accés al lloc de treball.
Per als casos d’ús d’empresaris i flotes, el patró correcte sol ser:
- Una comprovació del dret rellevant per al lloc de treball
- Potser una attestació periòdica de compliment
- Potser una afirmació que el titular segueix sent vàlid per a les categories especificades
- Però no una transferència per defecte de totes les dades del permís cada vegada que l’empleat inicia sessió en un sistema o comença un torn
El compliment de la flota és una categoria separada de part que confia, amb un ús previst separat i un perfil de divulgació separat.
4. Asseguradores: Les Reclamacions No Són un Permís per a la Visibilitat Contínua
El cas de les assegurances sovint és real. En el material de casos d’ús del mDL de la UE, les asseguradores apareixen indirectament en l’escenari de lloguer: les companyies d’assegurances exigeixen a les empreses de lloguer de vehicles que comprovin si la persona que lloga el cotxe té dret a conduir. Les assegurances ja influeixen en el flux de verificació de la conducció.
Però això no significa que una asseguradora hagi de rebre les mateixes dades que la policia, ni un dret permanent d’accés a la credencial.
Un futur PCI hauria de tractar les asseguradores com una categoria separada de verificadors amb usos previstos separats:
- Subscripció
- Verificació del risc de lloguer
- Gestió de reclamacions posteriors al sinistre
- Revisió per frau
Aquestes no són la mateixa finalitat. D’acord amb els principis de protecció de dades de la UE, les dades personals s’han de recollir per a finalitats especificades i limitar-se al que és necessari i proporcional per a aquella finalitat. L’orientació de credencials verificables del W3C arriba a la mateixa conclusió tècnicament: els verificadors haurien de sol·licitar només el que és estrictament necessari.
Exemples legítims i específics de cada event:
- Prova que el permís era vàlid en el moment rellevant
- Prova del dret sobre el vehicle rellevant
- Prova del vincle d’identitat quan sigui necessari per a una reclamació
- Divulgació específica per a la reclamació
No permès per defecte:
- Accés persistent a la credencial subjacent
- Verificació genèrica repetida cada vegada que el client interactua amb l’asseguradora
- Ús de la credencial de conducció com a testimoni d’inici de sessió
- Recollida d’atributs no relacionats
Una credencial de conducció no és una subscripció de monitoratge. I no hauria de convertir-s’hi silenciosament.
Per Què els Intermediaris Han de Ser Visibles
Els mercats reals impliquen intermediaris. Les plataformes de lloguer, els proveïdors de flotes, els sistemes de recursos humans dels empresaris i els processadors de reclamacions d’assegurances sovint actuen a través de tercers.
L’arquitectura EUDI gestiona això de la manera següent:
- Tractant els intermediaris com a parts que confien
- Exigint-los que es registrin
- Exigint que els atributs sol·licitats per a la part que confia intermediada estiguin registrats
- Mostrant tant l’intermediari com la part que confia final a l’usuari
- Prohibint als intermediaris emmagatzemar dades sobre el contingut de la transacció
Un futur PCI mai no hauria de permetre un patró on l’usuari creu que està divulgant a l’empresa de lloguer, però en realitat ho fa a una cadena invisible de corredor de verificació, processador d’analítica i proveïdor de reclamacions.
L’ETSI ajuda en aquest punt. El seu model de certificat de part que confia en una cartera digital inclou URI de suport, ús previst, URI de registre i metadades de l’autoritat de supervisió. Aquest és el tipus d’infraestructura llegible per màquines necessària perquè els usuaris entenguin qui hi ha realment a l’altre extrem de la sol·licitud i on dirigir-se quan volen la supressió o la correcció de les seves dades.
La Retenció És Part del Control d’Accés
La majoria de debats sobre la divulgació selectiva acaben massa aviat. Se centren en el que es divulga. No se centren prou en quant de temps roman posteriorment.
L’orientació actual ja convergeix:
- AAMVA: la cartera ha d’informar clarament el titular sobre quines dades es van sol·licitar i si el verificador té intenció de conservar-les; les parts interessades no han de fer un seguiment dels titulars ni de l’ús del permís mòbil, excepte quan ho exigeixi la llei
- W3C: el programari del titular hauria de proporcionar registres de la informació compartida amb els verificadors, de manera que es puguin identificar les sol·licituds excessives
- EUDI: els usuaris haurien de poder accedir als registres de transaccions, informar de sol·licituds sospitoses i sol·licitar la supressió de dades
La classe de retenció hauria de formar part de la pròpia política de divulgació:
- Control policial a la via pública: sense retenció per defecte més enllà del registre operatiu legal
- Comprovació prèvia de lloguer: registre de transacció vinculat a la reserva, no una còpia d’identitat reutilitzable
- Compliment de flota per a empresaris: registre de compliment o resultat d’attestació, no dades brutes de la credencial
- Reclamació d’assegurança: registre de reclamació limitat a la reclamació, sense accés permanent
Un futur PCI que ignori la retenció preserva la privadesa només parcialment.
El Que la Cartera Hauria de Decidir Realment
Si hagués de reduir tot aquest article a una sola regla d’implementació, seria aquesta:
La cartera no hauria de respondre “Puc presentar aquesta credencial?” Hauria de respondre “Puc presentar aquest conjunt d’afirmacions a aquest verificador autenticat, per a aquest ús previst, en aquest context, sota aquesta classe de retenció?”
Aquesta decisió hauria d’estar basada com a mínim en aquestes entrades:
- Identitat del verificador
- Categoria del verificador
- Ús previst
- Àmbit d’atributs registrats
- Política de divulgació de l’emissor, si n’hi ha
- Entorn (via pública, recollida, remot, flota, reclamació)
- Aprovació del titular
- Política de retenció aplicable
Els estàndards ja contenen gran part de la maquinària per a això: divulgació selectiva, autenticació de la part que confia, ús previst registrat, certificats d’accés, avaluació de la política de divulgació i sol·licituds vinculades a una finalitat. El que encara falta és la disciplina per tractar aquestes peces com una arquitectura de divulgació coherent.
L’Argument Central
El futur PCI no hauria de preguntar si les dades es poden divulgar. Hauria de preguntar:
- Qui demana?
- Per a quina finalitat?
- Sota quina autoritat?
- En quin context?
- Amb quines conseqüències de retenció?
La policia, els mostradors de lloguer, els empresaris i les asseguradores no són quatre logotips a l’altre extrem d’una sol·licitud. Són quatre models de risc diferents, quatre contextos legals diferents, quatre raons de preguntar diferents — i haurien de produir quatre conjunts de divulgació diferents.
Això no és complexitat innecessària. Això és com és una credencial de conducció moderna quan deixa de tractar tots els verificadors com si fossin el mateix.
Published April 27, 2026 • 15m to read
