La cartera europea de identidad digital es un elemento central de esta iniciativa, una herramienta fácil de usar en forma de aplicación móvil diseñada para almacenar, gestionar y presentar credenciales digitales. Al integrar esta cartera con servicios públicos y privados, la UE busca empoderar a la ciudadanía con una identificación y autenticación más seguras, y con un mayor control sobre sus datos personales. El alineamiento de la iniciativa con los principios y requisitos del RGPD es esencial para fomentar la confianza en el nuevo enfoque y, en términos generales, en las transacciones digitales.
El considerando 7 del RGPD establece que “Las personas físicas deben tener el control de sus propios datos personales”. La identidad es el aspecto más importante que define los datos personales (artículo 4(1) del RGPD) y es un derecho fundamental como queda recogido en el artículo 6 de la Declaración Universal de los Derechos Humanos que establece que "Todo ser humano tiene derecho, en todas partes, al reconocimiento de su personalidad jurídica". Además, la identidad está garantizada en España en la Ley Orgánica de Protección de la Seguridad Ciudadana
.
La transformación digital de Europa se está acelerando, y en el centro de esta transformación se encuentra la necesidad de una identificación electrónica pública y segura, que incluya la firma digital interoperable, para proporcionar a las personas control sobre su identidad y sus datos en línea, así como para permitir el acceso a los servicios digitales públicos, privados y transfronterizos.
La Unión Europea (UE) ha estado a la vanguardia de este movimiento con la introducción del Reglamento eIDAS en 2014 (Reglamento UE n.º 910/2014), que estableció un marco para la identificación electrónica y los servicios de confianza. Sin embargo, a medida que la tecnología y las necesidades de los ciudadanos han evolucionado, también lo ha hecho el panorama regulatorio. Esto ha llevado al desarrollo de eIDAS2 .
El Reglamento (UE) 2024/1183 de Parlamento Europeo y del Consejo de 11 de abril de 2024 por el que se modifica el Reglamento (UE) n.o 910/2014 en lo que respecta al establecimiento del marco europeo de identidad digital (eIDAS2), entró en vigor el 20 de mayo de 2024 como una actualización significativa del reglamento eIDAS original. El objetivo principal de eIDAS2 es mejorar la seguridad, la usabilidad y la interoperabilidad de los servicios de identificación electrónica y confianza en toda la UE. Este reglamento actualizado tiene por objeto abordar las limitaciones del marco original mediante la introducción de un sistema de identificación digital fiable y fácil de usar. Una de las características más importantes de eIDAS2 es la aceptación obligatoria de los medios de identificación electrónica emitidos en un Estado miembro por todos los demás Estados miembros, fomentando así una mayor interacción digital transfronteriza.
La European Digital Identity (EUDI) Wallet (la cartera europea de identidad digital) es una piedra angular del marco eIDAS2. Esta cartera digital permitirá a los ciudadanos, residentes y empresas de la UE almacenar y administrar de forma segura sus identidades digitales (en forma de credenciales o declaraciones electrónicas de atributos, electronic attestations of attributes). La cartera permitirá a los usuarios autenticar su identidad, almacenar credenciales digitales y acceder fácilmente a una amplia gama de proveedores de servicios (Relying Parties), basándose en una aplicación móvil. Cada Estado miembro proporcionará, al menos, una versión de la cartera para finales de 2026, lo que garantizará la interoperabilidad y una experiencia de usuario coherente en toda la UE.
La cartera está diseñada para preservar la privacidad, dando a los usuarios control sobre sus datos personales y asegurando que sólo se comparta la información necesaria en cada transacción. Se pretende que la cartera sea adecuada para transacciones tanto con el sector público como con el privado, y su uso será voluntario y gratuito para los ciudadanos.
El Architecture and Reference Framework (ARF) es un componente fundamental en el desarrollo y la implementación de la cartera digital. El ARF proporciona un conjunto de normas comunes, especificaciones técnicas y mejores prácticas que los Estados miembros deben seguir para garantizar la interoperabilidad y la seguridad de las soluciones de identidad digital. Al adherirse al ARF, los Estados miembros pueden desarrollar soluciones de cartera que sean compatibles entre sí, lo que facilita las interacciones digitales transfronterizas sin fricciones. El ARF está diseñado para ser flexible y adaptable, lo que permite futuros avances e innovaciones tecnológicas. El actual es la versión 1.4.1, aunque se espera al menos una actualización este año.
Para garantizar el éxito de la implementación de eIDAS2 y de la cartera digital, la Comisión Europea adoptará una serie de reglamentos de ejecución (Implementing Acts). El primer lote de ellos se ha aprobado en noviembre de 2024. Estos reglamentos proporcionan normas y directrices detalladas sobre diversos aspectos de la regulación, incluidas las especificaciones técnicas, los requisitos de seguridad y las normas de interoperabilidad. Los reglamentos de ejecución son esenciales para traducir los objetivos de alto nivel del eIDAS2 en medidas prácticas y viables. El contenido del ARF ha servido de base para el contenido de los reglamentos de ejecución que se adoptarán y serán de obligado cumplimiento para todos los Estados miembros.
La interacción entre el Reglamento eIDAS2 y el Reglamento General de Protección de Datos (RGPD) también debería ser crucial para garantizar reglamentos de ejecución que preserven la privacidad y permitan a los interesados el control real sobre sus propios datos personales.
eIDAS2 está diseñado para alinearse estrechamente con el RGPD. Esto garantiza que el tratamiento de datos personales en el contexto de la identificación electrónica y los servicios de confianza se adhiera a los principios y requisitos establecidos por el RGPD, como la transparencia, la minimización de datos, la limitación de la finalidad o los derechos de los interesados.
El Reglamento eIDAS2 exige a proveedores de servicios como partes usuarias (Relying Parties) que realicen evaluaciones de impacto relativas a la protección de datos (EIPD) y consulten a las autoridades de protección de datos competentes antes del tratamiento de datos cuando las EIPD indiquen que el tratamiento daría lugar a un alto riesgo (considerando 17).
El reglamento eIDAS2 también exige que los usuarios sean capaces de efectuar un seguimiento de todas las transacciones ejecutadas a través de la cartera con al menos los siguientes datos: la hora y la fecha de la transacción, la identificación de la contraparte, los datos personales solicitados y los datos compartidos (considerando 13). El Reglamento exige que la cartera permita el control total de los usuarios sobre sus datos, la divulgación selectiva de datos, el uso de seudónimos, el uso de políticas de divulgación integradas y el registro de todas las transacciones (artículos 5a.4 y 5a.5).
En lo que respecta al control total de sus datos, el Reglamento eIDAS2 exige que la cartera proporcione un panel común que permita al usuario ver una lista actualizada de los proveedores de servicios con los que ha establecido una conexión y, en su caso, todos los datos intercambiados; solicitar fácilmente a uno de estos proveedores que suprima los datos personales en virtud del artículo 17 del RGPD y notificar a la autoridad nacional de protección de datos en los casos en los que se reciba de un proveedor de servicios una solicitud de datos presuntamente ilícita o sospechosa (artículo 5 bis, apartado 4).
El reglamento eIDAS2 exige que los datos personales relacionados con la provisión de la cartera digital se mantengan separados lógicamente de cualquier otro dato que obre en poder del proveedor de la cartera (artículo 5a.14).
El reglamento eIDAS2 exige que la cartera no facilite información alguna a los prestadores de servicios de confianza de declaraciones electrónicas de atributos (a los proveedores que emiten distintos tipos de credenciales) sobre el uso de dichas declaraciones electrónicas (artículo 5a.5). Además, este Reglamento exige propiedades de no-vinculación (considerando 14, artículo 5 bis, 16) y mecanismos de revocación tanto para la cartera como para las credenciales (artículos 5 bis, 13, 45 quinquies y 45 septies).
Existe un alto consenso entre toda la comunidad (autoridades, investigadores y profesionales) en que la versión actual del ARF todavía tiene importantes lagunas en relación con la garantía de todos estos requisitos establecidos por la normativa. Las autoridades de protección de datos deben estar atentas para confirmar que las medidas enumeradas en los párrafos anteriores se incluyan en los reglamentos de ejecución y en la actualización del ARF, y que todo esto permita el desarrollo, e incluso la certificación, de productos de cartera que cumplan con el RGPD.
Las amenazas de vinculación contra las carteras de identidad digital
Las diferentes amenazas de vinculación contra las carteras de identidad digital, lo que implicaría incumplir el requisito de no vinculación (unlinkability) que recoge eIDAS2. Esto se debe principalmente al uso de identificadores únicos (firmas) y a los mecanismos de revocación de credenciales obligatorios.
El reglamento eIDAS2 tiene como objetivo garantizar la protección de datos y la privacidad cuando se usen las carteras de identidad digital de la UE. Aun así, el nuevo escenario plantea una serie de cuestiones, tales como:
- Si uso mi cartera cuando compro productos o accedo a servicios privados o públicos, ¿el emisor de la credencial (gubernamental o privado) puede obtener información sobre mis actividades? ¿Incluso en tiempo real?
- Si uso mi cartera para revelar de forma anónima que soy estudiante, con edad suficiente para acceder a servicios para adultos, miembro de una asociación o cualquier otra condición, ¿es posible rastrear mi actividad porque todos mis accesos se pueden vincular? Y, por lo tanto, ¿es posible vigilarme o perfilarme? ¿Quién podría hacerlo?
eIDAS obliga a garantizar la propiedad de no vinculación, de manera que sea imposible asociar diferentes datos o acciones a un sujeto de datos específico. Esta propiedad es crucial porque impide el seguimiento y la correlación de las actividades del interesado, evitando la elaboración de perfiles y la vigilancia, incluso cuando se producen brechas de datos o diferentes partes involucradas en el tratamiento de datos personales colaboran entre ellas.
El Architecture and Reference Framework (ARF) es el conjunto de normas comunes, especificaciones técnicas y mejores prácticas, que los Estados miembros deben seguir para implementar las carteras. La falta de un enfoque global para la propiedad de no vinculación en este ARF resulta preocupante. A pesar del mandato de eIDAS2 en cuanto a la utilización de técnicas que preserven la privacidad, la situación actual es que no tenemos detalles sobre cómo se logrará técnicamente la no vinculación, lo que deja espacio para implementaciones que podrían no proteger adecuadamente los datos personales de los usuarios. Sin embargo, el ARF aún está en desarrollo, para completarlo se están discutiendo 23 puntos diferentes (denominados temas) hasta finales de 2025. Bastantes de ellos abordan este problema.
La respuesta a la primera pregunta antes planteada depende de las decisiones que se tomen en la versión definitiva del ARF y de cómo (y hasta qué nivel) garantice la no vinculación con respecto a los emisores de credenciales. Estos emisores no deben ser capaces de saber o aprender nada sobre cuándo, dónde y a qué proveedores de servicios, como partes usuarias (Relying Parties o RPs), un interesado presenta sus credenciales mediante la cartera. A esto a menudo se le llama inobservabilidad (unobservability). Supongamos que el emisor de una credencial de mayoría de edad almacena todos los valores de elementos únicos (salts, hashes, clave pública, valor de firmas) de todas las credenciales emitidas. Si una o más RP comparten con el emisor el valor de cualquiera de los elementos únicos de una credencial que han recibido (aunque sea de manera indirecta, por ejemplo, a través del mecanismo de revocación), el emisor puede vincular la transacción al sujeto de datos correspondiente, rastrear en qué RP ha presentado sus credenciales (sitios web para adultos, plataformas de apuestas, tiendas de alcohol, etc.) y construir un perfil de sus hábitos. Esto es justo lo que se debe evitar.
La respuesta a la segunda pregunta depende de nuevo del ARF y de si garantiza la no vinculación con respecto a las RP (proveedores de servicios) en diferentes presentaciones. Supongamos que el usuario presenta una credencial a una RP en diferentes sesiones o transacciones. En ese caso, la RP no debería ser capaz de saber o aprender (mediante datos o información adicionales como metadatos, datos no revelados explícitamente por el usuario o conjuntos de datos adicionales) que estas transacciones corresponden al mismo usuario. Además, si el usuario presenta una misma credencial en diferentes RP, no deberían poder saber o aprender que todas estas transacciones corresponden al mismo usuario. A esto a menudo se le llama no vinculación multi-presentación (multi-show unlikability). Supongamos que un usuario desea participar en un programa de descuentos o fidelidad empleando para ello su cartera. Los valores de elementos únicos de dicho usuario pueden permitir a todas las partes que participan en ese programa vincular todas las transacciones con el interesado, que puede estar sujeto a un perfilado de su comportamiento o a precios diferenciados. De nuevo, esto es algo que se debe evitar.
Además, en este caso hay que tener en cuenta una propiedad de no vinculación diferente cuando las RP y los emisores de credenciales cooperan, comparten información, o un tercero logra comprometer a ambas partes (por ejemplo, en el caso de una brecha de datos en la RP y el emisor). En este caso, el emisor que proporcione credenciales al usuario no debe poder saber ni aprender nada sobre el usuario a partir de la información obtenida de la RP. Y al contrario. Esto a menudo se denomina no vinculación total (full unlikability) o falta de trazabilidad, ya que implica que los emisores de credenciales y las RP no tienen posibilidad de rastrear el uso de las credenciales de un usuario y sus transacciones. Si volvemos al ejemplo de la credencial de mayoría de edad, una o más RPs podrían colaborar con el emisor de credenciales, cruzar información y vincular transacciones a sujetos de datos específicos para construir perfiles. O ambas partes podrían sufrir una brecha de datos y cualquier persona con acceso a su información podría combinarla y construir esos mismos perfiles.
Como se ha observado en los ejemplos, en general, una amenaza de vinculación puede materializarse directamente a través de identificadores únicos o indirectamente mediante la combinación de diferentes datos sobre el interesado o la elaboración de perfiles de su comportamiento.
El reglamento eIDAS2 promueve la propiedad de no vinculación. Sin embargo, el ARF actual propone el uso de los formatos ISO mDL (Mobile Driver's License) y SD-JWT (Selective Disclosure JSON Web Token) para las credenciales, que podrían no ser suficiente para garantizar esta propiedad porque se basan en firmas para su validación.
Estas firmas son identificadores únicos que permiten reconocer la firma de un interesado en concreto en múltiples presentaciones, incluso si sólo se revela información contenida en las credenciales de manera selectiva. Si un emisor de credenciales emite un carné de conducir digital que contiene atributos como el nombre, la fecha de nacimiento y la dirección, las RP y el emisor de credenciales con la ayuda de estas, podrían rastrear las presentaciones del sujeto de datos de este carné en la misma RP y en diferentes RP a través de la firma, incluso si el usuario solo revela su edad o dirección cada vez. En este caso no es posible garantizar las propiedades de multi-show unlikability o full unlikability. Lo mismo ocurriría con otros posibles identificadores únicos persistentes, explícitos o implícitos (dentro de los metadatos, por ejemplo, las direcciones IP).
Un ejemplo diferente, que ya se ha adelantado, implicaría materializar la amenaza de vinculación aprovechando los mecanismos de revocación obligatorios para las credenciales según eIDAS2. Si el mecanismo de revocación requiere que la RP se ponga en contacto con el emisor de credenciales o con una autoridad central para comprobar la validez de una credencial, esta interacción podría facilitar el seguimiento. La RP podría inferir que varias presentaciones con el mismo estado de revocación o marca de tiempo, se originaron en el mismo sujeto de datos, incluso si los atributos divulgados son diferentes en cada presentación. Por otro lado, los mecanismos de revocación que involucran al emisor de la credencial en el proceso de validación también pueden ser un problema desde su punto de vista. Incluso si el emisor solo se entera del estado de revocación y no de los atributos específicos que se presentan, se puede rastrear el hecho de que el sujeto de datos interactúe con la RP en un momento y lugar determinados. Esto crea un rastro de la actividad del interesado que el emisor puede correlacionar con otra información.
La amenaza de vinculación más grave surge cuando el mecanismo de revocación de credenciales permite que tanto el emisor como la RP recojan información sobre la actividad del interesado. Si ambas partes pueden acceder al estado de revocación, las marcas de tiempo u otros identificadores asociados con la credencial, pueden cooperar entre ellas para rastrear al usuario en diferentes transacciones y proveedores (RPs).
El ARF, los reglamentos de ejecución y las diferentes propuestas de la comunidad sugieren reducir el alcance o la frecuencia de las interacciones potencialmente vinculables. Por ejemplo, emitir credenciales de corta duración o lotes de credenciales para unos pocos usos o para un único uso. Además, limitar las comprobaciones relacionadas con la revocación de credenciales exclusivamente a los atributos que tengan un período de validez superior a 24 horas. Sin embargo, estas soluciones pueden causar problemas de usabilidad debido, por ejemplo, a que necesitan que el interesado solicite, almacene y gestione un gran número de credenciales. También podrían causar costes operativos significativos para los emisores, y hay que tener en cuenta que no evitan todas las amenazas mencionadas.
El mejor enfoque podría ser confiar en técnicas criptográficas como las firmas aleatorias o ciegas, pruebas de conocimiento cero (por ejemplo, para demostrar la validez de una credencial sin revelar ninguna información de tipo identificador a la RP o al emisor), credenciales anónimas o mecanismos de revocación basados en acumuladores, por mencionar sólo algunos ejemplos. La pregunta sería: ¿existen diseños e implementaciones efectivas y seguras de estas técnicas, soportadas por hardware, que puedan ser estandarizadas, certificadas y aprobadas por los estados miembros? Es necesario seguir investigando, desarrollando y colaborando para crear soluciones que preserven la privacidad y que se alineen con los objetivos del reglamento eIDAS2.
Fuente original de la noticia (Parte 1)
Fuente original de la noticia (Parte 2)
