La licencia de conducir es el documento de identidad más universalmente aceptado del mundo. Casi todas las jurisdicciones emiten una, casi todos los adultos en esas jurisdicciones llevan una, y casi cualquier situación que pida identidad la acepta. Cuando los organismos de estandarización decidieron construir una credencial de identidad digital criptográficamente verificable para despliegue a escala de consumidor, eligieron el documento que ya tenía alcance global.
El resultado es la licencia de conducir móvil, conocida internacionalmente como mDL (por mobile driver’s license), definida por ISO/IEC 18013-5 y publicada en septiembre de 2021. A lo largo de una lista creciente de estados de Estados Unidos coordinados a través de AAMVA, países miembros de la UE que están implementando la EUDI Wallet, y despliegues piloto en Asia y América Latina, la mDL es el formato que llevó las credenciales verificables del whitepaper a la billetera en el teléfono.
Esta edición recorre qué es realmente una mDL, cómo está estructurada, cómo se presenta y cómo se verifica. Si todavía no leíste nuestra edición del 23 de abril sobre el ciclo de vida de la credencial verificable, es el punto de partida natural para el material que sigue.
Qué es una mDL
Una mDL es una licencia de conducir digital que vive en una aplicación de billetera en el teléfono del ciudadano, firmada por la autoridad de tránsito emisora, y estructurada para presentarse a un verificador en forma offline u online. El ciudadano tiene la credencial en su billetera. El verificador, al consultar, ejecuta una operación criptográfica contra la clave pública del emisor para confirmar que la credencial es genuina y no fue alterada.
El estándar que define todo esto es ISO/IEC 18013-5: Identificación personal, Licencia de conducir compatible con ISO, Parte 5: Aplicación de licencia de conducir móvil (mDL). El estándar especifica la estructura de datos de la credencial, el esquema de firma, los protocolos de presentación entre dispositivos, y las reglas para divulgación selectiva. Un estándar complementario, ISO/IEC 18013-7, extiende el modelo a la presentación en línea no asistida, abordando el caso en que se accede a un verificador a través de la red en lugar de cara a cara.
El objetivo arquitectónico del estándar es darle al ciudadano una licencia de conducir digital que funcione para todos los escenarios comunes que hoy cubre la tarjeta plástica, incluyendo verificación de edad en un local, prueba de identidad en un control de tránsito, y presentación en un cruce fronterizo, sin requerir que el verificador alcance al emisor en tiempo real.
Cómo está estructurada una mDL
Una mDL está codificada de forma distinta a una credencial verificable del W3C, y las diferencias son deliberadas.
Una credencial verificable del W3C es típicamente un documento JSON-LD o un SD-JWT, firmado con una suite de firmas de la familia JOSE. Una mDL está codificada en CBOR, la representación binaria concisa de objetos (Concise Binary Object Representation), y firmada con COSE, el formato CBOR para firma y cifrado de objetos (CBOR Object Signing and Encryption). La estructura que contiene la credencial firmada se llama Mobile Security Object, o MSO, y guarda los datos de la credencial junto con los metadatos requeridos para la presentación y la verificación.
La razón por la que el estándar eligió CBOR y COSE en lugar de JSON y JOSE es que las mDL fueron diseñadas para funcionar en entornos de presentación con recursos limitados: un intercambio Bluetooth a la tableta de un agente de tránsito en la calle, un toque NFC en un control de seguridad de aeropuerto, un intercambio por código QR en la puerta de un local. CBOR es significativamente más compacto que JSON, COSE es significativamente más eficiente que JOSE para firmar y verificar payloads pequeños, y la combinación mantiene el tamaño de la credencial lo suficientemente bajo como para transmitirse de forma confiable sobre protocolos de corta distancia entre dispositivos.
Dentro del MSO, una mDL contiene los mismos campos que la tarjeta plástica: nombre, fecha de nacimiento, número de licencia, número de documento, autoridad emisora, fecha de vencimiento, dirección y categorías de licencia. Cada campo se hashea de forma individual, de modo que el ciudadano puede presentar algunos y omitir otros sin invalidar la firma global del emisor. Esta es la base arquitectónica de la divulgación selectiva, que el estándar trata como capacidad por defecto y no como una extensión opcional.
Cómo se presenta una mDL
ISO 18013-5 define tres modos de presentación, cada uno para un escenario distinto que la licencia plástica cubre hoy.
La recuperación en dispositivo es el modo offline, en el que el ciudadano y el verificador intercambian la credencial directamente entre teléfonos, o entre un teléfono y un dispositivo verificador. El transporte suele ser NFC para acercamientos rápidos, o Bluetooth Low Energy para interacciones algo más extensas, con códigos QR para iniciar la conexión. No se requiere acceso a internet en ninguno de los dos extremos. El control de tránsito en la ruta es el escenario canónico para este modo, y es el escenario alrededor del cual el estándar fue diseñado con más cuidado.
La recuperación por servidor es un modo híbrido, en el que el verificador recibe un token desde el teléfono del ciudadano y usa ese token para obtener la credencial desde un endpoint de servidor que mantiene el emisor. La recuperación por servidor es útil cuando el verificador necesita contexto adicional desde el lado del emisor, aunque vuelve a introducir una dependencia de que el emisor esté disponible al momento de la presentación, una de las dependencias que el modo offline fue diseñado para eliminar.
La presentación en línea no asistida, definida en ISO 18013-7, aborda el caso en el que el verificador es un sitio web o un servicio en lugar de una persona con un dispositivo. El flujo usa un protocolo basado en OpenID para autorizar y transmitir la credencial, y es el puente que hace presentables las mDL ante e-commerce, banca, y servicios gubernamentales en línea. ISO 18013-7 es el estándar complementario hacia el cual la mayoría de los despliegues están construyendo hoy para los escenarios de verificación en línea.
Cómo se verifica una mDL
Cuando un verificador recibe una mDL, la operación de verificación tiene tres partes.
El verificador confirma que la firma del emisor sobre el MSO es válida, usando la clave pública del emisor. Esa clave pública la publica la autoridad emisora a través de un registro de confianza al que el verificador tiene acceso, típicamente mantenido por AAMVA en Estados Unidos, por autoridades nacionales en la UE bajo la EUDI Wallet ARF, y por organismos nacionales equivalentes en otros lugares. El verificador confirma que la divulgación selectiva es consistente, comparando los hashes de los campos que el ciudadano eligió revelar contra los hashes registrados en el MSO. El verificador confirma que la credencial no fue revocada, consultando el mecanismo de estado del emisor.
La divulgación selectiva merece una mirada más cercana, porque es una de las decisiones arquitectónicas que le da a la mDL su carácter operativo. Un encargado de seguridad que necesita confirmar que un ciudadano es mayor de 21 recibe la respuesta “sí” junto con la prueba criptográfica de que esa respuesta vino de la autoridad emisora, sin recibir la fecha de nacimiento del ciudadano, su nombre, ni su dirección. La misma credencial soporta a un verificador bancario que pide nombre completo y fecha de nacimiento para fines de conoce-a-tu-cliente. El ciudadano controla qué campos se liberan en cada presentación, y la estructura criptográfica del MSO garantiza que los campos retenidos no puedan inferirse a partir de los revelados.
Cubrimos las primitivas criptográficas detrás de la divulgación selectiva en nuestra edición del 26 de febrero sobre pruebas de conocimiento cero, que es la referencia para quienes quieran una mirada más profunda al funcionamiento matemático.
Dónde encaja Sovra
Sovra construye la capa institucional sobre la que operan las autoridades emisoras y los verificadores. SovraGov maneja el lado de la emisión: cómo un organismo de gobierno configura tipos de credenciales, las firma, gestiona claves, y publica sus raíces de confianza. SovraID maneja el lado de la verificación: cómo una institución verificadora se registra como contraparte, obtiene los datos de la lista de confianza, y ejecuta los chequeos criptográficos sobre las credenciales entrantes. SovraWallet guarda las credenciales del lado del ciudadano, incluyendo credenciales en formato W3C y credenciales en formato mDL ISO 18013-5 dentro de la misma billetera, presentándolas a través de OpenID4VP y a través de los protocolos de recuperación en dispositivo de ISO 18013-5 cuando el caso de uso lo requiere.
La infraestructura institucional sigue siendo la misma sin importar qué stack de credenciales use un despliegue específico. Las suites de firma difieren, la codificación difiere, los protocolos de presentación difieren, y los mecanismos de registro de confianza, el comportamiento de rotación de claves, la publicación de revocaciones y el onboarding institucional se mantienen consistentes a través de ambos formatos. A lo largo del stack en producción, se han emitido más de 10M de credenciales y procesado más de 50M de verificaciones contra esta arquitectura, abarcando múltiples formatos de credencial y múltiples contextos de presentación.
Desde el equipo
[PLACEHOLDER — confirmar con el equipo antes de enviar: trabajo de convergencia entre credenciales verificables del W3C y mDL ISO 18013-5 en el roadmap de SovraWallet, progreso en el alineamiento del perfil OpenID4VP, conversaciones de piloto de mDL, o un hito de despliegue específico de la semana. Usar únicamente datos verificados.]
Vale la pena leer esta semana
La descripción general del estándar ISO 18013-5 es el punto de partida más autorizado para entender la especificación de mDL, aunque el estándar completo es de pago. Para una guía gratuita, la Guía de Implementación de mDL de AAMVA cubre el patrón práctico de despliegue contra el que están construyendo los estados de Estados Unidos, incluyendo la publicación de listas de confianza, el onboarding de proveedores de billetera, y la integración del verificador. Vale la pena tener ambos a mano para cualquier persona que esté evaluando un despliegue de mDL en su jurisdicción.
Continuemos la conversación
Hay más recursos técnicos sobre el stack de credenciales verificables, incluyendo implementaciones de referencia y casos de despliegue tanto en formatos del W3C como ISO 18013-5, disponibles en sovra.io/knowledge.
Si estás trabajando en un despliegue de mDL o evaluando cómo encaja con infraestructura W3C existente, respondé. Leemos cada respuesta.
Suscribite a The Identity Brief, se publica todos los jueves.