What is a mobile driver license (mDL)?

An mDL is the digital equivalent of a plastic driver's license, issued by your state DMV (or national authority) and stored in a wallet app on your phone. It is governed by ISO/IEC 18013-5, an international standard that specifies how attributes are signed, transferred, and verified. US states including Arizona, Colorado, Maryland, Georgia, Iowa, Mississippi, Ohio, Utah, Virginia, and a growing list are issuing mDLs; California has it in production; the EU is rolling out its own variant under EUDI Wallet (eIDAS 2.0).

What's encoded in the QR?

Under ISO/IEC 18013-5 section 8.2, the QR carries a CBOR-encoded DeviceEngagement structure. That structure declares the wallet's ephemeral public key (eDeviceKey), the cipher suite used (currently P-256 / ECDH-ES), and the list of transfer methods the wallet supports (NFC, Bluetooth LE, Wi-Fi Aware). It does NOT carry the actual license attributes (name, DOB, license number, photo). Those are sent over the chosen transfer channel AFTER the verifier requests specific attributes and the holder approves.

How is this different from the PDF417 barcode on the back of a plastic license?

Completely different. The PDF417 barcode on plastic AAMVA cards encodes every attribute on the card in plaintext, name, address, DOB, license number, restrictions, donor status, and any scanner can read all of it. An mDL QR is just a handshake. The verifier has to ASK for specific attributes (e.g. 'over 21? yes/no') and the holder has to APPROVE the release on their phone. The wallet can answer 'over 21 = yes' without disclosing the actual date of birth, that's called selective disclosure.

What does selective disclosure mean in practice?

A bartender scanning your mDL needs to know one thing: are you of legal drinking age? With a plastic license, you hand over the card and they see your full address, DOB, and license number. With an mDL the bartender's verifier app requests only the age_over_21 attribute. Your phone shows you that request, you approve, and a signed boolean is transferred. Nothing else. ISO/IEC 18013-5 supports a long list of such derived attributes (age_over_18, age_over_21, age_over_65), plus full attributes when actually needed (a car rental probably needs full name and license number; a bouncer doesn't).

What's a hostile verifier and how do I spot one?

A hostile verifier is a verifier app that asks for more attributes than the transaction needs, e.g. a bar asking for full address, license number, and photo when it only needs age_over_21. This is a real risk because verifier apps are not centrally regulated; anyone can build one. The mDL standard requires the wallet to display the full list of requested attributes before the holder approves, so the defense is reading that list. If the bar wants your home address to pour a beer, decline. ISO/IEC 18013-5 also supports verifier authentication (the verifier signs its request with a certificate from a trust list), so a scrupulous wallet warns when the verifier isn't on a known trust list. The list of recognized verifiers is jurisdiction-specific and still maturing.

Estándares · Licencia de conducir móvil (mDL)

Códigos QR de licencia de conducir móvil: ISO/IEC 18013-5

Cuando un camarero, un agente de la TSA o un empleado de alquiler de coches escanea el QR de la app de licencia de conducir de su teléfono, ese QR no es la licencia. Es un protocolo de enlace. Los atributos reales solo se transmiten después de que el verificador solicite campos concretos y usted apruebe la cesión en su teléfono. Bien implementado, un mDL filtra mucho menos que una tarjeta física. Mal implementado (verificador hostil, aprobación global), filtra la misma cantidad o más. Así se distingue la diferencia.

Inspeccionar un QR mDL → Todos los estándares →

¿Cuál es el estándar?

ISO/IEC 18013-5:2021, Identificación personal, licencia de conducir conforme a ISO, Parte 5: Aplicación de licencia de conducir móvil (mDL). El estándar internacional que especifica cómo se emiten, almacenan, transfieren a un verificador y se verifican sin conexión las licencias de conducir digitales. La superficie QR (la parte que la mayoría de las personas ve) es la sección 8.2 "Recuperación en dispositivo, activación por código QR". Un estándar complementario, ISO/IEC 18013-7, cubre la recuperación en línea (el verificador consulta directamente al emisor con el consentimiento del titular).

La adopción está bien encaminada: una docena de estados de EE. UU. tienen mDLs en producción o en fase piloto en Apple Wallet y Google Wallet; la mDL de California está en disponibilidad general; la TSA acepta mDLs en los controles de seguridad de la mayoría de los principales aeropuertos de EE. UU.; la UE está integrando su variante en la EUDI Wallet bajo eIDAS 2.0 (reglamento vigente desde finales de 2024, wallets previstas para 2026-2027). El estándar es también la base de ISO/IEC 23220 (marco general de credenciales móviles, que abarca más allá de los permisos de conducir).

Qué hay realmente dentro del QR

El QR del mDL codifica una estructura CBOR de DeviceEngagement. CBOR (Concise Binary Object Representation, RFC 8949) es una alternativa binaria compacta a JSON. La estructura decodificada tiene aproximadamente este aspecto:

{
  0: "1.0",                         // version
  1: [1, 2, [eDeviceKey bytes]],    // security: cipher suite 1, EC P-256 key
  2: [                              // device retrieval methods
    [1, 1, {...NFC options...}],
    [2, 1, {...BLE options...}],
    [3, 1, {...Wi-Fi Aware options...}]
  ],
  3: {...optional server retrieval...}
}

Campos clave, decodificados:

Versión

Siempre "1.0" en los despliegues actuales. Revisiones futuras podrían incrementarlo.

Conjunto de cifrado

Actualmente siempre 1: acuerdo de clave ECDH sobre P-256, cifrado de sesión AES-GCM. El conjunto de cifrado 2 está reservado para brainpoolP320r1 (casos de uso de la UE).

eDeviceKey

Una clave pública EC efímera generada por sesión por la cartera. La utiliza el verificador para establecer una sesión cifrada. Se destruye tras la transacción. Nuestro escáner le muestra la longitud de este campo, pero nunca devuelve los bytes de la clave; son efímeros y solo tienen significado para la sesión del verificador en curso.

Métodos de transferencia

La cartera indica al verificador qué canales está dispuesta a usar para la transferencia real de atributos: NFC (proximidad), Bluetooth LE o Wi-Fi Aware (Wi-Fi entre pares sin punto de acceso). La mayoría de mDLs ofrecen BLE y NFC; Wi-Fi Aware está limitado a ciertas plataformas.

Recuperación desde servidor (opcional)

Si está presente, la cartera admite el modo 18013-7: el verificador puede solicitar atributos desde la API en línea del emisor en lugar de directamente desde la cartera. El QR incluye la URL del emisor. Nuestro escáner la extrae y le muestra qué autoridad recibiría la consulta.

¿En qué se diferencia esto del PDF417 AAMVA de la tarjeta física?

Es una categoría de credencial diferente. El código de barras PDF417 de AAMVA en el reverso de una licencia plástica estadounidense contiene todos los atributos de la tarjeta en texto plano: nombre, dirección, fecha de nacimiento, número de licencia, estatura, peso, color de ojos, restricciones y estado de donante de órganos. Cualquier escáner puede leer todo eso. La tarjeta es una credencial de "todo o nada": o la entregas y revelas todo, o no lo haces.

Un mDL invierte eso. El QR no lleva atributos, solo un handshake. El verificador tiene que solicitar atributos específicos (given_name, family_name, birth_date, age_over_21, portrait, document_number, driving_privileges, etc.), la billetera te muestra la solicitud, y solo los atributos que apruebas se transfieren. La transferencia también está firmada criptográficamente por la autoridad emisora (el DMV de tu estado), así que el verificador puede confirmar que los atributos son auténticos sin llamar a ningún servidor; la verificación offline funciona.

Por eso quienes valoran la privacidad prefieren los mDL aunque el estándar sea más complejo: permite una divulgación acotada a la transacción. Un portero no necesita tu dirección; un agente de la TSA no necesita saber si eres donante de órganos; un empleado de 7-Eleven no necesita tu número de licencia.

Divulgación selectiva: el punto clave

El estándar mDL define un conjunto de atributos derivados que permiten al verificador hacer una pregunta de sí/no en lugar de obtener un valor en bruto. Los más relevantes:

age_over_18, age_over_21, age_over_65, para compras con restricción de edad sin revelar la fecha de nacimiento.
resident_state, para preguntas del tipo «¿es residente del estado?» sin revelar la dirección.
driving_privileges, categoría de licencia y restricciones; para el alquiler de vehículos.

Una app verificadora bien diseñada para un bar solicita únicamente age_over_21. La billetera muestra "Bar XYZ quiere saber si eres mayor de 21 años." Tocas Aprobar, y un único booleano firmado ("true") regresa al sistema. La app del bar verifica la firma contra el trust root de mDL publicado por tu estado. Listo. Sin fecha de nacimiento, sin nombre, sin número de licencia, sin foto. Comparado con entregar la tarjeta física, esto es una mejora de privacidad enorme.

Verificadores hostiles: el nuevo modelo de amenaza

El modelo de amenaza de la tarjeta física era simple: perderla, copiarla, que alguien la vea por encima del hombro. El modelo de amenaza del mDL es distinto. El formato es sólido; la criptografía es correcta; el riesgo se desplaza hacia la app verificadora al otro lado de la transacción.

Cualquiera puede crear una app verificadora. No existe ninguna autoridad central de licencias. Así, un bar podría usar un verificador genérico configurado para pedir fecha de nacimiento completa, nombre completo y foto, aunque solo necesite age_over_21. Un empleado de alquiler de coches podría pedir todo «para el expediente». Un dependiente podría pedir la dirección. Nada de esto está técnicamente prohibido por el estándar; el estándar solo exige que la cartera muestre al titular qué se está solicitando y requiera aprobación explícita.

Por eso la defensa recae en el titular: lea el mensaje de solicitud. Si el verificador pide más de lo que la transacción necesita, rechácelo. Algunas carteras advierten cuando el verificador no está en una lista de confianza conocida; ISO/IEC 18013-5 admite autenticación de verificadores mediante certificados, pero la infraestructura de listas de confianza aún está madurando (listas por estado en EE. UU.; lista de confianza de la UE bajo eIDAS 2.0).

También conviene saber que el verificador ve su eDeviceKey, el conjunto de cifrado y los métodos de transferencia que admite, y nada más. No obtiene atributos solo con el QR. Escanear un QR de una pegatina o la pantalla de alguien y marcharse no le aporta nada útil a un atacante. Los atributos solo viajan dentro de la sesión cifrada tras el protocolo de enlace.

Lo que nuestro escáner te muestra

Suelta un QR de DeviceEngagement mDL (imagen, pegado o cámara) en nuestro escáner. El veredicto muestra:

Estándar, ISO/IEC 18013-5 §8.2 DeviceEngagement (CBOR).
Versión, generalmente 1.0.
Suite de cifrado, la suite de cifrado nombrada (P-256 / brainpool / etc.).
Métodos de transferencia, qué canales ofrece la billetera (NFC, BLE, Wi-Fi Aware).
Host de recuperación del servidor, si la billetera admite el modo 18013-7, qué URL del emisor gestionaría las solicitudes de atributos.
Longitud de eDeviceKey, confirma que la clave está presente y bien formada, sin exponer los bytes.

No decodificamos ningún atributo, no hay atributos en el QR, por diseño. Los datos reales de la licencia viajarían cifrados a través del método de transferencia elegido hacia un verificador real.

La decodificación ocurre en tu navegador; solo los metadatos estructurales llegan a nuestro servidor para la clasificación de seguridad.

Antes de aprobar una solicitud de verificador

Lee la solicitud. El estándar obliga a tu billetera a mostrarte la lista completa de atributos solicitados. Léela.
¿La solicitud coincide con la transacción? Un camarero que pide la fecha de nacimiento completa en lugar de age_over_21 = rechazar o preguntar por qué. Un empleado de alquiler de coches que pide el estado de donante de órganos = rechazar.
¿Está el verificador en una lista de confianza? Algunas carteras muestran una marca de verificación para verificadores conocidos (certificados emitidos por la raíz de confianza del DMV de su estado). Los verificadores desconocidos deben hacerle dudar.
La recuperación en línea (18013-7) es más potente y más invasiva. Si la billetera pregunta si deseas permitir que el verificador consulte tu DMV estatal directamente, esto crea un registro de auditoría en el DMV. Adecuado para algunas transacciones (TSA, verificaciones de identidad oficial), innecesario para otras (comprar cerveza).
Siempre puedes negarte. El propósito de la divulgación selectiva es precisamente que tú controlas qué información sale de tu teléfono. Si un verificador no acepta una divulgación reducida, puedes recurrir a la tarjeta física o abandonar la transacción.

Relacionado

Licencia de conducir AAMVA PDF417, el código de barras en tarjeta plástica que este formato reemplaza.
QR de contraseña de paso FIDO2, otro QR de enlace entre dispositivos.
Estafas con QR que debes vigilar en 2026
Todos los estándares QR que verificamos
Listado de cobertura completa

Inspeccionar un QR DeviceEngagement de mDL

Cargue el QR (imagen, pegado o cámara). El veredicto muestra la versión, el conjunto de cifrado, los métodos de transferencia y cualquier URL opcional de recuperación desde servidor. Sin atributos: esos solo viajan dentro de la sesión cifrada posterior al protocolo de enlace, ante un verificador real.

Abrir escáner →