La revocación es el problema más difícil en cualquier futuro Permiso Internacional de Conducción (PIC) digital. La forma más sencilla de resolverlo es también la más peligrosa: convertir al emisor en participante en cada presentación. Una credencial de conducción transfronteriza moderna debe rechazar este atajo por defecto.
Casi todas las propuestas de identidad digital contienen la misma frase tranquilizadora:
“La credencial puede verificarse al instante.”
A veces esa frase describe un progreso genuino. A veces describe vigilancia con una interfaz de usuario más amigable.
Los estándares publicados hoy ya dejan claro que un verificador no necesita contactar al emisor cada vez que se presenta una credencial:
- La arquitectura mDL actual del NIST establece que un verificador puede validar la autenticidad e integridad confiando en la firma y las claves públicas del emisor, sin ningún contacto directo con este.
- AAMVA confirma que ISO/IEC 18013-5 requiere compatibilidad con la recuperación por dispositivo y solo opcionalmente permite la recuperación por servidor.
- AAMVA también advierte que con la recuperación por servidor, la autoridad emisora participa en tiempo real en cada uso, lo que significa que técnicamente puede registrar cuándo se usa la credencial, qué datos se comparten e incluso inferir la ubicación mediante análisis de IP.
Eso no es una nota al pie menor. Es la pregunta central de diseño para la próxima generación de credenciales de conducción transfronterizas.
El Atajo Peligroso: Agrupar Cuatro Preguntas en una Sola Llamada de Red
Las arquitecturas deficientes agrupan cuatro preguntas muy distintas en una única llamada en vivo al emisor:
- ¿Es esta credencial auténtica?
- ¿Es la persona que la presenta el titular legítimo?
- ¿Sigue siendo válida la propia credencial?
- ¿Sigue vigente el derecho nacional de conducción subyacente?
Un sistema mal diseñado responde las cuatro llamando al servidor en tiempo real. Un sistema bien diseñado las separa, porque no son el mismo problema y no deben compartir un mecanismo.
La Autenticidad Debe Verificarse Localmente, No a Través de la Red
Una credencial puede ser criptográficamente genuina sin que el emisor observe jamás la transacción.
- El modelo de confianza mDL del NIST establece que la autenticidad e integridad se validan a partir de la firma y las claves públicas del emisor; no se requiere contacto en vivo con este.
- El Servicio de Confianza Digital de AAMVA existe precisamente para dar a los verificadores acceso a claves públicas válidas del emisor sin devoluciones de llamada por transacción.
Principio de Diseño 1: No utilices conectividad en vivo para resolver un problema que las firmas ya resuelven.
Si un verificador posee claves de emisor de confianza y recibe una presentación conforme a los estándares, la autenticidad es una verificación criptográfica local, no una dependencia de red.
La Vinculación del Titular Debe Probarse Localmente, No Reportarse Globalmente
La segunda pregunta — ¿es este el titular legítimo? — también tiene una respuesta que no requiere red.
La arquitectura EUDI actual exige la vinculación al dispositivo para los PID y las atestaciones ISO/IEC 18013-5. El verificador pide a la billetera que firme un desafío nuevo usando la clave privada que corresponde a la clave pública incorporada en la credencial:
- En ISO/IEC 18013-5 esto se denomina autenticación mdoc.
- En SD-JWT VC se denomina vinculación de clave.
En ambos casos, la posesión se prueba de forma local y criptográfica. Ningún dato personal necesita llegar jamás al emisor.
Principio de Diseño 2: Prueba la posesión localmente. No pruebes la identidad globalmente.
Un futuro PIC debe agotar la vinculación al dispositivo, la autenticación local del titular y el desafío-respuesta del verificador antes de considerar cualquier mecanismo del lado del emisor.
El Estado de la Credencial y el Estado del Derecho de Conducción Son Dos Cosas Distintas
Muchos diseños de identidad digital confunden esta distinción, y ahí es donde fallan.
La especificación Bitstring Status List del W3C lo deja claro: la información de estado adjunta a una credencial verificable se aplica a la credencial verificable en sí, no necesariamente al derecho real subyacente. Una credencial digital podría revocarse porque su mecanismo de firma fue comprometido, mientras que el derecho de conducción subyacente permanece completamente válido.
Un futuro PIC necesita por tanto dos capas de estado distintas:
- Capa de estado de la credencial — para la credencial digital o el canal de presentación en sí.
- Capa del derecho de conducción — para el derecho nacional subyacente a conducir.
A veces estos cambian juntos. Con frecuencia, no. Un sistema que los confunde reaccionará en exceso, expondrá más datos de los necesarios, o ambas cosas.
El Compromiso de la Billetera Debe Propagarse a Través del Estado, No Activar Devoluciones de Llamada al Verificador
Un futuro PIC también necesita una respuesta clara sobre qué ocurre cuando una billetera es comprometida.
La arquitectura EUDI ofrece una:
- El proveedor de la billetera emite Atestaciones de Unidad de Billetera que contienen información de revocación.
- La integridad de la billetera se reverifica periódicamente; si una billetera ya no es segura, su atestación se revoca.
- Los proveedores de PID deben comprobar regularmente si la billetera ha sido revocada. Si lo ha sido, revocan el PID.
- Al verificar el estado del PID, la parte dependiente verifica implícitamente el estado de la billetera.
Esta es la estructura en capas que debe adoptar un futuro PIC. No pidas a cada verificador que compruebe independientemente al proveedor de la billetera. Deja que el compromiso de la billetera se propague a través del proceso existente de estado de credenciales, y permite que los verificadores consulten ese único canal que preserva la privacidad.
Tres Patrones de Revocación Viables (Sin Devoluciones de Llamada)
EUDI exige que los proveedores utilicen uno de tres métodos de revocación:
- Atestaciones de corta duración — válidas durante 24 horas o menos, por lo que la revocación se vuelve innecesaria.
- Lista de Estado de Atestación — una lista publicada que los verificadores pueden consultar.
- Lista de Revocación de Atestación — una lista explícita de credenciales revocadas.
Para atestaciones válidas por más de 24 horas, EUDI exige incorporar información de revocación que incluya:
- Una URL desde donde las partes dependientes puedan obtener la lista de estado.
- Un identificador que localice la credencial dentro de esa lista.
Si la información de revocación fiable no está disponible — por ejemplo, cuando la parte dependiente está sin conexión — EUDI indica a la parte dependiente que realice un análisis de riesgo antes de aceptar o rechazar la credencial.
La conclusión: la revocación no es un mecanismo único, y ciertamente no es una justificación para las devoluciones de llamada obligatorias al emisor.
Corta Duración por Defecto, Larga Duración Solo Cuando Sea Necesario
Una de las medidas de privacidad más eficaces de toda la arquitectura es también la más sencilla: mantener lo que se presenta con una vida útil corta.
- EUDI establece que las atestaciones válidas durante 24 horas o menos no requieren infraestructura de revocación, ya que expiran antes de que la revocación sea relevante.
- W3C establece que las presentaciones verificables suelen ser de corta duración y no están diseñadas para almacenamiento a largo plazo.
- NIST advierte explícitamente contra la transmisión repetida de identificadores reutilizables para el uso cotidiano. La autenticación diaria debe basarse en tecnologías diseñadas para ese propósito, como las claves de acceso, no en la presentación repetida de una credencial rica en identidad.
- NIST también eligió la autenticación local por dispositivo frente a la biometría del lado del servidor precisamente porque la autenticación local preserva la privacidad y es operativamente más eficiente.
Principio de Diseño 3: La credencial base puede tener un período de validez medio, pero la presentación en sí debe ser de corta duración, específica para el verificador y no reutilizable.
Las Listas de Estado Son el Mecanismo Predeterminado Correcto
Cuando no se puede hacer todo de corta duración, se necesita infraestructura de estado, y la lista de estado es la opción predeterminada correcta.
La Bitstring Status List v1.0 del W3C describe un mecanismo eficiente en espacio, de alto rendimiento y que preserva la privacidad para publicar datos de estado como suspensión o revocación. Sus propiedades clave incluyen:
- Cada emisor gestiona una lista para las credenciales que ha emitido.
- El formato se comprime bien, ya que la mayoría de las credenciales permanecen sin revocar.
- El tamaño predeterminado de la lista es de 131.072 entradas, lo que según el W3C proporciona privacidad de grupo adecuada en el caso promedio.
- Se pueden usar listas más grandes donde se necesite mayor privacidad de grupo.
Esto desplaza la pregunta de:
“¿Puedo preguntar al emisor sobre este usuario ahora mismo?”
a:
“¿Ya tengo una lista de estado suficientemente reciente que preserve la privacidad para decidir localmente?”
Esa es una pregunta mucho mejor, tanto técnica como políticamente.
“Sin Llamada al Servidor” Es un Patrón de Descarga, No un Eslogan
La regla más importante en la guía de privacidad de EUDI es procedimental, no filosófica.
Las partes dependientes no deben solicitar la lista de estado cada vez que se presenta una credencial. En cambio, deben:
- Descargar cada nueva versión de la lista una sola vez.
- Hacerlo en un momento y desde una ubicación sin relación con ninguna presentación de usuario.
- Distribuir la lista internamente dentro de la organización de la parte dependiente.
- Obtener la lista sin autenticar a la parte dependiente.
Ese es el núcleo operativo de la verificación sin llamada al servidor: actualizar el estado de forma separada a las presentaciones de usuario, nunca por persona, nunca por transacción.
Esta única decisión de diseño impide que el emisor o el proveedor de estado sepa qué verificador comprobó qué credencial en qué momento.
Privacidad de Grupo: El Requisito que la Mayoría de los Diseños Olvida
Muchos sistemas proclaman la divulgación selectiva dentro de la propia presentación, para luego ignorar silenciosamente la privacidad de las consultas de estado. Esa es una brecha significativa.
Los requisitos de privacidad de EUDI especifican que:
- Los índices en las listas de estado deben asignarse de forma aleatoria, para que el propio índice nunca se convierta en una señal de seguimiento.
- Cada lista debe cubrir un número suficientemente grande de credenciales para garantizar la privacidad de grupo.
- Si una lista fuera de otro modo demasiado pequeña, los proveedores deben añadir entradas no utilizadas para ocultar el recuento real de credenciales.
Un futuro PIC no puede declararse que preserva la privacidad únicamente sobre la base de la divulgación selectiva. Si el mecanismo de revocación filtra el evento de presentación, el diseño de privacidad está incompleto.
El Funcionamiento Sin Conexión No Es un Caso Extremo — Es un Requisito Fundamental
Cualquier sistema de viaje que asuma una conectividad perfecta está mal diseñado.
- AAMVA confirma que la recuperación por dispositivo funciona sin conectividad exterior tanto para el dispositivo del titular como para el lector, y que ISO/IEC 18013-5 exige que los mDL admitan la recuperación por dispositivo.
- EUDI acepta que las partes dependientes pueden estar sin conexión y carecer de una lista de estado en caché, en cuyo caso recomienda un análisis de riesgo antes de decidir.
Acepta este compromiso desde el principio:
No puedes tener un funcionamiento sin conexión perfecto y una actualización en tiempo real perfecta al mismo tiempo.
Cualquier arquitectura que prometa ambas cosas sin compromiso es imprecisa o está reintroduciendo silenciosamente la vigilancia. La respuesta correcta es convertir la actualización en una entrada de política, no en una dependencia de red universal.
Los Registros Son Donde la Privacidad Falla Silenciosamente
Incluso una excelente arquitectura de estado puede quedar arruinada por un registro descuidado.
- EUDI exige que las instancias de partes dependientes descarten los elementos únicos y las marcas de tiempo tan pronto como ya no sean necesarios, y prohíbe su reenvío.
- AAMVA prohíbe a las partes interesadas rastrear a los titulares de mDL o el uso de mDL salvo cuando lo exija la ley, exige que las autoridades emisoras minimicen el intercambio de metadatos estáticos o de larga duración, y restringe el acceso al registro de actividad únicamente al titular.
- AAMVA también exige que la eliminación en el dispositivo suprima la información de registro y los metadatos que podrían revelar el historial de uso, y que dicha eliminación sea posible sin conexión.
Esto es comportamiento de protocolo, no mantenimiento administrativo. Un futuro PIC debe tratar los identificadores de larga duración, las marcas de tiempo y los registros como posibles herramientas de seguimiento, salvo que se demuestre explícitamente lo contrario.
Una Arquitectura Concreta Sin Llamada al Servidor para el Futuro PIC
Reuniendo todos los principios, esto es lo que el sistema debe hacer en la práctica:
- Emitir una credencial base vinculada al dispositivo. Vincular la credencial a claves protegidas en el entorno seguro de la billetera, obligatorio en EUDI para PID y atestaciones ISO/IEC 18013-5.
- Solicitar solo lo necesario, con un desafío nuevo. En una transacción OpenID4VP, una consulta DCQL permite a la billetera mostrar al titular qué atributos se están solicitando, y el verificador emite un desafío para prevenir la repetición (según la arquitectura mDL actual del NIST).
- Generar una presentación de corta duración, no un identificador reutilizable. Cada presentación debe ser específica para el verificador, la solicitud y el momento.
- Verificar la autenticidad localmente. Validar las firmas del emisor y las claves públicas sin conexión; el servicio de confianza de AAMVA está construido exactamente para esto.
- Comprobar el estado desde listas en caché, actualizadas por separado. Donde las credenciales sean demasiado longevas para omitir la revocación, usar listas de estado en caché local actualizadas según un calendario sin relación con las presentaciones de usuario.
- Aplicar una política de riesgo cuando la actualización no esté disponible. Hacer que las decisiones sin conexión sean política explícita del verificador, no especulación desestructurada.
- Eliminar los datos de seguimiento de forma agresiva. Descartar los elementos únicos de transacción y las marcas de tiempo cuando ya no sean necesarios; no conservar registros que puedan reconstruir el historial de movimientos.
Así es como luce una arquitectura seria sin llamada al servidor: en capas, que preserva la privacidad, criptográficamente local y operativamente honesta sobre la realidad sin conexión.
Tres Patrones que Deben Estar Prohibidos por Diseño
Un ecosistema maduro de PIC futuro debe tratar estos como fallos arquitectónicos, no como opciones de optimización:
- Devoluciones de llamada obligatorias al emisor en cada presentación. La propia guía de privacidad de AAMVA explica por qué esto es perjudicial.
- Usar la credencial de conducción como inicio de sesión rutinario. NIST advierte explícitamente contra la presentación repetida de credenciales que contienen identidad para la autenticación diaria.
- Conservar identificadores, marcas de tiempo y registros que puedan reconstruir el historial de presentaciones. Tanto EUDI como AAMVA exigen lo contrario.
El Argumento Central en Una Sola Frase
La verificación instantánea no debe convertirse en permiso para la vigilancia del lado del emisor.
Un futuro PIC debe ser capaz de:
- Probar la autenticidad localmente.
- Probar la posesión localmente.
- Verificar la actualización de forma privada.
- Tolerar la realidad sin conexión.
- Funcionar con elegancia cuando la información perfecta no está disponible.
Nada de esto hace al sistema más débil. Lo hace digno de implantarse a gran escala.
En el momento en que una credencial de conducción se convierte en una herramienta para registrar quién mostró qué, dónde y cuándo, deja de ser una versión más segura del papel. Se convierte en infraestructura de observación.
Eso es exactamente en lo que el futuro PIC debe negarse a convertirse.
Preguntas Frecuentes
¿Qué es la “verificación de llamada al servidor”?
Es cualquier diseño en el que un verificador contacta al emisor en tiempo real para validar una credencial. Aunque resuelve simultáneamente la autenticidad y la revocación, también permite al emisor observar cada evento de presentación.
¿Requiere ISO/IEC 18013-5 contacto en línea con el emisor?
No. AAMVA confirma que ISO/IEC 18013-5 exige compatibilidad con la recuperación por dispositivo y solo permite opcionalmente la recuperación por servidor.
¿Cómo puede funcionar la revocación sin contactar al emisor?
Mediante credenciales de corta duración, listas de estado de atestación o listas de revocación de atestación, idealmente con la parte dependiente descargando los datos de estado de forma separada a las presentaciones de usuario.
¿Por qué es importante la “privacidad de grupo” para las listas de estado?
Si una lista de estado es demasiado pequeña o sus índices son predecibles, una solicitud de estado puede revelar qué credencial específica se acaba de presentar. Los índices aleatorios y las listas grandes lo impiden.
¿Es realmente práctico el funcionamiento sin conexión?
Sí, y organismos de normalización como AAMVA y EUDI lo exigen explícitamente. El compromiso es que la actualización perfecta en tiempo real es incompatible con el funcionamiento sin conexión perfecto, por lo que la actualización debe convertirse en una decisión de política, no en una dependencia rígida.
Publicado Mayo 04, 2026 • 14m para leer
