Un futur Permís Internacional de Conducció (PIC) necessita transparència, ancoratges de confiança i responsabilitat pública. El que no necessita —per defecte— és posar els conductors mateixos en un registre distribuït.
Tota conversa seriosa sobre un PIC digital i transfronterer acaba atraient la mateixa proposta: “Simplement posa-ho a la cadena de blocs.” L’atractiu és comprensible. Les cadenes de blocs ofereixen evidència de manipulació, visibilitat compartida i un historial d’afegits exclusius. Aquestes són propietats reals. Però en el context de la identitat del conductor transfronterer, molt sovint s’apliquen a la capa equivocada.
Aquest article explica per què, repassa el que diuen realment els estàndards i presenta un patró arquitectònic millor.
El Que Diuen Realment els Estàndards Sobre la Cadena de Blocs
El Model de Dades de Credencials Verificables del W3C és explícit que un registre de dades verificables pot adoptar moltes formes, incloent-hi:
- Bases de dades de confiança
- Bases de dades descentralitzades
- Bases de dades d’identitat governamentals
- Registres distribuïts
El DID Core és igualment clar: molts mètodes DID utilitzen tecnologia de registre distribuït, però no tots ho fan. En altres paraules, els estàndards ja rebutgen la idea que la cadena de blocs sigui una base obligatòria per a les credencials digitals.
Aquest és el punt de partida correcte per a un futur PIC. La pregunta útil no és “cadena de blocs o no?” Sinó:
Quina capa necessita realment transparència, i quina capa no hauria de convertir-se de cap manera en infraestructura pública per defecte?
La Cadena de Blocs és un Conjunt de Propietats, No un Requisit
El primer error és tractar la “cadena de blocs” com un requisit únic. No ho és. És un conjunt de possibles propietats, que inclou:
- Publicació compartida
- Historial d’afegits exclusius
- Operació distribuïda
- Generació de rebuts
- Resistència als canvis unilaterals
Algunes d’aquestes propietats són útils per a un futur PIC. Altres són irrellevants. I algunes són activament perilloses quan s’apliquen a subjectes de credencials humans. El model de registre del W3C permet deliberadament múltiples implementacions perquè els diferents ecosistemes necessiten compromisos diferents.
Tres Problemes Que No S’han de Combinar
El segon error és fusionar tres problemes diferents en un sol sistema. Per a un futur PIC, cal mantenir-los separats:
- On resideix la veritat legal. El dret a conduir pertany als registres nacionals de llicències amb autoritat.
- Com es distribueix el material de confiança. Les claus dels emissors i els certificats dels verificadors pertanyen a registres de confiança controlats.
- Com l’ecosistema audita els canvis. Això pertany a una capa de transparència.
Els ecosistemes del món real ja funcionen d’aquesta manera. El Servei de Confiança Digital d’AAMVA distribueix les claus públiques dels emissors en una llista descarregable abans que un verificador interactuï amb un mDL. El manual europeu de permisos de conducció mòbils especifica que els Estats membres notifiquen a la Comissió els emissors de mDL autoritzats, i la Comissió publica una llista de verificació d’aquestes autoritats. Això és distribució de confiança sense cadena de blocs.
El Que Ens Ensenya la Transparència de Certificats
El model de transparència més eficaç a la xarxa pública no és una cadena de blocs de consum. És la Transparència de Certificats (CT).
L’RFC 9162 descriu la CT com un protocol per registrar públicament els certificats de servidor TLS perquè qualsevol persona pugui:
- Auditar l’activitat de les autoritats de certificació
- Detectar certificats problemàtics o emesos incorrectament
- Auditar els propis registres
La lliçó clau de disseny de la CT: la transparència és més valuosa quan registra el comportament dels emissors i el material de confiança — no l’activitat dels usuaris finals.
Aplicat a un futur PIC, això significa registrar coses com ara:
- Emissió i rotació de claus d’emissors
- Publicació d’ancoratges de confiança
- Registre de categories de verificadors
- Canvis de política
- Declaracions de conformitat
- Esdeveniments rellevants per a la seguretat
El que no significa és crear un registre públic o semipúblic de titulars, identificadors de credencials o esdeveniments de presentació. Això no és transparència. És una recollida excessiva de dades.
SCITT: Per Què la Transparència No és el Mateix que la Veritat
L’esborrany d’arquitectura SCITT de l’IETF amplia aquest pensament. SCITT defineix un Servei de Transparència que manté una estructura de dades verificable i emet rebuts criptogràfics que proven la inclusió de declaracions signades. La identitat del Servei de Transparència queda capturada per una clau pública coneguda per les parts que s’hi recolzen, i els ancoratges de confiança i les polítiques de registre es fan transparents ells mateixos.
Aquest és un model potent per a la infraestructura del PIC perquè converteix la transparència en un servei auditable al voltant del material de confiança i la política — no al voltant dels esdeveniments de viatge personals.
SCITT també és clar sobre els límits de la transparència:
- Una declaració registrada només prova que un emissor la va produir i registrar — no que la declaració sigui correcta indefinidament.
- Una declaració signada posterior pot substituir una anterior.
- La transparència no impedeix els emissors deshonestos o compromesos; els fa responsables.
Per a la identitat del conductor, aquesta distinció és enormement important: un registre de transparència és evidència i historial d’auditoria, no l’estat legal autoritzat del dret de conducció d’una persona.
SCITT també assenyala que un servei de transparència pot protegir la seva seqüència d’afegits exclusius mitjançant una combinació de maquinari de confiança, protocols de consens i evidència criptogràfica. Fins i tot la capa de transparència no requereix un disseny específic de cadena de blocs. El consens és una opció, no l’única.
La Separació Arquitectònica Correcta per a un Futur PIC
Un futur PIC hauria de separar les responsabilitats en quatre capes diferenciades:
- Registres autoritzats de qui pot conduir (autoritats nacionals de llicències)
- Registres de confiança per a les claus d’emissors i verificadors
- Infraestructura d’estat per a la frescor i la revocació
- Una capa de transparència opcional per a l’auditoria pública de polítiques, ancoratges de confiança, rebuts i declaracions de conformitat
Un cop separes aquestes capes, la pregunta sobre la cadena de blocs es torna molt més precisa. Ja no és “hauria el futur PIC d’estar en una cadena de blocs?” Sinó:
Quina capa, si n’hi ha alguna, es beneficia realment d’una auditoria pública d’afegits exclusius?
Cinc Raons per les Quals la Identitat del Conductor en Cadena és el Defecte Equivocat
1. Crea Senyals de Seguiment Duradors
El treball de privadesa de l’EUDI explica que les presentacions d’atestacions poden contenir valors únics com ara:
- Salts
- Valors de hash
- Identificadors de revocació
- Claus públiques de vinculació de dispositius
- Signatures
- Marques de temps
Com que aquests valors són fixos per a la mateixa atestació, permeten a les parts que s’hi recolzen vincular diferents transaccions i construir un perfil de comportament de l’usuari. L’EUDI adverteix explícitament que això viola l’expectativa raonable que les activitats separades de la cartera no es combinaran.
Si publiques identificadors estables de titulars, identificadors estables de credencials, hashes reutilitzables o esdeveniments de revocació individualment traçables en un registre públic, no estàs resolent el problema del seguiment — l’estàs fent permanent.
2. Exposa els Esdeveniments de Revocació i Frescor
La Recomanació de Llista d’Estat de Cadena de Bits del W3C descriu el problema amb claredat: si hi ha una correspondència u a u entre una credencial i l’URL on es publica el seu estat, el publicador pot connectar el titular, el verificador i el moment de la comprovació. L’especificació utilitza un exemple de permís de conducció per il·lustrar per què ser rastrejat per l’emissor en entrar a un establiment viola una expectativa de privadesa comuna.
El millor defecte que proposa la Llista d’Estat de Cadena de Bits:
- Llistes d’estat grans i comprimibles on moltes credencials comparteixen un recurs d’estat
- Una longitud de llista predeterminada de 131.072 entrades
- Les parts que s’hi recolzen descarreguen noves versions per separat, sense autenticar-se
- Índexs aleatoris i garanties de privadesa de grup
Això és el contrari de les traces de revocació individualitzades en cadena.
3. Confon l’Estat de la Credencial amb l’Estat Legal de Conducció
Una credencial digital pot ser revocada perquè el seu mecanisme de signatura va quedar compromès — fins i tot mentre el dret de conducció al món real continua sent vàlid. Un registre públic d’esdeveniments de credencials no és un substitut net de l’estat autoritzat d’un registre nacional de conducció.
SCITT reforça el punt: una declaració registrada pot ser substituïda posteriorment per una de nova, i les parts que s’hi recolzen decideixen en què confiar basant-se en la política i l’historial. El registre no és veritat permanent. És evidència sobre qui va dir què, quan, sota quina política. L’autoritat nacional de llicències continua sent l’arrel de la veritat legal.
4. Apunta al Problema de Governança Equivocat
La identitat del conductor transfronterer no és principalment un problema de consens. És un problema de governança:
- Qui té permès per emetre?
- Quines claus públiques estan vigents?
- Quins verificadors estan autoritzats?
- Quines sol·licituds de dades coincideixen amb el propòsit declarat?
- Quina versió de política estava en vigor en aquell moment?
Els ecosistemes reals ja responen a aquestes preguntes a través d’una infraestructura de confiança governada, no d’un consens descentralitzat:
- El Servei de Confiança Digital d’AAMVA publica les claus públiques de les autoritats emissores en una llista descarregable.
- El manual europeu de permisos de conducció mòbils indica que la Comissió publica la llista d’emissors de mDL autoritzats.
- El treball de certificats de parts de confiança de cartera d’ETSI proporciona autenticació de verificadors llegible per màquina amb l’ús previst i els atributs sol·licitats registrats.
Això és administració de confiança pública explícita — no governança descentralitzada.
5. No Resol la Realitat a la Vora de la Carretera
Moltes propostes de cadena de blocs assumeixen tàcitament que l’accés a la xarxa en viu és un avantatge. Per a les credencials de conductor — especialment a la vora de la carretera o durant el viatge — sovint no ho és.
La guia d’implementació d’AAMVA especifica que:
- La recuperació del dispositiu funciona sense connectivitat exterior tant per al titular com per al lector en el moment de la transacció.
- ISO/IEC 18013-5 requereix suport per a la recuperació del dispositiu.
- L’accés del verificador a les claus públiques de l’emissor no necessita produir-se en el moment de la transacció. Les claus es poden descarregar per endavant.
Si un verificador ja pot validar localment usant material de confiança en memòria cau, una dependència de cadena de blocs en viu no és essencial. En el millor dels casos, és una opció d’implementació per a alguna funció d’auditoria de backend.
Què Hauria de Ser Transparent en un Futur PIC
Un futur PIC necessita absolutament transparència — en el lloc correcte.
Fes transparents per defecte:
- Claus públiques dels emissors i esdeveniments de rotació de claus
- Ancoratges de confiança i llistes d’emissors autoritzats
- Certificats d’accés de verificadors i metadades de propòsit registrat
- Versions de política i normes de registre
- Declaracions de conformitat i reclamacions de llançament de programari rellevants per a la seguretat
- Rebuts auditables que proven que aquestes declaracions van ser registrades
No facis públics per defecte:
- Identificadors de titulars en un registre públic
- Identificadors estables de credencials reutilitzats entre verificadors
- Esdeveniments per presentació
- Entrades de revocació en brut que aïllen una persona
- Declaracions signades completes que contenen dades personals quan els hashes o les metadades serien suficients
SCITT adverteix explícitament als emissors que revisin la inclusió d’informació privada, confidencial o d’identificació personal abans d’enviar declaracions a un servei de transparència. També assenyala que els serveis de transparència poden retenir només metadades criptogràfiques com ara hashes — no declaracions signades completes.
Un Patró Millor: Transparència al Voltant de l’Ecosistema, No a Través de la Persona
Una arquitectura neta per a un futur PIC té aquest aspecte:
- Registre nacional autoritzat — continua sent la font legal de veritat per al dret a conduir.
- Capa de credencials — porta els drets de conducció verificables per màquina a la cartera del titular.
- Capa de registre de confiança — distribueix claus d’emissors, certificats de verificadors i llistes d’emissors autoritzats.
- Capa d’estat — utilitza atestacions de curta durada o llistes d’estat que preserven la privadesa actualitzades per separat.
- Capa de transparència — pot o no pot utilitzar consens internament, i registra ancoratges de confiança, canvis de claus, actualitzacions de política, rebuts i declaracions de l’ecosistema que es beneficien d’una auditoria pública d’afegits exclusius.
Aquesta arquitectura captura les parts útils del pensament de la cadena de blocs — auditabilitat d’afegits exclusius, escrutini públic, evidència de manipulació, rebuts — sense convertir el conductor en el subjecte públic del sistema. També coincideix amb el que els estàndards ja descriuen: els registres poden adoptar formes diferents, els DIDs no requereixen registres distribuïts, els registres de confiança ja existeixen i els mecanismes d’estat que preserven la privadesa ja estan estandarditzats.
L’Argument Central
El futur PIC hauria d’adoptar la millor idea de la cadena de blocs — responsabilitat pública per a la infraestructura — sense adoptar el seu pitjor defecte per a les persones: el seguiment durador i globalment visible.
En la pràctica, això significa:
- Transparència per als emissors, no exposició dels titulars
- Ancoratges de confiança auditables, no registres públics de viatge
- Rebuts per a polítiques i registres, no línies de temps permanents d’ús de credencials
- Evidència d’afegits exclusius per a la governança de l’ecosistema, no identitat del conductor en cadena com a defecte
Aquest no és un argument contra la cadena de blocs. És un argument contra l’aplicació de la cadena de blocs a la capa equivocada.
Un futur PIC pot perfectament utilitzar serveis de transparència amb suport de consens en algun lloc de l’ecosistema. Però si el disseny comença posant el conductor, la credencial o el rastre de presentació en un registre, ja ha triat el defecte equivocat.
Published May 18, 2026 • 12m to read
