Ningún estándar único reemplazará el Permiso Internacional de Conducción (PIC) en papel. El verdadero sucesor es un conjunto de estándares que trabajan en conjunto, y comprender esa arquitectura es clave para entender hacia dónde se dirigen realmente las credenciales digitales de conducción transfronterizas.
Por Qué Ningún Estándar Único Reemplazará el PIC en Papel
La mayoría de los debates sobre el futuro PIC comienzan con la pregunta equivocada: ¿qué estándar reemplazará al permiso en papel? Ese enfoque asume que una sola especificación puede hacer todo el trabajo. No puede.
El trabajo de NIST sobre la licencia de conducir móvil (mDL) señala explícitamente que están surgiendo nuevos estándares de credenciales digitales en distintas áreas de problemas. La propia familia ISO 18013 ya está dividida en múltiples partes que cubren diseño físico, seguridad, presentación móvil y extensiones para internet. Una futura credencial de conducción transfronteriza no es, por lo tanto, una sola especificación, sino una pila coordinada de especificaciones, cada una abordando un aspecto diferente.
La Pila del Futuro PIC en Resumen
Estas son las ocho capas que, en conjunto, definen cómo será un futuro PIC:
- Capa 0 — Base física y de datos: ISO/IEC 18013-1
- Capa 1 — Seguridad de la credencial: ISO/IEC 18013-3
- Capa 2 — Presentación en proximidad (presencial): ISO/IEC 18013-5
- Capa 3 — Presentación remota / por internet: ISO/IEC 18013-7
- Capa 4 — Semántica de la credencial: Modelo de Datos de Credenciales Verificables W3C 2.0
- Capa 5 — Protocolo de emisión: OpenID4VCI
- Capa 6 — Protocolo de solicitud y presentación: OpenID4VP
- Capa 7 — Distribución de confianza y autorización de verificadores: Registros de confianza (modelo VICAL de AAMVA, modelo de partes de confianza basado en certificados de EUDI)
Cada capa está fundamentada en estándares vigentes o en documentación activa del ecosistema. Las secciones siguientes explican qué hace cada capa y, con igual importancia, qué no hace.
Capa 0 — ISO/IEC 18013-1: La Fundación Física y Semántica
La Parte 1 importa más de lo que la mayoría de la gente cree, porque no se trata únicamente del diseño de la tarjeta.
ISO/IEC 18013-1 define las características físicas y el conjunto básico de datos de una licencia de conducir conforme a ISO, estableciendo una base común para el uso internacional y el reconocimiento mutuo. Se basa en una tarjeta segura de formato ID-1 acompañada de un folleto para uso internacional, sustituyendo al antiguo modelo del PIC en papel. ISO también señala que, en muchos casos, una sola tarjeta puede reemplazar la necesidad de dos documentos separados.
La implicación práctica es sencilla: el futuro PIC no puede comenzar en la capa de la billetera digital. Si la estructura del documento subyacente, el modelo de datos y el diseño no están estandarizados primero, cada capa digital superior se convierte en un parche de compatibilidad sobre formatos nacionales fragmentados. La Parte 1 es la base de la que depende el resto de la arquitectura.
Capa 1 — ISO/IEC 18013-3: Seguridad de la Credencial
La Parte 3 es donde la credencial deja de ser simplemente datos en un documento para convertirse en un objeto de seguridad. ISO describe la 18013-3 como la parte que especifica mecanismos para:
- Control de acceso a datos legibles por máquina
- Autenticación del documento
- Validación de integridad
ISO también es explícita en que la Parte 3 no aborda los problemas de privacidad relacionados con el uso posterior de los datos, y ese límite es importante.
En resumen, la 18013-3 proporciona seguridad de la credencial, no una gobernanza completa del ecosistema. Ayuda a responder preguntas como: ¿Fue esta credencial emitida por la autoridad declarada? ¿Han sido alterados los datos? No responde completamente: ¿Debería este verificador siquiera solicitar este campo? ¿Debería permitirse esta solicitud en este contexto?
Esta es también una capa activa, no un producto terminado. ISO incluye una enmienda de 2022 para el protocolo PACE, una enmienda de 2023 para actualizaciones de autenticación pasiva, y un nuevo borrador de la 18013-3 actualmente en desarrollo.
Capa 2 — ISO/IEC 18013-5: Presentación Móvil en Persona
Si la Parte 1 define el documento y la Parte 3 lo protege, la Parte 5 convierte la licencia en una credencial móvil.
ISO especifica que la 18013-5 cubre la interfaz entre la mDL y el lector, y entre el lector y la infraestructura de la autoridad emisora. También permite que terceros, incluidas autoridades y verificadores de otros países, puedan:
- Obtener datos de la mDL por medios automáticos
- Vincular esos datos al titular
- Autenticar su origen
- Verificar su integridad
Lo que la 18013-5 no cubre es igualmente importante. ISO enumera explícitamente los elementos fuera de su alcance, incluyendo cómo se obtiene el consentimiento del titular para compartir datos y los requisitos para almacenar datos de la mDL y claves privadas. La Parte 5 no es un producto de billetera completo, ni un modelo completo de consentimiento del usuario, ni un sistema de gobernanza completo. Es la capa de transporte y verificación para la presentación móvil.
La guía de implementación de AAMVA precisa esto aún más al distinguir entre dos modelos de recuperación de datos:
- Recuperación desde el dispositivo, donde los datos se leen directamente del dispositivo del titular.
- Recuperación desde el servidor, que puede permitir a la autoridad emisora observar cuándo se utiliza la mDL, qué datos se comparten e incluso estimar la ubicación física mediante análisis de la dirección IP.
Ese segundo punto no es una razón para rechazar el estándar, sino una razón para ser precisos sobre qué modelo de recuperación debería utilizar por defecto un futuro PIC. AAMVA también exige que la billetera otorgue al titular control total sobre qué elementos de datos se comparten, lo cual se adapta mucho mejor a un futuro PIC que el antiguo modelo de “mostrar el documento completo”.
Capa 3 — ISO/IEC 18013-7: Presentación por Internet
La Parte 5 resuelve el problema de la presentación presencial. La Parte 7 extiende ese modelo al uso remoto.
ISO describe la 18013-7:2025 como una extensión de la 18013-5 con presentación de una mDL a un lector a través de internet. El internet no es una consideración secundaria en esta arquitectura; es una parte explícita del estándar.
El manual de licencias de conducir móviles de la Unión Europea ya trata la presentación por internet como algo práctico y no meramente teórico, describiendo escenarios como:
- Registro en el alquiler de vehículos, donde los usuarios comparten su mDL de forma presencial o de manera remota con antelación
- Controles en carretera realizados por la policía
- Un perfil general de uso de la mDL basado en ISO/IEC 18013-5 e ISO/IEC 18013-7
Dicho esto, la orientación actual de AAMVA es honesta sobre las limitaciones: el uso de la mDL a través de internet es muy deseable, pero algunos estándares de soporte aún están en proceso de maduración. Existen brechas reales en la integración actual entre billeteras y navegadores, y sin una lista de lectores de confianza, el lado mdoc puede no tener una forma fiable de confirmar ciertas propiedades de seguridad. La presentación remota es real, y sigue desarrollándose.
Aun con esas advertencias, la 18013-7 es la primera respuesta seria a un problema que el PIC en papel nunca intentó resolver: presentar habilitaciones de conducción de forma remota, antes de que la persona llegue al mostrador o al punto de control.
Capa 4 — Modelo de Datos W3C VC 2.0: La Capa Semántica
El Modelo de Datos de Credenciales Verificables 2.0 de W3C no es un estándar específico para licencias de conducir, y precisamente por eso importa.
La Recomendación define un modelo de datos extensible para credenciales verificables, explica cómo pueden protegerse ante modificaciones y describe el ecosistema en términos de tres roles fundamentales: emisores, titulares y verificadores. Una licencia de conducir aparece como uno de sus ejemplos centrales.
Para un futuro PIC, VC 2.0 aporta un vocabulario general para declaraciones, presentaciones y registros de datos verificables. W3C es explícito en que dichos registros pueden adoptar diversas formas, entre ellas:
- Bases de datos de confianza
- Bases de datos de identidad gubernamental
- Bases de datos descentralizadas
- Libros contables distribuidos
Esto rompe la falsa dicotomía entre un enfoque exclusivamente basado en cadena de bloques y uno completamente propietario. El modelo de datos es más amplio que ambos.
VC 2.0 también es claro en cuanto a la divulgación selectiva. W3C señala que una licencia de conducir puede contener más datos de los necesarios para un caso de uso concreto, y recomienda dividir la información en fragmentos más pequeños o utilizar mecanismos que permitan la divulgación selectiva. Para un futuro PIC, esto no es una opción de privacidad adicional, sino la diferencia entre una credencial moderna y una fotocopia digital de una tarjeta de plástico.
VC 2.0 no es, sin embargo, un reemplazo completo de ISO 18013. W3C señala que el modelo de datos no requiere un modelo tradicional de cadena de confianza basado en autoridades de certificación. En la práctica, VC 2.0 es una sólida capa semántica, pero aún es necesario que sobre ella se sitúen capas explícitas de distribución de confianza y gobernanza de verificadores.
Capa 5 — OpenID4VCI: El Protocolo de Emisión
Un futuro PIC necesita una forma estándar de transferir una credencial desde un emisor a una billetera. Ese es el papel de OpenID para la Emisión de Credenciales Verificables (OpenID4VCI) 1.0.
La especificación define una API protegida con OAuth para la emisión de credenciales verificables, y es intencionalmente independiente del formato. Entre los formatos de credencial que admite:
- ISO mdoc
- SD-JWT VC
- Credenciales W3C VCDM
También admite la vinculación al titular y presentaciones posteriores sin necesidad de intervención del emisor. OpenID4VCI 1.0 fue aprobado como Especificación Final en septiembre de 2025.
Esto hace que OpenID4VCI sea estratégicamente importante para el ecosistema del futuro PIC. En lugar de construir canales propietarios de emisor a billetera para cada jurisdicción o proveedor de billetera, el ecosistema puede definir un perfil de emisión regulado sobre un marco de emisión estándar, manteniendo la flexibilidad de elegir si la credencial resultante se codifica en mdoc, VC u otro formato compatible. Esa flexibilidad es uno de los argumentos más sólidos para mantener modular la arquitectura del futuro PIC.
Capa 6 — OpenID4VP: El Protocolo de Solicitud y Presentación
Si OpenID4VCI introduce la credencial en la billetera, OpenID para Presentaciones Verificables (OpenID4VP) la extrae de forma controlada.
La especificación define un mecanismo para solicitar y presentar credenciales. Su funcionamiento base utiliza mensajes HTTPS y redirecciones, pero también admite el uso a través de la API de Credenciales Digitales del W3C en lugar de flujos de redirección. OpenID4VP 1.0 alcanzó el estado de Especificación Final en julio de 2025.
Esto importa porque proporciona a la arquitectura del futuro PIC una capa de presentación nativa para la web que sitios web, aplicaciones y verificadores en línea pueden implementar directamente. Varios desarrollos recientes refuerzan esto:
- En agosto de 2025, la Fundación OpenID anunció un análisis formal de seguridad de OpenID4VP utilizado sobre la API de Credenciales Digitales, sin que se encontraran nuevas vulnerabilidades en el modelo de protocolo verificado.
- El borrador actual de mDL del NIST construye su modelo de amenazas en torno a la solicitud y presentación de mDL mediante OpenID4VP sobre la API de Credenciales Digitales del W3C, con FIDO CTAP utilizado para reforzar la proximidad y resistir el phishing en los flujos pertinentes.
El lado web de la arquitectura y el lado mDL están convergiendo. OpenID4VP no debe interpretarse como un competidor de ISO 18013-7, sino como la capa de protocolo web que hace práctica la presentación por internet en entornos reales de navegadores, billeteras y verificadores.
Capa 7 — Registros de Confianza: Donde la Arquitectura Se Convierte en Ecosistema
Esta es la capa que muchos debates omiten, y la que determina si el sistema completo funciona realmente.
Un verificador no puede hacer gran cosa con una credencial firmada a menos que conozca tres cosas:
- Qué emisores son legítimos
- Qué claves públicas están vigentes
- Si la parte solicitante está ella misma autorizada
En el lado del emisor, el Servicio de Confianza Digital de AAMVA ofrece una respuesta concreta. Proporciona una forma única, segura y resiliente para que las partes dependientes obtengan las claves públicas de las autoridades emisoras, distribuidas a través de la Lista de Autoridades de Certificación de Emisores Verificados (VICAL). La guía de AAMVA describe el papel del proveedor VICAL en términos prácticos: recopilar claves públicas de las autoridades emisoras legítimas, verificar que dichas autoridades gestionen sus claves de forma segura, combinarlas en un único VICAL y entregarlo a los verificadores.
En el lado del verificador, Europa aborda el problema de la confianza desde otra dirección. En el Marco de Arquitectura y Referencia de la Cartera Digital de la Unión Europea (EUDI), las partes dependientes se registran, obtienen certificados de acceso y los utilizan para autenticarse ante las aplicaciones de billetera cuando solicitan atributos. La billetera verifica entonces la cadena de certificados, comprueba el estado de revocación, presenta la solicitud al usuario y libera únicamente los atributos aprobados.
El modelo VC de W3C también contribuye aquí, tratando los registros de datos verificables como un rol diferenciado dentro del ecosistema. Como se señaló anteriormente, esos registros pueden ser bases de datos de confianza, bases de datos de identidad gubernamental, bases de datos descentralizadas o libros contables distribuidos. Un registro de confianza para el futuro PIC no necesita estar construido sobre cadena de bloques. Necesita estar gobernado, ser auditable y legible por máquinas.
Si ISO 18013 define cómo se ve y se transmite la credencial, los registros de confianza deciden si alguien debería creer en ella.
Cómo Funciona una Transacción del Futuro PIC de Principio a Fin
A continuación, la arquitectura en funcionamiento, desglosada en los cuatro momentos clave del ciclo de vida de una credencial.
1. Emisión. Una autoridad nacional, o un emisor autorizado bajo una gobernanza estricta, verifica el registro de licencia subyacente y emite una credencial en la billetera del titular. OpenID4VCI es la capa de emisión más práctica disponible hoy en día, ya que ya admite los formatos ISO mdoc, SD-JWT VC y W3C VCDM. La propia ISO 18013-5 deja fuera de su alcance la recopilación del consentimiento y el almacenamiento de claves privadas, que es exactamente por qué la emisión y la gobernanza de la billetera deben operar por encima de la capa de transporte ISO básica.
2. Presentación presencial. En un control de tráfico en carretera o en el mostrador de una arrendadora de vehículos, la billetera presenta la credencial mediante un flujo de proximidad basado en la 18013-5. El lector valida el origen y la integridad utilizando las claves del emisor obtenidas de un registro de confianza, en lugar de tomar decisiones de confianza por sí mismo. El titular aprueba únicamente los campos necesarios para esa situación específica.
3. Presentación remota. Para verificaciones previas al alquiler u otros procesos en línea, el verificador solicita un conjunto mínimo de atributos a través de un flujo habilitado para internet mediante 18013-7 y/o OpenID4VP. La billetera muestra qué atributos se están solicitando, el titular los aprueba y el verificador recibe una presentación estructurada en lugar de un escáner o un archivo PDF adjunto. La arquitectura actual del NIST, construida en torno a OpenID4VP junto con la API de Credenciales Digitales, demuestra que esta es ahora una vía de implementación práctica.
4. Confianza y autorización del verificador. La billetera no confía ciegamente en cualquier solicitante. Un ecosistema maduro autentica a la parte dependiente, valida las cadenas de certificados, comprueba el estado de revocación y ofrece al usuario visibilidad sobre quién está solicitando qué datos. El modelo EUDI es particularmente sólido en este aspecto, al tratar el registro de verificadores y los certificados de acceso como partes esenciales del sistema, no como complementos opcionales.
Este flujo completo es precisamente por qué un futuro PIC debe ser una arquitectura en capas. Ninguna capa individual puede lograrlo por sí sola. No ISO por sí solo. No VC por sí solo. No OpenID por sí solo. Y desde luego no un PDF adjunto a un formulario.
Qué Falta Todavía en la Arquitectura del Futuro PIC
El problema más difícil que queda por resolver ya no es crear nueva criptografía, sino lograr la interoperabilidad gobernada.
Considérese el estado actual del ecosistema:
- El NIST ha descrito el panorama actual de estándares como algo que se está desarrollando en áreas separadas.
- AAMVA ha construido un servicio de confianza regional para América del Norte.
- Europa está integrando la confianza de partes dependientes basada en certificados en la arquitectura de su billetera digital.
- OpenID ha finalizado las especificaciones de emisión y presentación y está ampliando su infraestructura de conformidad.
Estas siguen siendo respuestas específicas de cada ecosistema. Todavía no existe una capa de confianza transfronteriza global para credenciales de conductor. El trabajo pendiente consiste en definir:
- Qué partes de la arquitectura son obligatorias
- Qué formatos de credencial son aceptables
- Cómo se distribuye la confianza entre emisores y verificadores
- Cómo se verifica la conformidad
- Cómo se gobierna el reconocimiento transfronterizo sin comprometer la privacidad
Conclusión: El Futuro PIC Es una Arquitectura en Capas, No un Documento
El futuro PIC no aparecerá porque una organización de estándares redacte un único documento. Surgirá cuando una arquitectura coherente sea definida, gobernada y adoptada en múltiples jurisdicciones. Esa arquitectura ya tiene capas identificables:
- ISO/IEC 18013-1 para la base documental
- ISO/IEC 18013-3 para la seguridad de la credencial
- ISO/IEC 18013-5 para la presentación móvil presencial
- ISO/IEC 18013-7 para la presentación remota
- W3C VC 2.0 para la semántica portable
- OpenID4VCI para la emisión
- OpenID4VP para la solicitud y presentación
- Registros de confianza para la confianza automatizada y la autorización de verificadores
Esa es la arquitectura detrás del futuro PIC. No un folleto. No una aplicación. Una arquitectura en capas.
Publicado Mayo 11, 2026 • 14m para leer
