Quién queda realmente registrado en la EU Digital Identity Wallet

La afirmación que circula

Hay un formato de post que está funcionando bien en redes ahora mismo. Viene a decir esto: un estado miembro activa su cartera de identidad digital, guarda el carné de conducir y la tarjeta sanitaria, se presenta como una comodidad — pero por debajo instala una credencial única emitida por el Estado que registra cada vez que un ciudadano demuestra quién es.

Las partes fácticas son reales. Los estados miembro están desplegando carteras. Contienen credenciales de identidad. Las plataformas privadas podrán conectarse.

La conclusión no lo es. Y la forma de comprobarlo no es fiarse de mí ni fiarse de la Comisión: es leer el Architecture and Reference Framework, la especificación técnica pública que define qué deben hacer estas carteras. Está publicada en eudi.dev, versionada en GitHub, y es legible.

Llevo dos años siguiendo de cerca su evolución. Aquí van cuatro cosas que no encajan con la narrativa.

1. El registro existe. Es tuyo.

El ARF exige que toda EUDI Wallet incluya un panel de privacidad: una vista integrada que da al usuario un resumen de todos los datos intercambiados con cada proveedor de servicios con el que ha interactuado.

Así que la afirmación de que "cada uso queda registrado" es, en sentido estricto, correcta. Hay un registro. Lo que la afirmación se equivoca es en quién lo tiene. El panel es una función de transparencia de cara al usuario, en el dispositivo del usuario. Existe para que tú puedas auditar quién te pidió qué — no para que nadie pueda auditarte a ti.

Esto se acerca bastante a invertir la lectura de vigilancia. La respuesta de la especificación a "¿cómo evitamos que esto sea opaco?" fue exigir que el usuario se quede con el libro de cuentas.

Y va más allá de "el Estado no lo ve". El requisito WIAM_12a establece que la Wallet Unit debe garantizar que el Wallet Provider — el organismo que te emitió la cartera, normalmente una entidad del estado miembro — no puede acceder al contenido de la Wallet Unit: ni qué attestations tienes, ni su estado, ni el valor de sus atributos, ni el contenido de ese log. La organización que te dio la app está explícitamente diseñada fuera de poder ver qué haces con ella.

2. El emisor no está en el circuito cuando presentas

Este es el punto técnico que sostiene todo lo demás, y el que casi todos los posts se saltan por completo.

Bajo el ARF, la presentación ocurre directamente entre la cartera de tu dispositivo y la parte que te pide los datos. Para flujos remotos la cartera habla OpenID for Verifiable Presentations, combinado con la W3C Digital Credentials API. Para flujos presenciales usa ISO/IEC 18013-5 sobre NFC, Bluetooth Low Energy o Wi-Fi Aware — que funciona sin ninguna conexión a internet.

En ninguno de esos flujos recibe notificación la autoridad emisora. No hay llamada a casa. La credencial se firmó cuando se emitió; el verificador comprueba esa firma contra una lista de confianza pública. El gobierno que emitió tu credencial no se entera de que la usaste, ni cuándo, ni dónde.

La documentación de AltID lo dice sin rodeos para su propia implementación: el emisor no puede saber que la credencial se está usando ni dónde se usa. Eso no es una decisión de diseño danesa — es lo que exige la arquitectura subyacente.

La pregunta obvia que sigue es: vale, el emisor no — ¿y el sistema operativo? Para los flujos de QR y proximidad, tampoco está en el camino. La cartera pinta el código, la respuesta va al verificador, y la proximidad funciona sin red alguna. El flujo nativo del navegador es otra historia, y es la objeción más fuerte que se le hace a esta arquitectura. Vuelvo a ella más abajo.

3. Quien tiene que registrarse es la empresa, no tú

Este es el detalle que da la vuelta al marco de forma más limpia, y casi nadie que cubre este tema lo menciona.

El ecosistema EUDI sí incluye un régimen de registro. Se aplica a las relying parties — las plataformas y servicios que quieren pedirte atributos. Se registran en su estado miembro, declaran qué datos concretos pretenden solicitar, bajo qué base legal y con qué finalidad. Esa declaración queda ligada a un certificado que la cartera comprueba en el momento de la presentación.

En la práctica: cuando un servicio te pide datos, tu cartera puede verificar que quien pregunta es quien dice ser y que está autorizado a pedir ese atributo concreto. Un servicio que se registró para pedir age_over_18 y luego intenta pedir tu dirección no tiene una vía técnica para hacerlo.

El sistema que supuestamente registra a los ciudadanos es, en la capa de registro, un sistema que registra empresas y limita lo que se les permite preguntar.

4. La no-vinculabilidad es un requisito de construcción, no una promesa

El ARF trata la no-vinculabilidad (unlinkability) como una propiedad de diseño que la arquitectura tiene que entregar: dos relying parties distintas no deben poder correlacionar sus interacciones contigo, y el emisor no debe poder rastrear por dónde viaja una credencial.

Eso tiene consecuencias concretas en código real. AltID, el primer emisor de verificación de edad en la Trusted List de producción de la UE, emite su credencial de edad en lotes de 30 attestations de un solo uso — mismos atributos, distintos metadatos. Cada presentación quema una. Dos verificadores nunca reciben el mismo artefacto, así que no hay identificador común por el que cruzar. Cuando el lote se agota, se genera otro automáticamente.

Eso es coste de ingeniería — gestión de claves, refresco de lotes, almacenamiento — gastado en una propiedad que no tiene ningún beneficio visible para el usuario salvo que no se le pueda seguir el rastro. Eso no se construye por accidente.

Tampoco es toda la historia. Más abajo vuelvo a lo que los lotes no resuelven.

La verificación de edad es el ejemplo más nítido

El EU Age Verification Blueprint, construido sobre los mismos cimientos, existe específicamente para romper el vínculo entre demostrar tu edad y revelar tu identidad.

La relying party recibe un booleano: superas el umbral solicitado, sí o no. No tu nombre, no tu fecha de nacimiento, no un número de documento, no un identificador persistente. La credencial de AltID lleva nueve umbrales — 13, 15, 16, 18, 21, 23, 25, 27, 67 — y el verificador solicita exactamente uno. Una plataforma que comprueba age_over_18 nunca sabe si además superas los 21.

Esto lo impulsa directamente la ley, no la buena voluntad. El Artículo 28(3) de la DSA establece que las plataformas no están obligadas a procesar datos personales adicionales únicamente para determinar si un usuario es menor. El diseño técnico tenía que satisfacer esa restricción.

Lo que sí merece preocupación

Nada de esto significa que no haya preguntas legítimas. Las hay — y las mejores llegaron en los comentarios de mi artículo anterior, de gente que lleva en esto bastante más tiempo que yo. Tampoco son las que se viralizan, que es justamente el problema.

Parte de lo que sigue queda fuera de lo que este artículo se proponía hacer. Esto empezó como una mirada a una decisión de diseño concreta — qué exige la especificación a carteras y verificadores — y varias de estas objeciones operan en un nivel completamente distinto. Las incluyo igualmente, porque ignorar una buena objeción es peor que responderla a medias. Pero son temas con entidad propia, y no los voy a cerrar aquí.

El entorno de ejecución. La objeción más afilada a esta arquitectura no tiene nada que ver con emisores, verificadores ni listas de confianza. Tiene que ver con el dispositivo — y merece separarse con cuidado de una cuestión vecina con la que se confunde constantemente.

La criptografía protege los datos en tránsito y en reposo. No protege los datos del entorno que la ejecuta. El componente de una cartera que preserva la privacidad recibe datos sensibles y los transforma en algo seguro de compartir — pero la app que hace esa transformación se ejecuta dentro de un sistema operativo que no controla. Si ese entorno puede observar la entrada antes de la transformación, la transformación te protege del verificador, no del entorno. Denis Roio lleva tiempo defendiendo este argumento en público: se sostiene incluso con pruebas de conocimiento cero, porque el sistema operativo ve los datos que entran. El aislamiento de procesos para el componente que preserva la privacidad no es un extra deseable. Es la precondición para que la garantía signifique algo.

Esto no va de dónde viven las claves privadas — el almacenamiento de claves es otro problema, con otras respuestas. Va del proceso: la memoria de la app, su pantalla y su E/S pertenecen al sistema operativo, sea cual sea el hardware que guarda las claves.

Esa objeción se sostiene. No creo que tenga una buena respuesta hoy.

Dos matices honestos, eso sí. Primero: nada de esto es específico de EUDI. Tu app del banco, tu 2FA, tu gestor de contraseñas y tu correo funcionan hoy bajo el mismo modelo de confianza. Eso no hace que la objeción sea falsa — hace que sea una objeción a la computación móvil que EUDI hereda en lugar de inventar. Segundo: "el sistema operativo podría correlacionar telemetría con presentaciones" es una afirmación sobre capacidad, no sobre comportamiento observado. Pero el argumento no necesita que Google lo esté haciendo hoy. Necesita que la arquitectura no lo impida — y no lo impide. Si tu modelo de privacidad depende de que un fabricante decida no mirar, eso no es un modelo de privacidad. Es un acuerdo de confianza.

Hay una posición que lleva esto hasta el final: si el silicio pertenece a Apple, Google o Qualcomm, la pila está comprometida de raíz y ninguna criptografía por encima puede arreglarlo. Es coherente. Pero su conclusión no es "arregla el marco" — es "espera a un dispositivo que todavía no existe". No creo que sea falsa; creo que es otra pregunta: no "¿es sólido este despliegue?" sino "¿deberíamos estar haciendo nada de esto sobre hardware que no controlamos?". Esa es una pregunta real. Simplemente no es una sobre la que pueda actuar una plataforma con una fecha límite de cumplimiento en diciembre.

La dependencia de la attestation. Un problema distinto, que se confunde rutinariamente con el anterior — y, a diferencia del anterior, este sí lo responde el marco. Para que una cartera demuestre que es la app genuina, sin modificar, corriendo en un dispositivo que no ha sido manipulado, necesita alguna forma de atestación de integridad. El camino de menor resistencia es la Play Integrity API de Google o el equivalente de Apple, y Países Bajos e Italia usan Play Integrity de forma incondicional. Suiza la descartó, alegando protección de datos, soberanía de los datos y libertad de elección. Usuarios de distribuciones Android sin servicios de Google, como GrapheneOS o /e/OS, pueden quedarse fuera de una infraestructura pública.

El marco exige la propiedad — que una cartera pueda demostrar su propia integridad — pero no prescribe el mecanismo. Los estados miembro son libres de construir carteras sin ninguna dependencia de servicios de plataformas estadounidenses. Play Integrity es un servicio de Google que necesita Play Services y una cuenta de Google; es la forma más fácil de obtener la propiedad, no la obligatoria. Suiza es la prueba de que la alternativa se puede desplegar.

Así que la dependencia no está en el marco. Está en una decisión de implementación — y es una crítica a despliegues reales medida contra los objetivos que el propio marco declara. También se está haciendo dentro del proceso: hay una discusión abierta titulada, literalmente, "Do not add Google Play Integrity integration" en el repositorio de la especificación de verificación de edad.

El flujo nativo del navegador entrega metadatos al sistema operativo. Cuando una cartera se registra en el Credential Manager de Android, entrega al sistema un blob con los datos de la credencial y un matcher WASM que el sistema ejecuta en un sandbox contra cada petición entrante. El sandbox protege la lógica de matching. El sistema sigue sabiendo qué carteras hay registradas, qué origin ha preguntado, cuándo, y qué cartera eligió el usuario — necesita esto último para enrutar la petición. No el contenido de la presentación. Pero sí el grafo de metadatos a su alrededor.

Dos cosas lo acotan. Solo aplica al flujo nativo del navegador: el QR y la proximidad dejan al sistema operativo fuera, y AltID no soporta la Digital Credentials API en absoluto. Y el ARF trata esta API como condicional — el Topic F establece expectativas explícitas de privacidad y afirma que, si no se cumplen, el soporte no será obligatorio. La AEPD presentó comentarios exactamente sobre esto, preguntando por neutralidad tecnológica, resiliencia y soberanía digital, dado que el soporte venía únicamente de Chrome y Android. La misma agencia escribió a los editores del ARF sobre el Topic T, advirtiendo de que las funciones de mantenimiento y soporte del wallet provider podían habilitar seguimiento y vigilancia; los editores respondieron punto por punto y modificaron el documento. Así es como se ve el escrutinio cuando funciona: un regulador, por escrito, en un repositorio público, antes del despliegue.

Linkabilidad a nivel de red. Los lotes de credenciales de un solo uso dan no-vinculabilidad en la capa de la credencial — dos verificadores nunca ven el mismo artefacto, así que no hay identificador común por el que cruzar. Esa parte es real. Pero en un flujo OID4VP remoto tu dispositivo hace una petición HTTPS. El verificador ve una dirección IP, una huella TLS, una ventana temporal. Si dos verificadores comparten infraestructura publicitaria — o si simplemente es el mismo verificador viéndote dos veces — la no-vinculabilidad de la capa de credencial no borra la linkabilidad de la capa de red.

Esto no es un defecto del diseño de la credencial. Es un límite de lo que el diseño de credenciales puede hacer. La no-vinculabilidad en la capa de protocolo es necesaria y no suficiente, y una respuesta seria implica la pila de red, que ninguna implementación tiene ahora mismo. Los flujos de proximidad lo esquivan por completo — sin red, sin problema — que es una razón por la que el mecanismo de QR firmado offline de AltID es más interesante de lo que parece a primera vista.

Este es un asunto con entidad propia, y no es específico de EUDI ni de la verificación de edad: es una propiedad de cualquier sistema de credenciales que hable por una red. Morten Larsen lo planteó en mi artículo anterior mejor de lo que yo lo había planteado, tras revisar el código fuente publicado de AltID. Merece un tratamiento en condiciones y no lo va a tener aquí. Aun así está en la lista, porque un diseño que acierta en la capa de la credencial y se detiene ahí no ha terminado el trabajo.

Scope creep — y yo formo parte de él. Esta es la preocupación que hay debajo de los posts virales. La rozan sin llegar a articularla, pero es real. Nada de lo anterior te dice para qué servirá la cartera en 2030. Un sistema construido por conveniencia administrativa, una vez que todo el mundo tiene uno y todos los servicios lo aceptan, genera presión para ampliarse. Esa ampliación es una decisión política que se tomará después, en otro debate, por otra gente — y la elegancia técnica del diseño de la credencial no influye en ella lo más mínimo.

No hace falta especular. La verificación de edad es scope creep ocurriendo en tiempo real. Hace tres años la EUDI Wallet se presentaba como una forma de hacer la declaración y llevar el carné de conducir. Hoy se discute como una puerta de acceso a internet, y yo dirijo una empresa que vende esa puerta. Denis Roio ha argumentado que convertir la protección de la infancia en control de acceso a internet es un mal intercambio, por bien que funcione la criptografía. Ese argumento no se vuelve falso porque el diseño de la credencial haya resultado ser bueno. Son preguntas distintas.

La respuesta técnica a "¿se puede hacer esto sin vigilancia?" es sí. Eso no es una respuesta a "¿debería hacerse esto?" — y prefiero que esa segunda pregunta siga abierta a ver cómo mi propio sector la responde por defecto.

Todas las objeciones anteriores sobreviven al contacto con la especificación. "Registra todos los sitios por los que pasas" no — y el ruido que genera desplaza a las que sí mejorarían el sistema.

Cómo leer el próximo post de estos

Una pregunta separa los posts que merecen atención de los que no: ¿distingue entre lo que exige la especificación y lo que podría hacer un despliegue concreto?

Un post que dice "este despliegue concreto hace X, que el ARF no exige, y aquí está la evidencia" está haciendo algo útil. Un post que dice "identidad digital significa vigilancia" se ha saltado el paso de comprobarlo.

El ARF es público. El Age Verification Blueprint tiene un portal técnico. Las implementaciones de referencia son open source en GitHub. Nada de esto exige fiarse del resumen de nadie — incluido este.

---

Las afirmaciones técnicas de este artículo se basan en el Architecture and Reference Framework de la EU Digital Identity Wallet (publicado en eudi.dev), la especificación técnica del EU Age Verification Blueprint, y "Om AltID" v1.4 (mayo 2026), publicado por Digitaliseringsstyrelsen.