Por qué blockchain es opcional para el futuro Permiso Internacional de Conducción (PIC)

Un futuro Permiso Internacional de Conducción (PIC) necesita transparencia, anclajes de confianza y rendición de cuentas pública. Lo que no necesita —por defecto— es colocar a los conductores en un registro distribuido.

Toda conversación seria sobre un PIC digital y transfronterizo acaba atrayendo la misma propuesta: “Ponlo en blockchain.” El atractivo es comprensible. Las blockchains ofrecen evidencia de manipulación, visibilidad compartida e historial de solo adición. Esas son propiedades reales. Pero en el contexto de la identidad del conductor en cruce de fronteras, muy a menudo se aplican a la capa equivocada.

Este artículo explica por qué, repasa lo que dicen realmente los estándares y presenta un mejor patrón arquitectónico.

Lo que dicen realmente los estándares sobre blockchain

El Modelo de Datos de Credenciales Verificables del W3C es explícito en que un registro de datos verificables puede adoptar muchas formas, entre ellas:

• Bases de datos de confianza
• Bases de datos descentralizadas
• Bases de datos de identidad gubernamentales
• Registros distribuidos

DID Core es igualmente claro: muchos métodos DID utilizan tecnología de registro distribuido, pero no todos. En otras palabras, los estándares ya rechazan la idea de que blockchain sea una base obligatoria para las credenciales digitales.

Ese es el punto de partida correcto para un futuro PIC. La pregunta útil no es “¿blockchain o no blockchain?” Sino:

¿Qué capa necesita realmente transparencia y cuál no debería convertirse en infraestructura pública por defecto?

Blockchain es un conjunto de propiedades, no un requisito

El primer error es tratar “blockchain” como un único requisito. No lo es. Es un conjunto de posibles propiedades, que incluyen:

• Publicación compartida
• Historial de solo adición
• Operación distribuida
• Generación de recibos
• Resistencia a cambios unilaterales

Algunas de estas propiedades son útiles para un futuro PIC. Otras son irrelevantes. Y algunas son directamente peligrosas cuando se aplican a personas como sujetos de credenciales. El modelo de registro del W3C permite deliberadamente múltiples implementaciones porque los distintos ecosistemas necesitan diferentes compromisos.

Tres problemas que no deben combinarse

El segundo error es fusionar tres problemas distintos en un solo sistema. Para un futuro PIC, estos deben mantenerse separados:

1. Dónde reside la verdad legal. El derecho a conducir pertenece a los registros nacionales autorizados de licencias.
2. Cómo se distribuye el material de confianza. Las claves de los emisores y los certificados de los verificadores pertenecen a registros de confianza controlados.
3. Cómo el ecosistema audita los cambios. Esto pertenece a una capa de transparencia.

Los ecosistemas del mundo real ya funcionan así. El Servicio de Confianza Digital de la AAMVA distribuye las claves públicas de los emisores en una lista descargable antes de que un verificador interactúe con un mDL. El manual de licencia de conducción móvil de la UE especifica que los Estados miembros notifican a la Comisión los emisores de mDL autorizados, y la Comisión publica una lista de verificación de dichas autoridades. Eso es distribución de confianza sin blockchain.

Lo que la Transparencia de Certificados nos enseña

El modelo de transparencia más eficaz en la internet pública no es una blockchain de consumo. Es la Transparencia de Certificados (CT).

El RFC 9162 describe la CT como un protocolo para registrar públicamente los certificados de servidor TLS, de modo que cualquiera pueda:

• Auditar la actividad de las autoridades de certificación
• Detectar certificados problemáticos o mal emitidos
• Auditar los propios registros

La lección de diseño clave de la CT: la transparencia es más valiosa cuando registra el comportamiento del emisor y el material de confianza, no la actividad del usuario final.

Aplicado a un futuro PIC, eso significa registrar cosas como:

• Emisión y rotación de claves del emisor
• Publicación de anclajes de confianza
• Registro de categorías de verificadores
• Cambios de política
• Declaraciones de conformidad
• Eventos relevantes para la seguridad

Lo que no significa es crear un registro público o semipúblico de titulares, identificadores de credenciales o eventos de presentación. Eso no es transparencia. Es recopilación excesiva de datos.

SCITT: por qué la transparencia no equivale a la verdad

El borrador de arquitectura SCITT del IETF amplía este razonamiento. SCITT define un Servicio de Transparencia que mantiene una estructura de datos verificable y emite recibos criptográficos que prueban la inclusión de declaraciones firmadas. La identidad del Servicio de Transparencia queda capturada en una clave pública conocida por las partes que confían en él, y los anclajes de confianza y las políticas de registro se hacen transparentes a su vez.

Este es un modelo potente para la infraestructura del PIC porque convierte la transparencia en un servicio auditable sobre el material de confianza y las políticas, no sobre eventos de viaje personales.

SCITT también es claro sobre los límites de la transparencia:

• Una declaración registrada solo prueba que un emisor la produjo y la registró, no que la declaración sea correcta indefinidamente.
• Una declaración firmada posterior puede reemplazar a una anterior.
• La transparencia no impide la existencia de emisores deshonestos o comprometidos; los hace responsables.

Para la identidad del conductor, esa distinción es enormemente importante: un registro de transparencia es evidencia e historial de auditoría, no el estado legal autorizado del derecho a conducir de alguien.

SCITT también señala que un servicio de transparencia puede proteger su secuencia de solo adición mediante una combinación de hardware de confianza, protocolos de consenso y evidencia criptográfica. Incluso la capa de transparencia no requiere un diseño blockchain específico. El consenso es una opción, no la única.

La separación arquitectónica correcta para un futuro PIC

Un futuro PIC debería separar las responsabilidades en cuatro capas diferenciadas:

1. Registros autorizados sobre quién puede conducir (autoridades nacionales de licencias)
2. Registros de confianza para claves de emisores y verificadores
3. Infraestructura de estado para la actualización y la revocación
4. Una capa de transparencia opcional para la auditoría pública de políticas, anclajes de confianza, recibos y declaraciones de conformidad

Una vez que se separan estas capas, la pregunta sobre blockchain se vuelve mucho más precisa. Ya no es “¿debería el futuro PIC estar en una blockchain?” Se convierte en:

¿Qué capa, si alguna, se beneficia realmente de una auditoría pública de solo adición?

Cinco razones por las que la identidad del conductor en cadena es el valor predeterminado equivocado

1. Crea señales de seguimiento duraderas

El trabajo sobre privacidad de la EUDI explica que las presentaciones de atestaciones pueden contener valores únicos como:

• Sales criptográficas
• Valores hash
• Identificadores de revocación
• Claves públicas vinculadas al dispositivo
• Firmas
• Marcas de tiempo

Dado que esos valores son fijos para una misma atestación, permiten a las partes que confían en ellos vincular distintas transacciones y construir un perfil de comportamiento del usuario. La EUDI advierte explícitamente que esto viola la expectativa razonable de que las actividades separadas de la cartera no serán combinadas.

Si publicas identificadores estables de titulares, identificadores estables de credenciales, hashes reutilizables o eventos de revocación individualmente rastreables en un registro público, no estás resolviendo el problema del seguimiento: lo estás haciendo permanente.

2. Expone los eventos de revocación y actualización

La Recomendación de Lista de Estado de Cadena de Bits del W3C describe el problema con claridad: si existe una correspondencia uno a uno entre una credencial y la URL donde se publica su estado, el publicador puede conectar al titular, al verificador y el momento de la consulta. La especificación utiliza un ejemplo de licencia de conducción para ilustrar por qué ser rastreado por el emisor al entrar en un establecimiento viola una expectativa común de privacidad.

El mejor valor predeterminado que propone la Lista de Estado de Cadena de Bits:

• Listas de estado grandes y comprimibles donde muchas credenciales comparten un único recurso de estado
• Una longitud de lista predeterminada de 131.072 entradas
• Las partes que confían descargan nuevas versiones por separado, sin necesidad de autenticarse
• Índices aleatorizados y garantías de privacidad de grupo

Eso es lo opuesto a los rastros de revocación individualizados en cadena.

3. Confunde el estado de la credencial con el estado legal de conducción

Una credencial digital puede ser revocada porque su mecanismo de firma fue comprometido, incluso mientras el derecho real a conducir sigue siendo válido. Un registro público de eventos de credenciales no es un sustituto limpio del estado autorizado de un registro nacional de conducción.

SCITT refuerza este punto: una declaración registrada puede ser reemplazada posteriormente por una nueva, y las partes que confían deciden en qué confiar basándose en la política y el historial. El registro no es la verdad permanente. Es evidencia sobre quién dijo qué, cuándo y bajo qué política. La autoridad nacional de licencias sigue siendo la raíz de la verdad legal.

4. Apunta al problema de gobernanza equivocado

La identidad del conductor transfronterizo no es principalmente un problema de consenso. Es un problema de gobernanza:

• ¿Quién está autorizado a emitir?
• ¿Qué claves públicas están vigentes?
• ¿Qué verificadores están autorizados?
• ¿Qué solicitudes de datos corresponden a su finalidad declarada?
• ¿Qué versión de la política estaba en vigor en ese momento?

Los ecosistemas reales ya responden a estas preguntas a través de una infraestructura de confianza gobernada, no mediante consenso descentralizado:

• El Servicio de Confianza Digital de la AAMVA publica las claves públicas de las autoridades emisoras en una lista descargable.
• El manual de licencia de conducción móvil de la UE establece que la Comisión publica la lista de emisores de mDL autorizados.
• El trabajo de la ETSI sobre certificados de partes que confían en carteras proporciona autenticación de verificadores legible por máquina con uso previsto y atributos solicitados registrados.

Eso es administración explícita de confianza pública, no gobernanza descentralizada.

5. No resuelve la realidad en la vía pública

Muchas propuestas de blockchain asumen implícitamente que el acceso a la red en tiempo real es una ventaja. Para las credenciales de conductor —especialmente en la vía pública o durante un viaje— a menudo no lo es.

La guía de implementación de la AAMVA especifica que:

• La recuperación desde el dispositivo funciona sin conectividad exterior, tanto para el titular como para el lector en el momento de la transacción.
• La norma ISO/IEC 18013-5 exige compatibilidad con la recuperación desde el dispositivo.
• El acceso del verificador a las claves públicas del emisor no necesita producirse en el momento de la transacción. Las claves pueden descargarse con antelación.

Si un verificador ya puede validar localmente usando material de confianza en caché, una dependencia de blockchain en tiempo real no es esencial. En el mejor de los casos, es una opción de implementación para alguna función de auditoría en el backend.

Qué debe ser transparente en un futuro PIC

Un futuro PIC sí necesita transparencia, pero en el lugar correcto.

Hacer transparente por defecto:

• Claves públicas de emisores y eventos de rotación de claves
• Anclajes de confianza y listas de emisores autorizados
• Certificados de acceso de verificadores y metadatos de finalidad registrada
• Versiones de políticas y reglas de registro
• Declaraciones de conformidad y afirmaciones de versiones de software relevantes para la seguridad
• Recibos auditables que acrediten el registro de dichas declaraciones

No hacer público por defecto:

• Identificadores de titulares en un registro público
• Identificadores de credenciales estables reutilizados entre verificadores
• Eventos por presentación
• Entradas de revocación individuales que aíslan a una persona
• Declaraciones firmadas completas que contienen datos personales cuando bastarían hashes o metadatos

SCITT advierte explícitamente a los emisores que revisen la inclusión de información privada, confidencial o de identificación personal antes de enviar declaraciones a un servicio de transparencia. También señala que los servicios de transparencia pueden conservar únicamente metadatos criptográficos como hashes, y no declaraciones firmadas completas.

Un mejor patrón: transparencia alrededor del ecosistema, no a través de la persona

Una arquitectura limpia para un futuro PIC tiene este aspecto:

• Registro nacional autorizado — sigue siendo la fuente legal de verdad sobre el derecho a conducir.
• Capa de credenciales — traslada los derechos de conducción verificables por máquina a la cartera digital del titular.
• Capa de registro de confianza — distribuye claves de emisores, certificados de verificadores y listas de emisores autorizados.
• Capa de estado — utiliza atestaciones de corta duración o listas de estado que preservan la privacidad, actualizadas de forma independiente.
• Capa de transparencia — puede o no usar consenso internamente, y registra anclajes de confianza, cambios de claves, actualizaciones de políticas, recibos y declaraciones del ecosistema que se benefician de una auditoría pública de solo adición.

Esta arquitectura captura las partes útiles del pensamiento blockchain —auditabilidad de solo adición, escrutinio público, evidencia de manipulación, recibos— sin convertir al conductor en el sujeto público del sistema. También se corresponde con lo que los estándares ya describen: los registros pueden adoptar distintas formas, los DIDs no requieren registros distribuidos, los registros de confianza ya existen y los mecanismos de estado que preservan la privacidad ya están normalizados.

El argumento central

El futuro PIC debería adoptar la mejor idea de blockchain —responsabilidad pública sobre la infraestructura— sin adoptar su peor valor predeterminado para las personas: el seguimiento duradero y globalmente visible.

En la práctica, eso significa:

• Transparencia para los emisores, no exposición de los titulares
• Anclajes de confianza auditables, no registros públicos de viajes
• Recibos de políticas y registros, no líneas de tiempo permanentes de uso de credenciales
• Evidencia de solo adición para la gobernanza del ecosistema, no identidad del conductor en cadena como valor predeterminado

Este no es un argumento en contra de blockchain. Es un argumento en contra de aplicar blockchain a la capa equivocada.

Un futuro PIC bien puede utilizar servicios de transparencia respaldados por consenso en algún punto del ecosistema. Pero si el diseño comienza colocando al conductor, la credencial o el rastro de presentación en un registro, ya ha elegido el valor predeterminado equivocado.