El mayor error de diseño en un futuro Permiso Internacional de Conducción (PIC) sería tratar a todos los verificadores como si fueran el mismo verificador. Un agente de policía, un mostrador de alquiler de coches, un empleador y una aseguradora no hacen la misma pregunta, por lo que no deberían recibir la misma respuesta.
Un conductor. Un derecho subyacente a conducir. Una cartera digital. Pero cuatro verificadores muy distintos:
- Un agente de policía en la vía pública
- Un mostrador de alquiler de coches en la recogida del vehículo
- Un empleador que comprueba la aptitud para conducir vehículos de flota
- Una aseguradora que revisa una reclamación
Si el futuro PIC muestra los mismos datos a los cuatro, el sistema ya ha fracasado. No porque la credencial sea insegura, sino porque el modelo de divulgación es demasiado simple.
La comunidad de estándares ya se está alejando de ese modelo simple. El trabajo sobre credenciales verificables del W3C describe el ecosistema de emisores, titulares y verificadores, utilizando empleadores y sitios web como ejemplos de verificadores. El trabajo de la UE sobre la licencia de conducción móvil ya trata las verificaciones en vía pública y los alquileres de coches como escenarios de verificación separados, incluyendo la compartición remota anticipada para alquileres y las comprobaciones presenciales para la policía. La arquitectura ya está diseñada para múltiples tipos de verificadores. El error sería diseñar la experiencia de usuario como si solo existiera uno.
Por Qué la Tarjeta Física Nos Enseñó a Pensar Incorrectamente
Un permiso físico nos acostumbró a un enfoque de mostrar-todo. Se entrega la tarjeta. La otra persona ve lo que hay en ella. Esa es toda la interacción.
Este enfoque es aceptable en un mundo en papel porque no hay alternativa. Se vuelve inaceptable en uno digital.
El W3C VC Data Model 2.0 afirma directamente: un permiso de conducción puede contener número de identificación, estatura, peso, fecha de nacimiento y domicilio, pero eso puede seguir siendo mucho más de lo necesario para una transacción concreta. Puntos clave de los estándares actuales:
- Buena práctica del W3C: admitir la divulgación selectiva y solicitar únicamente lo estrictamente necesario
- Orientación de protección de datos de la UE: el tratamiento debe limitarse a finalidades específicas, y los datos tratados deben ser necesarios y proporcionados
- El primer principio de un futuro PIC: la misma credencial no implica el mismo derecho de inspección
El Modelo Correcto Es la Divulgación Basada en Políticas
Si se quiere una arquitectura seria, el modelo correcto se aproxima más al control de acceso basado en atributos que a la presentación de una tarjeta digital.
El NIST SP 800-205 define las decisiones de control de acceso como evaluaciones de los atributos asociados al sujeto, el objeto, la operación solicitada y las condiciones del entorno, confrontadas con una política. Esa es exactamente la estructura adecuada para un futuro PIC:
- Sujeto: el conductor
- Objeto: los campos de datos solicitados
- Acción: no «ver el permiso» en abstracto, sino algo concreto como «verificar el derecho a conducir la categoría B en vía pública» o «verificar la elegibilidad de alquiler para una reserva»
- Entorno: la vía pública, el mostrador de alquiler, la precomprobación remota, la incorporación a una flota y la revisión de una reclamación por siniestro son entornos distintos y deben dar lugar a decisiones diferentes
El NIST también señala que los sistemas de atributos necesitan granularidad, gobernanza y mecanismos para la reducción, agrupación y minimización de atributos.
Por tanto, el futuro PIC no debería preguntarse: ¿Puede este verificador leer el permiso? Debería preguntarse: ¿Qué atributos puede recibir este verificador, para qué uso previsto, en este entorno, con qué reglas de retención?
Un Verificador Debe Identificarse Antes de Solicitar Cualquier Cosa
El futuro PIC no debería comenzar con la cartera mostrando datos. Debería comenzar con el verificador demostrando quién es.
La arquitectura EUDI es clara al respecto. Las partes interesadas deben:
- Registrar qué atributos tienen intención de solicitar y con qué finalidad
- Recibir certificados de acceso
- Autenticarse ante la cartera antes de cualquier divulgación
- Ser comprobadas frente a su alcance registrado, cuando la información de registro esté disponible
El usuario puede entonces ver quién solicita, qué se solicita y si la petición está dentro del alcance registrado.
El trabajo actual de ETSI sobre certificados de partes interesadas en carteras digitales concreta esto aún más. Un certificado de registro de parte interesada en la cartera puede describir el uso previsto de esa parte y los atributos que registró para solicitar. El certificado de acceso relacionado existe para garantizar que la solicitud proviene de una parte legítima y autorizada. ETSI también incluye metadatos de la parte interesada tales como:
- Nombre comercial
- URI de soporte
- Uso previsto
- Habilitaciones
- URI del registro
- Información sobre la autoridad supervisora
El segundo principio de un futuro PIC: sin identidad del verificador, no hay divulgación.
Por Qué las Pantallas de Consentimiento No Son Suficientes
Existe otro error: tratar la aprobación del usuario como equivalente a la legitimidad legal.
La arquitectura EUDI establece explícitamente que la aprobación del usuario para presentar atributos no debe considerarse base jurídica para el tratamiento de datos personales por parte de la parte interesada. La parte interesada debe tener su propia base jurídica. EUDI también exige la aprobación del usuario en todos los casos de uso, incluyendo aquellos en los que la parte interesada pueda formar parte de las fuerzas del orden u otro organismo gubernamental.
Una buena interfaz de cartera puede ayudar, pero no puede resolver por sí sola los excesos del verificador. La norma debe existir antes que la interfaz.
Un futuro PIC necesita, por tanto, ambas cosas:
- Autenticación criptográfica del verificador para confirmar quién solicita
- Restricciones de política sobre lo que esa categoría de verificador puede solicitar
Sin ambas, la «elección del usuario» se convierte en una forma de trasladar el fracaso de la política al individuo.
1. Policía: Verificar el Derecho a Conducir, No a la Persona Entera
El escenario de control policial en vía pública es el más enfocado de todos.
El manual de mDL de la UE lo describe directamente: la policía u otros funcionarios comprueban el permiso cuando es requerido, incluyendo la validez del permiso y los derechos sobre el vehículo. En el recorrido del usuario, el agente verifica el permiso a través de un flujo activado por código QR, Bluetooth, Wi-Fi Aware o NFC. Se trata de una tarea de verificación concreta:
- ¿Es esta persona el titular?
- ¿Es válida la credencial?
- ¿Qué derechos sobre vehículos y restricciones son aplicables?
Permitido por defecto:
- Nombre
- Fotografía
- Estado del permiso
- Fechas de expedición y caducidad
- Categorías
- Restricciones relevantes para la conducción
- Emisor y jurisdicción
- Resultado de vigencia/estado
No permitido por defecto:
- Domicilio
- Identificadores internos no necesarios para el uso en vía pública
- Atributos no relacionados procedentes de otras certificaciones
- Registros históricos de presentación
- Metadatos comerciales
La guía de implementación de AAMVA refuerza el punto sobre la fotografía: si se solicita la fotografía y se facilita cualquier otro elemento, la fotografía debe compartirse para que el verificador pueda vincular los datos con la persona que los presenta. La misma guía señala también que las partes interesadas no deben rastrear a los titulares de mDL ni el uso del mDL, salvo cuando lo exija la ley.
El caso policial no consiste en que el Estado reciba todo. Consiste en que el Estado reciba los datos específicos de conducción necesarios para el control en vía pública. Esa es una diferencia importante.
2. Mostradores de Alquiler: Elegibilidad, Verificación de Identidad y Nada Innecesario
El caso del alquiler es más detallado porque hay realmente dos momentos: la precomprobación remota antes de la llegada y la recogida cuando una persona o un quiosco entrega las llaves.
El manual de mDL de la UE ya modela ambos. Un servicio de alquiler de coches puede solicitar el mDL junto con la prueba de identidad durante la reserva, validar las certificaciones y posteriormente verificar al cliente en persona en la recogida antes de entregar el vehículo. Los usuarios pueden compartir sus mDL con las empresas de alquiler de coches tanto en persona como de forma remota con antelación.
Un mostrador de alquiler no necesita principalmente investigar un incidente. Necesita decidir: ¿Puedo alquilar este vehículo a este cliente en el marco de esta reserva y esta política?
La precomprobación remota debe incluir:
- Vinculación de identidad
- Fotografía o elemento equivalente de vinculación de identidad
- Categoría de vehículo pertinente
- Fechas de expedición y caducidad
- Vigencia actual
- Posiblemente un umbral de edad o una franja de edad
La recogida debe confirmar:
- Que el titular es la misma persona que completó la precomprobación
- Vigencia actual
- Habilitaciones pertinentes
No necesario por defecto:
- Domicilio completo cuando el perfil de reserva ya contiene datos de contacto
- Fecha de nacimiento completa cuando una verificación de mayoría de edad o franja de edad es suficiente
- Atributos de identidad no relacionados
- Repetición de la presentación completa de la credencial si ya existe una certificación de reserva
La arquitectura mDL actual del NIST muestra a la parte interesada utilizando DCQL para solicitar únicamente los atributos necesarios, y afirma explícitamente que esto favorece la minimización de datos y el consentimiento del titular al estructurar la solicitud en lugar de tratar la credencial como una unidad única. AAMVA añade que la aplicación debe mostrar claramente qué datos se solicitaron y si el verificador tiene intención de conservarlos.
3. Empleadores: Una Categoría de Verificador, No una Puerta de Entrada a la Identidad Completa
El resumen del W3C utiliza el sistema digital de un empleador que verifica un título universitario como ejemplo de verificador. Eso nos recuerda que la verificación por parte de un empleador es ya un patrón reconocido en los ecosistemas de credenciales.
Un empleador u operador de flota puede legítimamente necesitar saber:
- Si un trabajador está actualmente habilitado para conducir ciertas categorías de vehículos
- Si existen restricciones relevantes
- Si la habilitación sigue siendo válida
Esa es una necesidad empresarial real. Pero no justifica automáticamente el acceso permanente a toda la credencial de conducción, todos los datos de identidad, ni un flujo continuo de presentaciones repetidas.
El NIST advierte que transmitir frecuentemente un identificador reutilizable y habituar a los usuarios a presentar repetidamente una credencial con datos de identidad es indeseable, y señala que la autenticación cotidiana debe basarse en tecnologías diseñadas para la autenticación, como las claves de acceso. El NIST prefiere la autenticación local en el dispositivo frente a la verificación biométrica en el servidor porque preserva mejor la privacidad.
Un futuro PIC no debe convertirse en una tarjeta de acceso al puesto de trabajo.
Para el uso por parte de empleadores y flotas, el patrón correcto suele ser:
- Una comprobación de habilitación relevante para el puesto
- Quizás una certificación periódica de cumplimiento
- Quizás una declaración de que el titular sigue siendo válido para las categorías especificadas
- Pero no una transferencia por defecto de todos los datos del permiso cada vez que el empleado inicia sesión en un sistema o comienza un turno
El cumplimiento en flotas es una categoría de parte interesada separada, con un uso previsto separado y un perfil de divulgación separado.
4. Aseguradoras: Las Reclamaciones No Son Permiso para una Visibilidad Continua
El caso de los seguros es frecuentemente real. En el material de casos de uso de mDL de la UE, las aseguradoras aparecen indirectamente en el escenario de alquiler: las compañías de seguros exigen a las empresas de alquiler de coches que comprueben si la persona que alquila el vehículo tiene derecho a conducirlo. Los seguros ya influyen en el flujo de verificación de la conducción.
Pero eso no significa que una aseguradora deba recibir los mismos datos que la policía, ni un derecho permanente de acceso a la credencial.
Un futuro PIC debería tratar a las aseguradoras como una categoría de verificador separada con usos previstos separados:
- Suscripción
- Verificación del riesgo en el alquiler
- Gestión de reclamaciones por siniestro
- Revisión de fraude
Esos no son la misma finalidad. Conforme a los principios de protección de datos de la UE, los datos personales deben recogerse con finalidades específicas y limitarse a lo necesario y proporcionado para esa finalidad. La orientación sobre VC del W3C llega a la misma conclusión técnicamente: los verificadores deben solicitar únicamente lo estrictamente necesario.
Ejemplos legítimos y específicos de cada evento:
- Prueba de que el permiso era válido en el momento pertinente
- Prueba de la habilitación pertinente sobre el vehículo
- Prueba de vinculación de identidad cuando sea necesario para una reclamación
- Divulgación específica para la reclamación
No permitido por defecto:
- Acceso persistente a la credencial subyacente
- Verificación genérica repetida cada vez que el cliente interactúa con la aseguradora
- Uso de la credencial de conducción como token de inicio de sesión
- Recopilación de atributos no relacionados
Una credencial de conducción no es una suscripción de seguimiento. Y no debería convertirse en una de forma silenciosa.
Por Qué los Intermediarios Deben Ser Visibles
Los mercados reales involucran intermediarios. Las plataformas de alquiler, los proveedores de flotas, los sistemas de recursos humanos de los empleadores y los gestores de reclamaciones de seguros actúan a menudo a través de terceros.
La arquitectura EUDI aborda esto mediante:
- Tratar a los intermediarios como partes interesadas
- Exigirles que se registren
- Exigir que los atributos solicitados en nombre de la parte interesada final estén registrados
- Mostrar al usuario tanto al intermediario como a la parte interesada final
- Prohibir a los intermediarios almacenar datos sobre el contenido de la transacción
Un futuro PIC nunca debería permitir un patrón en el que el usuario crea que está divulgando a la empresa de alquiler, pero en realidad está divulgando a una cadena invisible compuesta por un bróker de verificación, un procesador de análisis y un proveedor de reclamaciones.
ETSI ayuda en este punto. Su modelo de certificados de partes interesadas en carteras digitales incluye URIs de soporte, uso previsto, URIs de registro y metadatos de la autoridad supervisora. Esa es la infraestructura legible por máquina que los usuarios necesitan para comprender quién está realmente al otro lado de la solicitud y a dónde acudir cuando deseen la supresión o corrección de sus datos.
La Retención Es Parte del Control de Acceso
La mayoría de los debates sobre la divulgación selectiva terminan demasiado pronto. Se centran en lo que se divulga. No se centran suficientemente en cuánto tiempo permanece después.
La orientación actual ya está convergiendo:
- AAMVA: la cartera debe informar claramente al titular qué datos se solicitaron y si el verificador tiene intención de conservarlos; las partes interesadas no deben rastrear a los titulares ni el uso del mDL, salvo cuando lo exija la ley
- W3C: el software del titular debe proporcionar registros de la información compartida con los verificadores, para que puedan identificarse las solicitudes excesivas
- EUDI: los usuarios deben poder acceder a los registros de transacciones, notificar solicitudes sospechosas y solicitar la supresión
La clase de retención debe formar parte de la propia política de divulgación:
- Control policial en vía pública: sin retención por defecto más allá del registro operativo legalmente previsto
- Precomprobación de alquiler: registro de transacción vinculado a la reserva, no una copia de identidad reutilizable
- Cumplimiento de flota del empleador: registro de cumplimiento o resultado de la certificación, no datos brutos de la credencial
- Reclamación de la aseguradora: registro de la reclamación limitado a la reclamación, no acceso permanente
Un futuro PIC que ignore la retención solo preserva parcialmente la privacidad.
Lo Que la Cartera Realmente Debe Decidir
Si tuviera que reducir todo este artículo a una sola regla de implementación, sería esta:
La cartera no debe responder a «¿Puedo presentar esta credencial?» Debe responder a «¿Puedo presentar este conjunto de atributos a este verificador autenticado, para este uso previsto, en este contexto, bajo esta clase de retención?»
Esa decisión debe basarse al menos en estas entradas:
- Identidad del verificador
- Categoría del verificador
- Uso previsto
- Alcance de atributos registrado
- Política de divulgación del emisor, si existe
- Entorno (vía pública, recogida, remoto, flota, reclamación)
- Aprobación del titular
- Política de retención aplicable
Los estándares ya contienen gran parte de la maquinaria para esto: divulgación selectiva, autenticación de la parte interesada, uso previsto registrado, certificados de acceso, evaluación de la política de divulgación y solicitudes vinculadas a una finalidad. Lo que aún falta es la disciplina para tratar todas esas piezas como una arquitectura de divulgación coherente.
El Argumento Central
El futuro PIC no debería preguntarse si los datos pueden divulgarse. Debería preguntarse:
- ¿Quién solicita?
- ¿Con qué finalidad?
- ¿Bajo qué autoridad?
- ¿En qué contexto?
- ¿Con qué consecuencias en materia de retención?
La policía, los mostradores de alquiler, los empleadores y las aseguradoras no son cuatro logotipos al otro extremo de una solicitud. Son cuatro modelos de riesgo diferentes, cuatro contextos jurídicos diferentes, cuatro razones diferentes para preguntar, y deberían producir cuatro conjuntos de divulgación diferentes.
Eso no es complejidad innecesaria. Así es como se ve una credencial de conducción moderna cuando deja de tratar a todos los verificadores como si fueran el mismo verificador.
Publicado Abril 27, 2026 • 14m para leer
