Archivo de la categoría: Identificación remota

Ángel Luis Martín Bautista explica la Cartera de Identidad Digital Europea y su ecosistema (CNIS 2026)


Nota (octubre de 2026). La presentación de Ángel Martín que se recoge en el video referenciado en este artículo es muy interesante y sigue siendo una buena foto del proyecto, pero se dio el 26 de febrero de 2026 y desde entonces han pasado algunas cosas. Se han publicado nuevas versiones del Architecture and Reference Framework (la 2.9.0 en mayo y la 3.0.0 en verano). También se han adoptado nuevos actos de ejecución:

  • el Reglamento de Ejecución (UE) 2026/248, sobre los formatos de firma y sello electrónicos;
  • el Reglamento de Ejecución (UE) 2026/798, sobre el alta a distancia en la cartera, que el ponente da por rechazada «ayer»;
  • los Reglamentos de Ejecución (UE) 2026/1730, 2026/1731 y 2026/1735, de julio, que modifican los actos reabiertos (entre otras cosas, la fotografía del PID deja de ser una propuesta).

Lo que el ponente presenta como pendiente o en discusión debe leerse con esa perspectiva. Al final del resumen lo detallo.

En el XVI Congreso Nacional de Innovación y Servicios Públicos (CNIS 2026), celebrado el 26 de febrero de 2026, Ángel Luis Martín Bautista, jefe adjunto del Departamento de Tecnologías Disruptivas e Integridad de la Información de la Agencia Estatal de Administración Digital (AEAD), presentó la ponencia «Cartera de identidad digital: situación y ecosistema asociado».

La ponencia tiene tres partes: cómo avanza el proyecto europeo de cartera, el ecosistema de actores que la rodea y el estado del proyecto español. Sus mensajes principales son estos:

  • La cartera sustituye el modelo de nodos eIDAS de 2014 por otro en el que el ciudadano lleva sus datos y decide qué comparte.
  • La aplicación es solo una pieza. Para que funcione hacen falta una docena de actores, muchos de los cuales hay que notificar a la Comisión Europea.
  • La complejidad técnica crece: varios actos de ejecución se han reabierto y las tecnologías de formatos han pasado de 2 a 35, sin que se amplíe el plazo.
  • La cartera española debe estar lista el 24 de diciembre de 2026 y saldrá con el PID y las credenciales de mayor de 18 y de 16 años. El PID incluirá el número del DNI.
  • El alta exigirá nivel alto: cita presencial en una oficina de registro o lectura del DNIe por NFC. El alta totalmente remota no prosperó en la votación del acto de ejecución del día anterior a la charla.
  • El cotejo de identidades (identity matching) es un problema abierto, porque algunos países no incluirán un número de identificación en el PID.

Del eIDAS de 2014 a la cartera (0:53–3:44)

El primer Reglamento eIDAS, de 2014, buscaba que los medios de identificación electrónica de cada país sirvieran en los demás. La idea era buena, pero con los años mostró carencias:

  • Cada país notificaba su medio de identificación y los demás tenían que estudiarlo y aceptarlo, un proceso largo y farragoso.
  • Solo 14 Estados miembros llegaron a notificar un esquema; muchos ni siquiera ofrecían identificación electrónica a sus ciudadanos.
  • El sector privado no lo usó, aunque sí el público.
  • Era un sistema de «todo o nada»: se compartía toda la identificación o ninguna.
  • Exigía que cada Estado tuviera un nodo eIDAS que hacía de traductor. Cada vez que un país notificaba un medio nuevo, los 27 nodos tenían que actualizarse.

El nuevo modelo prescinde de los nodos: es el ciudadano quien lleva el dato y hace con él lo que quiere. La pieza central es la cartera digital.

Qué es la cartera de identidad digital de la UE y quién debe aceptarla (3:44–10:54)

  • Es el primer medio de identificación común de la UE: todos los ciudadanos podrán identificarse entre sí, en presencia y en línea, con un sistema interoperable.
  • Contiene los datos de identificación de la persona (PID), equivalentes a los del DNI español o la tarjeta de identidad de otros países.
  • Será obligatorio que cada Estado la ofrezca a finales de 2026, gratuita y voluntaria para el ciudadano.
  • Tiene tres funciones: identificar, presentar declaraciones electrónicas de atributos (cualquier atributo predicable de una persona, objeto o empresa) y firmar documentos electrónicos de forma gratuita para el ciudadano par usos particulares.
  • Se trabaja en casos de uso europeos y nacionales. Los europeos se definirán en rulebooks, guías con los datos, metadatos y arquitectura de cada caso.
  • Requisitos de ciberseguridad de nivel alto, divulgación selectiva de atributos y código fuente abierto.

Quién está obligado a aceptarla: el sector público; las entidades del sector privado obligadas a identificar a sus clientes (know your customer), como la banca, y los sectores que enumera el Reglamento (transporte, energía, servicios financieros, sanidad, agua…); y las grandes plataformas definidas por la Ley de Mercados Digitales. La diapositiva amplía la lista con seguridad social, servicios postales, infraestructura digital, educación y telecomunicaciones.

Otros servicios de confianza nuevos: la emisión de declaraciones electrónicas de atributos, con el mismo valor jurídico que un documento en papel; el archivo electrónico cualificado; y los libros mayores electrónicos. La gobernanza se apoya en un grupo de alto nivel sobre identidad digital en el que participan todos los Estados.

Esquema de funcionamiento: el ciudadano, en el centro, recibe las credenciales (declaraciones electrónicas de atributos) procedentes de fuentes auténticas o de emisores cualificados (hay credenciales cualificadas, no cualificadas y de organismos públicos) y las entrega a quien se las pida. La confianza transfronteriza se basa en registros de la Comisión y nacionales y en certificados de acceso y de registro. El ponente pone el ejemplo de una empresa alemana de alquiler de coches: la cartera debe saber que la empresa existe y alquila coches, y la empresa debe poder fiarse de los datos que recibe.

Actos de ejecución, consorcios y calendario (10:54–16:20)

Las especificaciones se debaten en el Marco de Arquitectura y Referencia (ARF), con un volumen de trabajo «increíble». Pero «lo que va a misa» es lo que los Estados votan en comitología: los actos de ejecución, que pasan a ser derecho vinculante.

La diapositiva de situación (referida a la versión 2.8.0 del ARF) detalla los lotes. La tabla sigue la presentación; la descripción oral del ponente no la sigue al pie de la letra.

LoteFecha en la diapositivaReglamentos de Ejecución (UE)Situación en febrero de 2026
121/11/20242024/2979 (integridad y funcionalidades básicas), 2024/2977 (PID y declaraciones electrónicas de atributos), 2024/2980 (notificaciones del ecosistema), 2024/2982 (protocolos e interfaces), 2024/2981 (certificación)Aprobados; todos salvo 2024/2981, reabiertos
206/05/2025 y 25/06/20252025/849 (listas de carteras), 2025/847 (brechas de seguridad), 2025/848 (partes usuarias), 2025/846 (cotejo de identidades), 2025/1569 (declaraciones electrónicas cualificadas de atributos)Aprobados; 2025/848 y 2025/1569, reabiertos
325–26/06/20252025/1566, 1567, 1568, 1570, 1571, 1572, 1929, 1942, 1943, 1945 y 1946 (servicios de confianza: firma y sello electrónicos, certificados cualificados, dispositivos cualificados, validación y conservación)Aprobados
416/09/20252025/2164 (formatos de las listas de confianza), 2025/2160 (prestadores no cualificados), 2025/2162 (organismos de evaluación de la conformidad)Aprobados
513/11/20252025/2530 (requisitos de los prestadores cualificados), formatos de firma y sello electrónicos (sin número en la diapositiva; hoy, 2026/248), 2025/2527 (certificados cualificados de sitio web), 2025/2532 (archivo electrónico), 2025/2531 (libros mayores electrónicos)Aprobados
6—Alta (on-boarding) en la carteraNon paper enviado
Siguientes—Nivel de garantía (art. 8.3), certificación de dispositivos cualificados de creación de firma, marco de los esquemas de identificación electrónicaNon paper pendiente

El dato más llamativo: en el acto de formatos del lote 1 había dos formatos; con la reapertura, las tecnologías propuestas ascienden a 35, y el plazo para tener las carteras no se amplía. «Fácil no nos lo están poniendo.»

Grandes consorcios europeos: proyectos multipaís que trabajan casos de uso para redactar los rulebooks. Ha habido seis: DC4EU, Potential, EWC, NOBID, APTITUDE y WE BUILD. El primero, DC4EU (Digital Credentials for Europe), lo lideró España, con 101 participantes de 26 Estados. Casos de uso citados: pagos, permiso de circulación, tarjeta sanitaria europea, títulos académicos, apertura de cuenta bancaria y el documento portátil A1 para acreditar la vida laboral en varios países.

Calendario: en 2026 deben adoptarse todos los actos de ejecución y notificarse a la Comisión los actores responsables en cada país. A finales de 2026 las carteras deben estar disponibles para los ciudadanos, y a finales de 2027 las empresas obligadas deben aceptarlas. La diapositiva de planificación lo detalla así: eIDAS2 en vigor en 2024; actos de ejecución adoptados entre 2024 y 2026; notificaciones a la Comisión en 2026; verificación de edad en 2025–2026; aceptación obligatoria para el sector público a finales de 2026–2027 y para el privado a finales de 2027.

Verificación de edad (16:20–18:47 y 30:45–31:29)

Varios Estados, España quizá el primero, se plantearon proteger a los menores del contenido para adultos y vieron que era un problema transfronterizo que nadie podía resolver por su cuenta. La cartera, obligatoria en 2026, era el instrumento natural: un caso de uso más.

El reto técnico es grande, porque hay que demostrar sin lugar a dudas que se supera una edad sin revelar ningún otro dato, y además:

  • lo que se presente debe ser distinto cada vez, para impedir el perfilado;
  • no debe existir ningún registro («efecto Gran Hermano») de cuándo y dónde se ha usado la cartera para esto.

Ya está terminada una primera versión de las especificaciones. Es un protocolo armonizado en la UE, alineado con el artículo 28 del Reglamento de Servicios Digitales sobre protección de menores en línea. La cartera española incluirá dos credenciales, mayor de 18 y mayor de 16 años, derivadas de la fecha de nacimiento del PID.

El ecosistema, actor por actor (18:47–30:45)

Para el ponente, la cartera es «un aspecto, y no de los más complejos» del ecosistema. Todos estos actores deben estar funcionando el día del lanzamiento, y muchos hay que notificarlos a la Comisión Europea.

ActorQué hace, según la ponencia
Punto de contacto únicoPersona u organismo de referencia en cada Estado para todo el ecosistema
Proveedor de la carteraQuien la suministra a los ciudadanos; se notifica a la Comisión
Usuario titularCiudadano o empresa que tiene la cartera
Proveedor de PIDEmite los datos de identificación. Su acto de ejecución se había reabierto
Emisores de declaraciones electrónicas de atributosDesde la DGT con el permiso de circulación hasta la empresa de alquiler de coches
Registro de partes usuariasNuevo procedimiento administrativo: un registro público, igual en todos los países, que acredita que una empresa existe, a qué se dedica y qué datos pide y para qué. Permite al ciudadano detectar peticiones excesivas («un título académico para alquilar un coche») y quejarse
Prestadores de servicios de confianzaEmiten a las partes usuarias registradas los certificados de acceso (obligatorios) y de registro (opcionales): X.509 «de toda la vida», pero exclusivos del ecosistema. El de acceso garantiza que la parte usuaria está registrada y comprobada; el de registro indica la finalidad y por qué se piden los datos. Este último es opcional porque aún faltan semánticas y metadatos por acordar
Organismo de supervisiónYa existe; previsiblemente asumirá nuevas responsabilidades
Fuentes auténticasLugar donde reside de forma indudable el origen de una información (un registro público, una academia de inglés). Los prestadores podrán consultarlas para emitir credenciales, y las fuentes podrán encargar a un tercero que emita por ellas
CertificaciónEsquema, organismo de certificación y organismos de evaluación de la conformidad. Dos esquemas: uno de ciberseguridad, con requisitos «extraordinariamente altos», y otro funcional
Cotejo de identidades (identity matching)Mecanismo para saber si dos identificaciones corresponden a la misma persona

El PID y el problema del cotejo. Según el ponente, los datos obligatorios del PID son muy pocos: nombre, apellidos, fecha de nacimiento y nacionalidad. Entre los opcionales está el número de identificación administrativo, en el que España incluirá el número del DNI, así que los españoles no causarán problemas a nadie. Pero habrá países que no lo incluyan, porque no tienen ese número (en algunos se considera inconstitucional) o porque tienen varios. «¿Cómo sé yo que el John Smith irlandés que me pidió una subvención por la mañana no es el mismo que me la pidió por la tarde?» El cotejo de identidades pretende permitir pedir los datos adicionales necesarios para asegurarse.

La reapertura del acto del PID proponía además incluir la fotografía. España la veía interesante, pero difícil antes de fin de año, porque muchas oficinas de registro no tienen cámaras.

La cartera española (20:48–23:00 y 31:29–33:08)

Alta con nivel alto. Como la cartera se basa en un esquema de nivel alto, obtenerla exigirá las mismas garantías que un pasaporte o un DNI. Habrá dos vías:

  1. Cita presencial en una oficina de registro. España es uno de los Estados con más oficinas de registro de la UE y las pondrá todas a disposición.
  2. DNI electrónico por NFC: quien recuerde la contraseña de su DNIe y tenga activos sus certificados podrá acercarlo al móvil y crear el PID con garantías.

Se discutía en Europa una tercera vía, el alta digital remota (videollamada o verificación del documento por inteligencia artificial, como en la banca). El acto de ejecución se votó «ayer» (el 25 de febrero) y no salió adelante, porque muchos países no lo consideraban tan seguro.

Prototipo. El ponente mostró las pantallas: descarga, ayuda, activación, añadir la credencial de identidad digital y pedir cita desde la propia aplicación si no se tiene NFC. Las credenciales se piden mediante un código QR que lleva dentro la solicitud concreta.

Lanzamiento. La cartera saldrá con el PID y las credenciales de mayor de 18 y mayor de 16 años. Hay muchas otras en preparación, tanto europeas, procedentes de los consorcios, como españolas. La fecha fijada es el 24 de diciembre: «Vienen para Papá Noel».

La diapositiva de credenciales de valor añadido marca la de mayor de 16 años como «en estudio». Como futuras credenciales cita: titulaciones universitarias y no universitarias, permiso de conducción (DGT), tarjeta sanitaria europea, documento A1 de la Seguridad Social, residencia, tarjeta sanitaria de las comunidades autónomas y certificado de ausencia de delitos sexuales.

Cierre. «Es un proyecto muy complejo precisamente porque quiere ser sencillo para el usuario, muy seguro, y confluir con Europa.»

Qué ha cambiado desde febrero, y algunos matices

  • Alta remota. Pese a la votación fallida del 25 de febrero, en abril se publicó el Reglamento de Ejecución (UE) 2026/798, que regula el alta a distancia en la cartera con nivel de garantía alto.
  • Actos reabiertos. En julio se publicaron los Reglamentos de Ejecución (UE) 2026/1730, 2026/1731 y 2026/1735. Modifican los actos que la diapositiva marcaba como reabiertos: 2025/848; 2024/2977, 2024/2979, 2024/2980 y 2024/2982; y 2025/1569. Con el 2026/1731, la fotografía del titular pasa a formar parte del PID salvo que el usuario decida no incluirla.
  • Formatos de firma y sello. El acto del lote 5 que aparecía sin número es el Reglamento de Ejecución (UE) 2026/248.
  • ARF. La presentación se basa en la versión 2.8.0. Después llegaron la 2.9.0 y la 3.0.0, alineada con los actos modificados.
  • Datos obligatorios del PID. Entre ellos el ponente no menciona el lugar de nacimiento, que sí figura en el Reglamento de Ejecución (UE) 2024/2977.
  • Cotejo de identidades. El ponente lo presenta como un acto «en elaboración», pero su propia diapositiva muestra el Reglamento de Ejecución (UE) 2025/846 aprobado en mayo de 2025. Probablemente se refiere a su desarrollo práctico.
  • Lotes. Su descripción oral no coincide del todo con la diapositiva: sitúa las listas de confianza en el lote 5 (en la diapositiva están en el lote 4), y no solo el lote 1 estaba reabierto, sino también dos actos del lote 2.
  • Certificados de acceso y de registro. El registro de partes usuarias y estos certificados abren un papel nuevo para los prestadores de servicios de confianza.

El problema del John Smith irlandés es el mismo que planteaba en «Codificación de los números de identidad de los ciudadanos de la Unión Europea en los certificados»: es una buena noticia que desde la AEAD se reconozca que habrá países sin número personal en el PID.

Artículos relacionados en este blog

El mercado de la Identidad Digital Europea: previsiones de 2021 y conjeturas de 2026


En abril de 2021, dos meses antes de que la Comisión presentara su propuesta de revisión de eIDAS, se cerró el Study to support the impact assessment for the revision of the eIDAS regulation, el estudio de apoyo a la evaluación de impacto elaborado por PwC y DLA Piper para la DG CNECT. Son 248 páginas que sirvieron de base técnica y económica a la propuesta que acabó convertida en el Reglamento (UE) 2024/1183, el que conocemos como eIDAS2.

Releerlo cinco años después resulta muy instructivo: permite ver qué problemas se identificaron, qué alternativas se barajaron, cuáles se eligieron y cuánto se ha transformado el mercado de la identidad digital desde entonces. En esta entrada resumo el estudio y hago ese repaso.

El punto de partida: el diagnóstico de 2021

El estudio partía de una constatación: el Reglamento eIDAS de 2014 había dado seguridad jurídica a los servicios de confianza y se había convertido en una referencia mundial, pero la parte de identificación electrónica no estaba funcionando como se esperaba. Los problemas que identificaba eran estos:

  • Cobertura insuficiente. Seis años después de eIDAS, los esquemas notificados cubrían solo a un 59 % de la población de la UE, y el 41 % de los ciudadanos no podía usar ninguna identificación electrónica fiable en otro país.
  • Uso transfronterizo testimonial. Las autenticaciones transfronterizas con identidades notificadas no llegaban a 10.000 al año, frente a millones de usos nacionales.
  • Limitación al sector público. eIDAS solo obligaba a reconocer identidades para servicios públicos, que son de uso poco frecuente: los entrevistados calculaban que un ciudadano necesita identificarse 1,5 veces al año ante la Administración y diez veces más ante servicios privados. En Suecia, solo el 7 % de las 4.100 millones de autenticaciones con BankID de 2019 correspondían a servicios públicos.
  • Ausencia de un marco para los atributos. Las credenciales que acreditan títulos, certificados médicos o cualificaciones profesionales quedaban fuera de eIDAS, lo que obligaba a cada país y sector a crear sus propios marcos.
  • Privacidad mejorable. eIDAS transmitía siempre el conjunto mínimo de datos completo, no permitía la divulgación selectiva y no admitía las pruebas de conocimiento cero.
  • Problemas en los servicios de confianza. Había divergencias nacionales en la supervisión y la evaluación de la conformidad, no estaba regulada la verificación remota de la identidad, el archivo electrónico carecía de reglas comunes y los navegadores se negaban a reconocer los certificados cualificados de autenticación de sitios web (QWAC).

Sobre todo, el estudio describía un mercado en el que los gobiernos habían dejado de ser los proveedores dominantes de identidad. Seis grandes plataformas (Facebook, Google, Instagram, LinkedIn, Twitter y Amazon) acaparaban el 87 % de los inicios de sesión sociales en Europa y se usaban en más de 50.000 servicios. A ellas se sumaban los bancos (con BankID como referencia nórdica), los operadores móviles con Mobile Connect, las empresas de identidad digital (Yoti, Onfido…), las redes de identidad derivada (Verimi, Yes, Mastercard) y los proveedores de identidad como servicio. El temor explícito era que, sin regulación, unas pocas plataformas aumentasen su dominio, con dependencia para los proveedores de servicios, cautividad de los usuarios y pérdida de autonomía digital europea.

Las cuatro opciones que se estudiaron

  • Opción 0, sin cambios: mantener eIDAS y completarlo solo con actos de ejecución y con los efectos de otras normas, como la Ley de Mercados Digitales.
  • Opción 1, reforzar el marco existente: obligar a los Estados a ofrecer identidades notificadas a todos los ciudadanos, ampliar el conjunto de datos, facilitar su uso por el sector privado, simplificar las revisiones inter pares y crear el archivo electrónico como servicio de confianza.
  • Opción 2, crear un mercado de atributos: un nuevo servicio de confianza cualificado para intercambiar atributos vinculados a la identidad legal (edad, títulos, permisos de conducir, certificados médicos), con acceso de los prestadores a las fuentes auténticas.
  • Opción 3, una cartera de identidad personal: un marco jurídico y técnico para una aplicación móvil controlada por el usuario, con dos variantes de despliegue: por prestadores cualificados privados o por los gobiernos (directamente, por mandato o mediante reconocimiento).

La conclusión fue que la mejor solución era combinar las opciones 1, 2 y 3. Y eso es, en esencia, lo que hizo el legislador: el Reglamento 2024/1183 refuerza el marco de identificación, crea las declaraciones electrónicas de atributos (cualificadas y del sector público) y establece la Cartera de Identidad Digital Europea, cuya provisión sigue siendo responsabilidad de los Estados miembros, de forma directa, por mandato o mediante reconocimiento.

Algunas cifras del estudio

El estudio cuantificaba los costes y beneficios de cada opción. Algunas estimaciones son especialmente interesantes vistas hoy:

  • El desarrollo y despliegue inicial de una cartera se estimaba en unos 10 millones de euros para 2021-2023.
  • Obtener la cualificación como prestador de un nuevo servicio de confianza costaría de media 545.000 euros iniciales y 255.000 euros anuales.
  • Conectar un proveedor de servicios a un nodo eIDAS costaba unos 42.000 euros.
  • El intercambio de atributos podría ahorrar al sector financiero entre 410 y 1.360 millones de euros al año en incorporación de clientes y cumplimiento de las obligaciones de diligencia debida, y reducir el fraude en entre 850 y 1.400 millones, con hipótesis de adopción del 20 % al 33 %.
  • Se citaban previsiones de crecimiento del mercado mundial de identidad de entre el 13 % y el 20 % anual.

Qué ha pasado desde entonces

Del estudio a la norma, y de la norma a la técnica

La propuesta se presentó en junio de 2021 y, tras casi tres años de negociación, el Reglamento 2024/1183 entró en vigor en mayo de 2024. Desde entonces se ha publicado una avalancha de actos de ejecución (más de treinta, que he ido recogiendo en el blog) y se ha desarrollado el marco técnico de la cartera: el ARF, que ya va por la versión 3.0, los protocolos OpenID4VCI y OpenID4VP, las normas ISO/IEC 18013-5 y 18013-7 y la serie ETSI TS 119 472. Los Estados miembros deben tener su cartera disponible a finales de 2026, y las partes usuarias privadas obligadas deben aceptarla a finales de 2027.

Muchos de los problemas de los servicios de confianza que señalaba el estudio tienen hoy respuesta normativa: la verificación remota de la identidad (CIR 2025/1566 y ETSI TS 119 461), el archivo electrónico cualificado (CIR 2025/2532), la acreditación armonizada de los organismos de evaluación de la conformidad (CIR 2025/2162) y los QWAC, cuya coexistencia con los certificados web de los navegadores regula el CIR 2025/2527. A ellos se suman servicios que el estudio no contemplaba, como los libros registro electrónicos cualificados.

De los pilotos al despliegue

Entre 2023 y 2025, los primeros pilotos a gran escala (POTENTIAL, EWC, NOBID y DC4EU) probaron la cartera en casos reales, y hoy les han tomado el relevo APTITUDE y WE BUILD. En diciembre de 2025, el primer Launchpad reunió en Bruselas a los equipos nacionales para probar la interoperabilidad, y la segunda edición, a finales de este mes, ya está pensada para el lanzamiento. La estimación de 10 millones por cartera contrasta con experiencias como la de Rumanía, que ha construido su cartera nacional en seis meses reutilizando componentes de código abierto alemanes: la implementación de referencia de la Comisión y el código abierto han abaratado la entrada mucho más de lo que se preveía.

Las plataformas, contenidas, pero no ausentes

El estudio temía la consolidación de las grandes plataformas como guardianes de la identidad. La respuesta ha llegado por dos vías: la Ley de Mercados Digitales y la obligación de las plataformas en línea de muy gran tamaño de aceptar la Cartera de Identidad Digital Europea cuando exijan autenticación. Pero las plataformas no se han quedado quietas: sus carteras móviles ya almacenan documentos de identidad en algunos mercados fuera de la UE, y los navegadores han incorporado la Digital Credentials API, por la que pasará buena parte de la presentación remota de credenciales. La competencia ya no está en el inicio de sesión social, sino en quién controla la interfaz en la que el usuario guarda y presenta sus credenciales.

Algunas de las alternativas que citaba el estudio han desaparecido o se han reorientado. Libra, la moneda de Facebook mencionada como ejemplo de identidad ligada a pagos, se abandonó en 2022 tras convertirse en Diem. Los esquemas nacionales consolidados, como itsme en Bélgica, han optado por convivir con la cartera en lugar de competir con ella.

De los atributos al ecosistema

La opción 2 del estudio se ha materializado en las declaraciones electrónicas de atributos, pero el mercado aún está en sus inicios. Según el resumen de una de las sesiones del Launchpad 2026, en septiembre solo tres de los unos 250 prestadores cualificados europeos tenían en producción un servicio de declaraciones electrónicas cualificadas de atributos, y todavía no había ningún organismo de evaluación acreditado para él. El ahorro que el estudio atribuía al intercambio de atributos sigue siendo, por tanto, una promesa.

El cambio de mirada sobre los intermediarios

Quizá la evolución más llamativa sea esta. En 2021, el estudio veía como ventaja de la cartera que «reduciría la necesidad de intermediarios», al permitir que el ciudadano se comunicara directamente con los proveedores de servicios y de credenciales, y dejaba el modelo de negocio sin prescribir. Cinco años después, el informe de la Comisión sobre modelos de negocio sitúa a los intermediarios en el centro del ecosistema: serán ellos quienes incorporen a las partes usuarias y a los emisores, gestionen miles de relaciones contractuales y redistribuyan los ingresos. La experiencia ha demostrado que ningún proveedor de cartera puede gestionar por sí solo miles de partes usuarias.

Lo que sigue pendiente

Algunas de las preocupaciones de 2021 siguen abiertas:

  • Las pruebas de conocimiento cero, cuya ausencia criticaba el estudio, siguen en discusión. La verificación de edad se resuelve por ahora con declaraciones de un solo uso y atributos como «mayor de 18», mientras se debate cómo incorporar soluciones más flexibles.
  • La financiación del ecosistema choca con el principio de no observabilidad, que impide facturar por uso sin mecanismos específicos de privacidad.
  • La responsabilidad de cada actor del ecosistema sigue sin un marco claro.
  • El riesgo de fragmentación, que motivó la revisión, reaparece ahora en otra forma: veintisiete despliegues nacionales con opciones distintas de modelo de negocio, casos de uso y funcionalidades.

¿Cuánto vale el mercado? Lo que dicen las consultoras

El estudio de 2021 se limitaba a citar previsiones de crecimiento del 13 % al 20 % anual para el mercado mundial de identidad. Cinco años después, he buscado estimaciones más recientes del mercado de identidad digital basada en carteras con horizonte 2030-2035. Lo que hay es escaso y poco homogéneo:

No he encontrado ningún estudio solvente que cuantifique en euros el mercado europeo de servicios ligados a la Cartera de Identidad Digital Europea para 2031 o 2036. El propio informe de la Comisión sobre modelos de negocio evita deliberadamente dar cifras.

Una referencia más sólida: la verificación de identidad en el alta de clientes

Un mercado comparable, y mucho mejor medido, es el de la verificación de identidad para el alta remota de clientes, sobre todo en banca. Es el de los sistemas de documento más biometría facial que ofrecen empresas como Onfido (integrada en Entrust desde 2024), Jumio, Veriff, IDnow, Signicat, Sumsub, Mitek, IDEMIA, Thales, GBG, Trulioo, AU10TIX o Shufti Pro, entre otras. Este es precisamente el mercado que la cartera puede transformar, porque permite sustituir la foto del documento y el selfie por la presentación de un PID de nivel alto.

Estas cifras dan una idea del orden de magnitud que está en juego: miles de millones al año que hoy se pagan por comprobar identidades con métodos que la cartera puede abaratar. El informe de la Comisión calcula, con datos de PwC, unos 10,4 euros por cada KYC básico de una persona física. La cuestión no es tanto si ese mercado desaparecerá como quién lo capturará. Lo más probable es que los actuales proveedores de verificación de identidad se reconviertan en intermediarios de la cartera: ya tienen las relaciones con los bancos, la integración técnica y la experiencia en cumplimiento. Varios de ellos, como Signicat o IDnow, participan activamente en los foros del ecosistema de la cartera. Para los prestadores cualificados, la oportunidad está en combinar ese papel con los servicios que solo nosotros podemos prestar: certificados cualificados, firma a distancia y declaraciones electrónicas cualificadas de atributos.

Conclusión

El estudio de 2021 acertó en el diagnóstico y en la solución: la combinación de identidad notificada reforzada, declaraciones de atributos y cartera es la que recoge el Reglamento 2024/1183. Donde más ha cambiado la visión es en la economía del ecosistema: de una cartera que eliminaría intermediarios hemos pasado a un ecosistema que depende de ellos, y de un modelo de negocio sin definir a un debate abierto sobre quién paga y cómo. Para los prestadores de servicios de confianza, las oportunidades que el estudio vislumbraba (expedición de declaraciones de atributos, firma a distancia, intermediación) son hoy más concretas que nunca, aunque el mercado esté todavía despegando.

Si quieres comentar cómo afecta esta evolución a tu organización, puedes escribirme a julian.inza@eadtrust.com o contactar con EADTrust en info@eadtrust.com.

Enlaces

El Estudio de 2021

Desde Poznań (Polonia): agenda y ponentes del Trusted Economy Forum 2026


Escribo desde Poznań, donde hoy, 14 de octubre, arranca el Trusted Economy Forum 2026. Como adelanté en Rumbo a Poznań: Trusted Economy Forum 2026, este foro se ha consolidado como una de las citas centroeuropeas de referencia sobre identidad digital y servicios de confianza. En aquel artículo hice una presentación general; en este quiero repasar con más detalle la agenda de los dos días y quiénes intervienen en cada sesión.

El lema de esta edición es «Connected by Trust». El foro se celebra en el edificio Concordia Design (calle Zwierzyniecka 3), a pocos minutos andando de la estación de tren, y lo organiza Obserwatorium.biz. Las sesiones son en inglés con traducción simultánea al polaco. La edición de 2025 reunió a más de 300 participantes de 15 países.

El programa se articula en seis módulos, tres por día, que combinan presentaciones breves (de unos 15 minutos) con muchos debates. Lo resumo a continuación.

Día 1 — miércoles 14 de octubre

Módulo 1: On the way to European Digital Identity Wallets

El primer bloque plantea una pregunta directa: ¿estamos preparados para la Cartera de Identidad Digital Europea?

  • Giorgia Dragoni (Observatorio de Identidad Digital del Politecnico di Milano) abre con la keynote «EUDI wallets landscape and its national strategies», un panorama de las estrategias nacionales de cartera.
  • Joanna Koczorowska (COI, el Centro de Tecnologías de la Información polaco, que es además patrocinador honorífico estratégico del foro) presenta «Ready for Polish EUDI Wallet!», sobre el estado de la cartera polaca.
  • Michał Tabor y Piotr Sterczała (Obserwatorium.biz) presentan el informe «Making the EUDI Wallet a Success».
  • Debate «Europe’s Digital Identity Ecosystem: from trust infrastructure to global reference model – is this the realistic scenario?», moderado por Andras A. Barsi (Aruba), con Katarzyna Zajkowska (Ministerio de Asuntos Digitales de Polonia), Katarzyna Seroczyńska (COI), Lal Chandran (iGrant.io), Jan Szajda (IDENTT) y Edgars Stafeckis (Trustlynx).
  • Elżbieta Andrukiewicz (Instituto Nacional de Telecomunicaciones de Polonia) explica la certificación de la cartera en «EUDI Wallet Certification in Practice: The Polish Experience and Future Perspectives».
  • Marco Mangiulli (Aruba) cierra el módulo con «Beyond the Wallet: Building Europe’s Next Trust Infrastructure».

Módulo 2: Trust trends

Nuevos servicios, mercados y tecnologías. Es el módulo más cercano a los temas que trato habitualmente en este blog.

  • Doble sesión sobre criptografía postcuántica: Martin Stiefel (Allaris) pregunta «Is your organisation ready for the post-quantum world?» y Piotr Rydlichowski (Centro de Supercomputación y Redes de Poznań, PCSS) plantea «Post-quantum – buzzword or real threat?».
  • Debate «Electronic Attestations of Attributes: The Missing Link in Digital Business Transformation?» sobre las declaraciones electrónicas de atributos, moderado por Marcin Wolski (Obserwatorium.biz), con Viktor Varga (Microsec) y Sebastian Elfors (IDnow Trust Services).
  • Aleksandra Nowak (IDENTT) aborda la integración de las partes usuarias en «EUDI Wallet relying party integration».
  • Jakub Kwiatkowski (PCSS) habla de confianza y procedencia en la inteligencia artificial: «Trust and Provenance in AI».
  • Debate «Business Wallet – what is it all about?», moderado por Arno Fiedler (Nimbus; vicepresidente de ETSI TC ESI), con Marcin Szulga (Asseco Data Systems), Szymon Mamrot (coordinador nacional de la Pasarela Digital Única, Ministerio de Desarrollo Económico y Tecnología) e Iñigo Barreira (Sectigo; también vicepresidente de ETSI TC ESI).
  • Grzegorz Sokołowski (GS1 Polonia) cierra con «Digital Product Passport and the Future of Trusted Data Exchange».

Tras la comida hay un interludio muy apropiado para la ciudad: Oliwier Sakowski, del Centro del Cifrado Enigma de Poznań, presenta «From Enigma to Modern Cryptography». Conviene recordar que fueron tres matemáticos formados en la Universidad de Poznań —Marian Rejewski, Jerzy Różycki y Henryk Zygalski— quienes rompieron por primera vez la criptografía de la máqiina Enigma, utilizada por Alemania en la segunda guerra mundial, a comienzos de los años treinta. En julio de 1939, semanas antes de la invasión alemana, compartieron sus resultados, sus réplicas de la máquina y el diseño de su bomba criptológica con los servicios de inteligencia británico y francés. Sobre esa base trabajó Alan Turing en Bletchley Park: su Bombe británica perfeccionó la idea polaca y permitió descifrar de forma sistemática las comunicaciones alemanas durante la guerra. Turing, que en 1936 ya había sentado las bases teóricas de la computación con su «máquina universal», es hoy una figura de referencia de la informática, y la historia de Enigma ilustra bien algo que seguimos aplicando en criptografía: la seguridad de un sistema no debe depender del secreto del algoritmo, sino de la solidez de las claves y de su correcta gestión.

Módulo 3: Digital market players

  • Jarek Sygitowicz (Authologic): «Making cross border verifiable credentials work».
  • Karen Mkoyan (imID) presenta el caso de Armenia: «Digital Trust Beyond the EU: Armenia’s eIDAS-Aligned Digital Trust Ecosystem».
  • Debate «Building a successful partnership between supervisory bodies and national QTSPs», moderado por Jon Ølnes (Signicat), con Michał Kowalewski-Li (Ministerio de Asuntos Digitales de Polonia), Artur Miękina (Asseco Data Systems), Andrea Röck (ANSSI) y Andrea Sassetti (Aruba PEC; presidente de AssoCertificatori Italia).

La jornada termina con una discusión abierta y, por la noche, con la velada de networking «Connected by Trust» en el propio Concordia Design.

Día 2 — jueves 15 de octubre

Módulo 1: Trust in action!

Implantación real de servicios de confianza, carteras y verificación de identidad en empresas y administraciones.

  • Andreas Freitag (Procivis): «Implement EUDI Wallet (Fast) – What are the options?».
  • Debate «The World of Payment, Identity and Super Wallets: One Ecosystem or Competing Digital Universes?», moderado por Beata Galas, con Jarek Sygitowicz (Authologic), Kevin Meijer (Betaalvereniging Nederland; responsable de pagos de consumo en el consorcio WE BUILD) y Tomasz Chomicki (Samsung Electronics Polonia).
  • Debate «Building the EUDI Wallet Ecosystem Together: Why Market Collaboration Is Essential?», moderado por Piotr Sterczała, con Piotr Brewiński (FinTech Poland), Maciej Mironiuk (Visa), Anna Koźlik (COI) y Jakub Banaś (BNP Paribas Bank Polska).
  • Karol Ciechoński (Ayuntamiento de Lublin) aporta la visión de la administración local: «Local administration view on new digital ecosystem».

Módulo 2: Customer in the centre!

Experiencia de usuario y modelos de negocio.

  • Bart Jurkowski (I’MPRO): «Ready for the Unexpected – Acting Effectively in a World of Change and Uncertainty».
  • Gran debate «Sector Solutions or Shared Digital Infrastructure?», moderado por Miłosz Brakoniecki (Obserwatorium.biz), con Grzegorz Wójcik (Autenti), Edgars Stafeckis (Trustlynx), Anna Sienkiewicz (ING Leasing), Andrzej Ochocki (Deutsche Telekom), Bartosz Witkowski (Signius) y Tomasz Litarowicz (Asseco Data Systems).
  • Adrian Doerk (Lissi) sobre la experiencia de usuario de la cartera y los retos para las partes usuarias.
  • Arno Fiedler (Nimbus) presenta «Proving What’s Real: C2PA, Content Credentials and the Future of Digital Trust», sobre la autenticidad del contenido digital.
  • Debate «What Customers Really Need», moderado por Remigiusz Lewandowski, con Piotr Andruszkiewicz (eIDAS Easy), Andrzej Zduńczyk (BIK), Krzysztof Król (UODO, la autoridad polaca de protección de datos) y Marek Pieróg (Siepomaga.pl).
  • Tomasz Nogol (MONET+): «Digital Identity in Insurance 2027: Opportunities You Can’t Afford to Miss».

Después de la comida, Marcin Bielicki (SENSE) habla de «habilidades blandas» para equipos de innovación, y le sigue el debate «Zero Trust Meets Digital Trust: Rethinking the Security of Electronic Transactions», moderado por Krzysztof Bogacki, con Agata Kolorz-Lentini (Autenti), Piotr Rutkowski (NASK; vicepresidente de la Asamblea General de EUROPEUM-EDIC) y Robert Poznański (Asseco Data Systems).

Módulo 3: Global Trust Services

Interoperabilidad y expansión internacional de los servicios de confianza.

  • Guillaume Forget (Cloud Signature Consortium; Cryptomathic): «CSC as interoperability pillar in the Trusted Digital Economy», sobre el uso de la firma electrónica más allá de los contratos (cumplimiento, prevención del fraude, facturación electrónica y cadenas de suministro).
  • Charla con Xavier Juredieu (EUROPEUM-EDIC; consorcio WE BUILD) sobre la hoja de ruta de EUROPEUM-EDIC y EBSI, moderada por Miłosz Brakoniecki.
  • Alessia Soccio (Entaksi Solutions): «Trust services as a factor of European Sovereignty – the e-Archive Case».
  • Michał Tabor (Obserwatorium.biz): «How to build PanEuropean eDelivery».
  • Debate final «How to build a bridge of trust and digital identity between Asia, America and Europe?», moderado por Guillaume Forget, con Andreea Prian (IDAKTO), Svetlanna Maleryan (imID), Łukasz Jaromin (Raidiam), Igor Marcolongo (InfoCert, grupo Tinexta) y Melany Pașca (Edge Institute, Rumanía).

La clausura está prevista para las 16:30 del jueves.

Lo que más me interesa

De un programa tan denso, hay varias sesiones que seguiré con especial atención:

  • El debate sobre declaraciones electrónicas de atributos. Es probablemente el servicio de confianza nuevo de eIDAS 2 con más recorrido comercial, y la pregunta del título —¿el eslabón perdido de la transformación digital de las empresas?— es exactamente la que nos hacemos los prestadores cualificados.
  • La relación entre organismos de supervisión y prestadores cualificados. Tener en la misma mesa al ministerio polaco, a la ANSSI francesa y a prestadores de Polonia e Italia permite comparar modelos de supervisión, algo muy útil para quienes operamos bajo la supervisión de la SEDIA en España.
  • La Business Wallet, con dos vicepresidentes de ETSI TC ESI en el debate, en pleno proceso de definición de la cartera empresarial europea.
  • La criptografía postcuántica, que aquí se presenta desde dos ángulos: la preparación de las organizaciones y el análisis de la amenaza real.
  • Los pilotos a gran escala, con la presencia de WE BUILD en el debate sobre pagos y en la sesión sobre EUROPEUM-EDIC y EBSI.
  • El puente entre Asia, América y Europa, con el caso de Armenia como ejemplo de ecosistema alineado con eIDAS fuera de la Unión, un tema que me interesa por el trabajo que hacemos en Latinoamérica.

Organización y patrocinio

El foro cuenta con el patrocinio honorífico estratégico del COI y con Asseco Data Systems como socio Gold. Entre los socios Silver están Siepomaga, IDENTT, Authologic, Signius, Aruba, Allaris y Autenti, y entre los Bronze, Crédit Agricole (EFL), QSCert, Lissi, Procivis, IDnow, Trustlynx y Monet+. Entre los patrocinadores honoríficos figuran ETSI, el Ministerio de Digitalización y el Ministerio de Desarrollo y Tecnología polacos, la UODO, NASK, el comité polaco de normalización (PKN), la Universidad Tecnológica de Poznań y el PCSS.

EADTrust y la Cartera de Identidad Digital Europea

Mi presencia en Poznań forma parte del compromiso de EADTrust con el despliegue de la Cartera de Identidad Digital Europea. EADTrust es uno de los prestadores cualificados de servicios de confianza más activos de España en el impulso de la cartera, como pueden comprobar los lectores habituales de este blog.

Ese compromiso también se traduce en eventos en España. El pasado 28 de abril coorganizamos con el Observatorio Legaltech Garrigues-ICADE la jornada «La Cartera de Identidad Digital de la UE, su implementación y transformación de la gestión de la identidad», que puede verse en vídeo en la web de la Universidad Pontificia Comillas.

Ahora estamos preparando con G-Digital, de Garrigues, dos nuevas citas: un evento ligero en diciembre de 2026 y otro más amplio, previsiblemente en abril de 2027. Buena parte de lo que estoy escuchando estos días en Poznań, y de los contactos que estoy haciendo, servirá para preparar esos encuentros. Daré más detalles aquí en cuanto estén cerrados.

Seguiré informando

En los próximos días compartiré aquí mis notas y conclusiones de las sesiones. Si también estás en Poznań y quieres que hablemos, búscame en los descansos o escríbeme a julian.inza@eadtrust.com.

Enlaces

Estándares publicados en el desarrollo de la Cartera de Identidad Digital Europea y del resto de aspectos cubiertos por #EIDAS2


En la entrada «Los actos de ejecución de #eIDAS2, al día, junto con las normas ETSI y CEN que citan», actualizada en octubre de 2026, relaciono cada Reglamento de Ejecución con las normas técnicas que lo hacen operativo. Muchos lectores me han pedido la vista inversa: partir de cada norma y saber qué es, de qué trata y qué actos la exigen.

Eso es lo que recoge esta entrada: un catálogo de las normas de ETSI, CEN e ISO citadas en los actos de ejecución de eIDAS2, ordenadas por organismo y número, con su título oficial en inglés, una traducción al español, un breve resumen de su contenido y los actos que las citan. Las dos entradas se complementan: aquella sirve para saber qué normas aplica un acto concreto y esta, para entender cada norma y ver en qué actos aparece.

Las referencias se han obtenido del texto de cada acto publicado en EUR-Lex, incluidos los reglamentos modificativos de julio de 2026 (CIR (UE) 2026/1730, 2026/1731 y 2026/1735), que incorporan buena parte de las especificaciones ETSI más recientes sobre la cartera, y el anexo II del CIR (UE) 2025/2162, que recoge las normas de referencia para evaluar cada servicio de confianza cualificado.

Siglas utilizadas: DEA = declaración electrónica de atributos; DECA = declaración electrónica cualificada de atributos; PID = datos de identificación de la persona (DIP); CIR = Reglamento de Ejecución de la Comisión; CID = Decisión de Ejecución de la Comisión.

Criterio de clasificación

Las normas se agrupan en dos bloques:

  • Bloque 1, Cartera de Identidad Digital Europea (38 entradas): normas citadas por alguno de los actos de la cartera y de sus partes usuarias, es decir, los CIR (UE) 2024/2977, 2024/2979, 2024/2980, 2024/2981, 2024/2982, 2025/848, 2026/798, 2026/1730 y 2026/1731. Algunas de ellas, como la EN 319 401 o los formatos AdES, las citan también actos de servicios de confianza; en ese caso se indican todos.
  • Bloque 2, resto de servicios de confianza (35 entradas): normas que solo citan los demás actos de ejecución.

Dentro de cada bloque el orden es alfabético por organismo (CEN, ETSI, ISO) y numérico dentro de cada uno. En la serie ETSI de firmas electrónicas se han traducido los títulos de forma orientativa; los títulos originales en inglés son los que hay que usar en pliegos y auditorías.

Bloque 1. Normas de la Cartera de Identidad Digital Europea

Normas CEN

CEN EN 17640:2018

  • Versión citada: 2018
  • Título: Fixed-time cybersecurity evaluation methodology for ICT products
  • En español: Metodología de evaluación de ciberseguridad de tiempo fijo para productos TIC
  • Contenido: Metodología de evaluación de seguridad con duración y esfuerzo acotados (conocida como FITCEM), en la que se inspiran esquemas nacionales como CSPN (Francia), BSZ (Alemania) o LINCE (España). Sirve de referencia para evaluar componentes de la cartera cuando no se exige una evaluación Common Criteria completa.
  • Citada en: CIR (UE) 2024/2981 (certificación de las carteras: metodología de evaluación y tabla de certificados reutilizables)

Normas ETSI

ETSI TS 119 182-1

  • Versión citada: V1.2.1 (2024-07)
  • Título: Electronic Signatures and Infrastructures (ESI); JAdES digital signatures; Part 1: Building blocks and JAdES baseline signatures
  • En español: Firmas electrónicas e infraestructuras (ESI); firmas digitales JAdES; parte 1: componentes básicos y firmas JAdES de nivel básico
  • Contenido: Formato de firma avanzada para JSON basado en JWS, con los niveles B, T, LT y LTA.
  • Citada en: CIR (UE) 2024/2979 (formato opcional de la cartera); CIR (UE) 2025/2531 (con adaptaciones); CIR (UE) 2026/248; CIR (UE) 2025/2162 (anexo II, que la cita por error como «EN 319 182-1»)

ETSI TS 119 411-8

  • Versión citada: V1.1.1 (2025-10)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 8: Access Certificate Policy for EUDI Wallet Relying Parties
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); requisitos de política y seguridad para los prestadores que expiden certificados; parte 8: política de certificados de acceso para las partes usuarias de la Cartera EUDI
  • Contenido: Política de certificación específica para los certificados de acceso con los que las partes usuarias se identifican ante las carteras al solicitar datos. Sustituye a la referencia genérica a la política NCP de la EN 319 411-1.
  • Citada en: CIR (UE) 2026/1730 (modifica el CIR (UE) 2025/848 en lo relativo a los certificados de acceso)

ETSI TS 119 412-6

  • Versión citada: V1.1.1 (2025-09)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Certificate Profiles; Part 6: Certificate profile requirements for PID, Wallet, EAA, QEAA, and PSBEAA providers
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); perfiles de certificado; parte 6: requisitos de perfil de certificado para los proveedores de PID, de carteras, de DEA, de DECA y de DEA del sector público
  • Contenido: Perfiles de los certificados con los que firman o sellan los proveedores de datos de identificación personal, los proveedores de carteras y los emisores de declaraciones electrónicas de atributos.
  • Citada en: CIR (UE) 2026/1731 (anexo II del CIR (UE) 2024/2979)

ETSI TS 119 432

  • Versión citada: v1.3.1 (2026-03)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Protocols for remote digital signature creation
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); protocolos para la creación de firmas digitales a distancia
  • Contenido: Protocolos e interfaces de programación para firmar a distancia, alineados con la especificación del Cloud Signature Consortium. Es la interfaz que deben admitir las aplicaciones de firma usadas por la cartera.
  • Citada en: CIR (UE) 2026/1731 (anexo IV del CIR (UE) 2024/2979, cláusulas 6.4.3, A.6, A.7 y A.8)

ETSI TS 119 461

  • Versión citada: V2.1.1 (2025-02)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for trust service components providing identity proofing of trust service subjects
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); requisitos de política y seguridad para los componentes de servicio de confianza que verifican la identidad de los sujetos
  • Contenido: Requisitos para verificar la identidad de personas físicas y jurídicas, presencial o a distancia (vídeo, documento con chip, identificación electrónica), con casos de uso y niveles de confianza. El CIR 2026/798 la aplica al alta remota en la cartera.
  • Citada en: CIR (UE) 2025/1566 (verificación de identidad); CIR (UE) 2026/798 (alta remota en la cartera); CIR (UE) 2025/2162 (anexo II)

ETSI TS 119 472-1

  • Versión citada: V1.2.1 (2026-02)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Profiles for Electronic Attestation of Attributes; Part 1: General requirements
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); perfiles de las declaraciones electrónicas de atributos; parte 1: requisitos generales
  • Contenido: Perfiles de las declaraciones electrónicas de atributos en los formatos SD-JWT VC e ISO/IEC mdoc: contenido, firma, metadatos, revocación y políticas de divulgación integradas.
  • Citada en: CIR (UE) 2026/1731 (anexo II del CIR (UE) 2024/2979)

ETSI TS 119 472-2

  • Versión citada: V1.2.1 (2026-03)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Profiles for Electronic Attestation of Attributes; Part 2: Profiles for EAA/PID Presentations to Relying Party
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); perfiles de las declaraciones electrónicas de atributos; parte 2: perfiles de presentación de DEA y PID a la parte usuaria
  • Contenido: Perfil del protocolo de presentación de datos de la cartera a las partes usuarias, basado en OpenID4VP, en remoto y en proximidad.
  • Citada en: CIR (UE) 2026/1731 (anexo II del CIR (UE) 2024/2982)

ETSI TS 119 472-3

  • Versión citada: V1.1.1 (2026-03)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Profiles for Electronic Attestation of Attributes; Part 3: Profiles for issuance of EAA or PID
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); perfiles de las declaraciones electrónicas de atributos; parte 3: perfiles de expedición de DEA o PID
  • Contenido: Perfil del protocolo de expedición de PID y declaraciones de atributos a la cartera, basado en OpenID4VCI, incluidos los metadatos del emisor y el uso de certificados de registro.
  • Citada en: CIR (UE) 2026/1731 (anexo I del CIR (UE) 2024/2982, protocolos de expedición; anexo III del CIR (UE) 2024/2979, políticas de divulgación integradas; nota en el anexo Ib del CIR (UE) 2024/2979)

ETSI TS 119 475

  • Versión citada: V1.2.1 (2026-03)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Relying party attributes supporting EUDI Wallet user’s authorisation decisions
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); atributos de la parte usuaria que respaldan las decisiones de autorización del usuario de la Cartera EUDI
  • Contenido: Define los certificados de registro y los datos de las partes usuarias (identidad, finalidad, atributos que pueden solicitar) que la cartera muestra al usuario para que decida si comparte sus datos.
  • Citada en: CIR (UE) 2026/1730 (anexo V del CIR (UE) 2025/848, certificados de registro); CIR (UE) 2026/1731 (anexo II del CIR (UE) 2024/2982)

ETSI EN 319 122-1

  • Versión citada: V1.3.1 (2023-06)
  • Título: Electronic Signatures and Infrastructures (ESI); CAdES digital signatures; Part 1: Building blocks and CAdES baseline signatures
  • En español: Firmas electrónicas e infraestructuras (ESI); firmas digitales CAdES; parte 1: componentes básicos y firmas CAdES de nivel básico
  • Contenido: Formato de firma avanzada basado en CMS (estructuras binarias ASN.1), con los niveles B, T, LT y LTA.
  • Citada en: CIR (UE) 2024/2979 (formato opcional de firma de la cartera; el DOUE lo escribe por error «EN 3191 22-1»); CIR (UE) 2025/2531 (libros registro electrónicos); CIR (UE) 2026/248 (sector público); CIR (UE) 2025/2162 (anexo II, libros registro)

ETSI EN 319 132-1

  • Versión citada: V1.2.1 (2022-02) en 2024/2979; V1.3.1 (2024-07) en 2025/2531
  • Título: Electronic Signatures and Infrastructures (ESI); XAdES digital signatures; Part 1: Building blocks and XAdES baseline signatures
  • En español: Firmas electrónicas e infraestructuras (ESI); firmas digitales XAdES; parte 1: componentes básicos y firmas XAdES de nivel básico
  • Contenido: Formato de firma avanzada para documentos XML basado en XMLDSig, con los niveles B, T, LT y LTA.
  • Citada en: CIR (UE) 2024/2979 (formato opcional de la cartera); CIR (UE) 2025/2531; CIR (UE) 2026/248; CIR (UE) 2025/2162 (anexo II)

ETSI EN 319 142-1

  • Versión citada: V1.1.1 (2016-04) en 2024/2979; V1.2.1 (2024-01) tras 2026/1731
  • Título: Electronic Signatures and Infrastructures (ESI); PAdES digital signatures; Part 1: Building blocks and PAdES baseline signatures
  • En español: Firmas electrónicas e infraestructuras (ESI); firmas digitales PAdES; parte 1: componentes básicos y firmas PAdES de nivel básico
  • Contenido: Formato de firma avanzada integrada en documentos PDF. Es el formato obligatorio que debe admitir la cartera para firmar o sellar.
  • Citada en: CIR (UE) 2024/2979 (formato obligatorio de la cartera), actualizada a V1.2.1 por CIR (UE) 2026/1731; CIR (UE) 2026/248

ETSI EN 319 162-1 y EN 319 162-2

  • Versión citada: V1.1.1 (2016-04)
  • Título: Electronic Signatures and Infrastructures (ESI); Associated Signature Containers (ASiC); Part 1: Building blocks and ASiC baseline containers; Part 2: Additional ASiC containers
  • En español: Firmas electrónicas e infraestructuras (ESI); contenedores de firma asociada (ASiC); parte 1: componentes básicos y contenedores ASiC de nivel básico; parte 2: contenedores ASiC adicionales
  • Contenido: Contenedores (basados en ZIP) que agrupan uno o varios documentos con sus firmas o sellos de tiempo separados, en variantes ASiC-S y ASiC-E.
  • Citada en: CIR (UE) 2024/2979 (formato opcional de la cartera); CIR (UE) 2026/248

ETSI EN 319 401

  • Versión citada: V3.1.1 (2024-06); V3.2.1 (2026-01) en 2026/1735
  • Título: Electronic Signatures and Trust Infrastructures (ESI); General Policy Requirements for Trust Service Providers
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); requisitos generales de política para los prestadores de servicios de confianza
  • Contenido: Requisitos horizontales para cualquier prestador: gestión de riesgos, políticas y prácticas, recursos humanos, seguridad física y lógica, gestión de incidentes, continuidad de negocio y cese de actividad. Es la base sobre la que se construyen las normas específicas de cada servicio.
  • Citada en: CIR (UE) 2025/1566; 2025/1567; 2025/1569; 2025/1929; 2025/1942; 2025/1943; 2025/1944; 2025/1946; 2025/2160; 2025/2531; 2025/2532; 2026/798 (alta remota en la cartera); 2026/1735 (V3.2.1); CIR (UE) 2025/2162 (anexo II, con una errata «EN 310 401» en dos entradas)

ETSI EN 319 411-1

  • Versión citada: V1.4.1 (2023-10) en 2025/848; V1.5.1 (2025-04) en 2025/1943 y 2025/1944
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); requisitos de política y seguridad para los prestadores de servicios de confianza que expiden certificados; parte 1: requisitos generales
  • Contenido: Políticas de certificación normalizadas (NCP, NCP+, LCP, EVCP…) y requisitos de ciclo de vida de los certificados: registro, emisión, revocación y servicios de estado.
  • Citada en: CIR (UE) 2025/848 (certificados de acceso y de registro de las partes usuarias, sustituida después por TS 119 411-8 y TS 119 475 mediante CIR (UE) 2026/1730); CIR (UE) 2025/1942; CIR (UE) 2025/1943; CIR (UE) 2025/1944; CIR (UE) 2025/2162 (anexo II, como «EN 319 411»)

ETSI EN 319 412-1

  • Versión citada: V1.6.1 (2025-06)
  • Título: Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 1: Overview and common data structures
  • En español: Firmas electrónicas e infraestructuras (ESI); perfiles de certificado; parte 1: visión general y estructuras de datos comunes
  • Contenido: Estructuras comunes a todos los perfiles de certificado de ETSI, como la semántica de identificadores (por ejemplo, el NIF o el VAT en el campo organizationIdentifier).
  • Citada en: CIR (UE) 2025/1943; CIR (UE) 2026/1731 (referencia normativa de la TS 119 472-1 en el anexo II del CIR (UE) 2024/2979); CIR (UE) 2025/2162 (anexo II)

ETSI EN 319 412-2

  • Versión citada: V2.4.1 (2025-06)
  • Título: Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 2: Certificate profile for certificates issued to natural persons
  • En español: Firmas electrónicas e infraestructuras (ESI); perfiles de certificado; parte 2: perfil de certificado para certificados expedidos a personas físicas
  • Contenido: Perfil de los certificados de personas físicas, incluidos los certificados cualificados de firma.
  • Citada en: CIR (UE) 2025/1943; CIR (UE) 2026/1731 (certificados de los registros en el anexo II del CIR (UE) 2024/2980); CIR (UE) 2025/2162 (anexo II)

ETSI EN 319 412-3

  • Versión citada: V1.3.1 (2023-09)
  • Título: Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 3: Certificate profile for certificates issued to legal persons
  • En español: Firmas electrónicas e infraestructuras (ESI); perfiles de certificado; parte 3: perfil de certificado para certificados expedidos a personas jurídicas
  • Contenido: Perfil de los certificados de personas jurídicas, incluidos los certificados cualificados de sello.
  • Citada en: CIR (UE) 2025/1943; CIR (UE) 2026/1731 (anexo II del CIR (UE) 2024/2980); CIR (UE) 2025/2162 (anexo II)

ETSI EN 319 412-5

  • Versión citada: V2.5.1
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Certificate Profiles; Part 5: QCStatements
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); perfiles de certificado; parte 5: declaraciones QCStatements
  • Contenido: Extensiones QCStatements que indican en el certificado su carácter cualificado, el tipo (firma, sello o web), si la clave está en un dispositivo cualificado y otros datos. El CIR 2026/1731 añade un tipo nuevo para los certificados de los emisores de declaraciones de atributos del sector público (id-etsi-qct-eidaspsbeaa).
  • Citada en: CIR (UE) 2025/1943; CIR (UE) 2026/1731 (anexo II del CIR (UE) 2024/2979, Pub-EAA); CID (UE) 2025/2164 (lista de confianza); CIR (UE) 2025/2162 (anexo II)

Normas ISO e ISO/IEC

ISO 3166-1

  • Versión citada: (sin versión; 2006 en 2025/2164)
  • Título: Codes for the representation of names of countries and their subdivisions — Part 1: Country code
  • En español: Códigos para la representación de los nombres de los países y sus subdivisiones — Parte 1: Códigos de país
  • Contenido: Códigos de país de dos letras (alfa-2), como ES o FR. Se usa en los datos PID, en el identificador de las partes usuarias (con la excepción de Grecia, «EL») y en las listas de confianza.
  • Citada en: CIR (UE) 2024/2977 (PID); CIR (UE) 2025/848 (registro de partes usuarias); CIR (UE) 2026/1731 (anexo del CIR (UE) 2024/2977); CID (UE) 2025/2164

ISO 3166-2:2020

  • Versión citada: 2020
  • Título: Codes for the representation of names of countries and their subdivisions — Part 2: Country subdivision code
  • En español: Códigos para la representación de los nombres de los países y sus subdivisiones — Parte 2: Códigos de subdivisión de país
  • Contenido: Códigos de regiones y provincias (por ejemplo, ES-MD). Se usa para indicar la jurisdicción que expide los datos PID.
  • Citada en: CIR (UE) 2024/2977; CIR (UE) 2026/1731

ISO/IEC 5218

  • Versión citada: (sin versión)
  • Título: Information technology — Codes for the representation of human sexes
  • En español: Tecnologías de la información — Códigos para la representación de los sexos humanos
  • Contenido: Códigos numéricos del sexo (0, 1, 2 y 9), que el PID usa para el atributo opcional «sex», ampliado con otros valores propios.
  • Citada en: CIR (UE) 2024/2977; CIR (UE) 2026/1731

ISO 8601-1

  • Versión citada: (sin versión)
  • Título: Date and time — Representations for information interchange — Part 1: Basic rules
  • En español: Fecha y hora — Representaciones para el intercambio de información — Parte 1: Reglas básicas
  • Contenido: Formato normalizado de fechas (AAAA-MM-DD), que se usa, por ejemplo, para la fecha de nacimiento en la codificación SD-JWT VC del PID.
  • Citada en: CIR (UE) 2026/1731 (anexo del CIR (UE) 2024/2977)

ISO/IEC 15408

  • Versión citada: 2022 (partes 1 a 5)
  • Título: Information security, cybersecurity and privacy protection — Evaluation criteria for IT security
  • En español: Seguridad de la información, ciberseguridad y protección de la privacidad — Criterios de evaluación de la seguridad TI
  • Contenido: Los «Common Criteria»: marco para especificar y evaluar requisitos funcionales y de garantía de seguridad de productos TIC, con niveles EAL y componentes como AVA_VAN (análisis de vulnerabilidades).
  • Citada en: CIR (UE) 2024/2981 (parte 3, AVA_VAN.5 para el dispositivo criptográfico seguro de la cartera); CIR (UE) 2025/1929; 2025/1942; 2025/1943; 2025/1944; 2025/1946; 2025/2531; 2025/2532; 2026/1735

ISO/IEC 17000:2020

  • Versión citada: 2020
  • Título: Conformity assessment — Vocabulary and general principles
  • En español: Evaluación de la conformidad — Vocabulario y principios generales
  • Contenido: Términos y principios comunes de la evaluación de la conformidad (certificación, inspección, validación, verificación…).
  • Citada en: CIR (UE) 2024/2981

EN ISO/IEC 17020:2012

  • Versión citada: 2012
  • Título: Conformity assessment — Requirements for the operation of various types of bodies performing inspection
  • En español: Evaluación de la conformidad — Requisitos para el funcionamiento de diferentes tipos de organismos que realizan la inspección
  • Contenido: Requisitos de competencia, imparcialidad y funcionamiento de los organismos de inspección.
  • Citada en: CIR (UE) 2024/2981; CIR (UE) 2025/2162

EN ISO/IEC 17021-1:2015

  • Versión citada: 2015
  • Título: Conformity assessment — Requirements for bodies providing audit and certification of management systems — Part 1: Requirements
  • En español: Evaluación de la conformidad — Requisitos para los organismos que realizan la auditoría y la certificación de sistemas de gestión — Parte 1: Requisitos
  • Contenido: Requisitos de los organismos que auditan y certifican sistemas de gestión. Los actos la usan también para las auditorías de seguimiento y de renovación.
  • Citada en: CIR (UE) 2024/2981; CIR (UE) 2025/2162

EN ISO/IEC 17025:2017

  • Versión citada: 2017
  • Título: General requirements for the competence of testing and calibration laboratories
  • En español: Requisitos generales para la competencia de los laboratorios de ensayo y calibración
  • Contenido: Requisitos de los laboratorios que realizan ensayos, aplicables a los laboratorios de evaluación de seguridad.
  • Citada en: CIR (UE) 2024/2981; CIR (UE) 2025/2162

EN ISO/IEC 17029:2019

  • Versión citada: 2019
  • Título: Conformity assessment — General principles and requirements for validation and verification bodies
  • En español: Evaluación de la conformidad — Principios generales y requisitos para los organismos de validación y verificación
  • Contenido: Requisitos de los organismos que validan o verifican declaraciones, aplicables a la verificación de las afirmaciones del proveedor de la cartera.
  • Citada en: CIR (UE) 2024/2981

EN ISO/IEC 17065:2012

  • Versión citada: 2012
  • Título: Conformity assessment — Requirements for bodies certifying products, processes and services
  • En español: Evaluación de la conformidad — Requisitos para organismos que certifican productos, procesos y servicios
  • Contenido: Norma base de los organismos de certificación de productos y servicios. Rige tanto a los organismos que certifican carteras como a los que evalúan a los prestadores cualificados.
  • Citada en: CIR (UE) 2024/2981 (plan de evaluación, apartado 7.4.1); CIR (UE) 2025/2162

EN ISO/IEC 17067:2013

  • Versión citada: 2013
  • Título: Conformity assessment — Fundamentals of product certification and guidelines for product certification schemes
  • En español: Evaluación de la conformidad — Fundamentos de la certificación de producto y directrices para los esquemas de certificación de producto
  • Contenido: Tipología de los esquemas de certificación. Los esquemas nacionales de certificación de carteras deben ser de «tipo 6» (producto, proceso y servicio, con vigilancia).
  • Citada en: CIR (UE) 2024/2981; CIR (UE) 2025/2162

ISO/IEC 18013-5:2021

  • Versión citada: 2021
  • Título: Personal identification — ISO-compliant driving licence — Part 5: Mobile driving licence (mDL) application
  • En español: Identificación personal — Permiso de conducción conforme a ISO — Parte 5: Aplicación del permiso de conducción móvil (mDL)
  • Contenido: Define el formato «mdoc» (CBOR/COSE) y la presentación en proximidad (QR, NFC, BLE) del permiso de conducir móvil. Es uno de los dos formatos obligatorios del PID y la base de la presentación presencial.
  • Citada en: CIR (UE) 2024/2977 (formato del PID); CIR (UE) 2024/2982 (protocolos); CIR (UE) 2026/1731

ISO/IEC TS 18013-7:2024 / ISO/IEC 18013-7:2025

  • Versión citada: 2024 (TS) en 2024/2982; 2025 en 2026/1731
  • Título: Personal identification — ISO-compliant driving licence — Part 7: Mobile driving licence (mDL) add-on functions
  • En español: Identificación personal — Permiso de conducción conforme a ISO — Parte 7: Funciones adicionales del permiso de conducción móvil (mDL)
  • Contenido: Extiende la parte 5 para la presentación en remoto (por internet) de los datos mdoc. El anexo C, que se apoya en la Digital Credentials API de los navegadores, es el que se aplica a la cartera.
  • Citada en: CIR (UE) 2024/2982 (versión TS de 2024); CIR (UE) 2026/1731 (versión de 2025, anexo C)

ISO/IEC 19794-5

  • Versión citada: (sin versión)
  • Título: Information technology — Biometric data interchange formats — Part 5: Face image data
  • En español: Tecnologías de la información — Formatos de intercambio de datos biométricos — Parte 5: Datos de imagen facial
  • Contenido: Formato y requisitos de calidad de la imagen facial. Se mantiene por compatibilidad para el retrato del PID.
  • Citada en: CIR (UE) 2024/2977 (como «ISO 19794-5»); CIR (UE) 2026/1731

EN ISO/IEC 27001:2022

  • Versión citada: 2022
  • Título: Information security, cybersecurity and privacy protection — Information security management systems — Requirements
  • En español: Seguridad de la información, ciberseguridad y protección de la privacidad — Sistemas de gestión de la seguridad de la información — Requisitos
  • Contenido: Requisitos del sistema de gestión de la seguridad de la información (SGSI). Se admite como certificación reutilizable en la certificación de carteras y para los nodos del marco de interoperabilidad de la identificación electrónica.
  • Citada en: CIR (UE) 2024/2981; CIR (UE) 2025/1568 (revisiones inter pares de los esquemas de identificación electrónica)

EN ISO/IEC 30111:2019

  • Versión citada: 2019
  • Título: Information technology — Security techniques — Vulnerability handling processes
  • En español: Tecnologías de la información — Técnicas de seguridad — Procesos de gestión de vulnerabilidades
  • Contenido: Procesos para investigar, clasificar y corregir vulnerabilidades notificadas. El titular del certificado de la cartera debe tenerla en cuenta en su política de gestión de vulnerabilidades.
  • Citada en: CIR (UE) 2024/2981

ISO/IEC 39794-5

  • Versión citada: (sin versión)
  • Título: Information technology — Extensible biometric data interchange formats — Part 5: Face image data
  • En español: Tecnologías de la información — Formatos extensibles de intercambio de datos biométricos — Parte 5: Datos de imagen facial
  • Contenido: Sucesora de la ISO/IEC 19794-5, con formatos extensibles. Es la referencia principal para el retrato del PID (imagen frontal completa).
  • Citada en: CIR (UE) 2024/2977 (como «ISO 39794»); CIR (UE) 2026/1731

Bloque 2. Normas del resto de servicios de confianza

Normas CEN

CEN/TS 18170:2025

  • Versión citada: 2025
  • Título: Functional and security requirements for electronic archiving services
  • En español: Requisitos funcionales y de seguridad de los servicios de archivo electrónico
  • Contenido: Especificación técnica de CEN que define los requisitos de organización, procesos y seguridad de los prestadores de servicios de archivo electrónico, incluida la conservación de la integridad, autenticidad y legibilidad de los documentos a lo largo del tiempo.
  • Citada en: CIR (UE) 2025/2532 (archivo electrónico cualificado, con adaptaciones); CIR (UE) 2025/2162 (anexo II, archivo electrónico y libros registro electrónicos)

CEN/TS 419261:2015

  • Versión citada: 2015
  • Título: Security requirements for trustworthy systems managing certificates and time-stamps
  • En español: Requisitos de seguridad de los sistemas fiables que gestionan certificados y sellos de tiempo
  • Contenido: Requisitos de seguridad de los sistemas que utilizan los prestadores para generar y gestionar certificados (registro, emisión, revocación) y sellos de tiempo, con base en perfiles de protección y criterios de evaluación de seguridad.
  • Citada en: CIR (UE) 2025/1943 (certificados cualificados de firma y de sello)

Normas ETSI

ETSI TS 103 171

  • Versión citada: v2.1.1
  • Título: Electronic Signatures and Infrastructures (ESI); XAdES Baseline Profile
  • En español: Firmas electrónicas e infraestructuras (ESI); perfil básico XAdES
  • Contenido: Perfil «baseline» anterior de las firmas XAdES (XML). Se mantiene como formato admitido para facilitar la transición desde la Decisión 2015/1506.
  • Citada en: CIR (UE) 2026/248 (anexo II, formatos heredados)

ETSI TS 103 172

  • Versión citada: (versión según el anexo II)
  • Título: Electronic Signatures and Infrastructures (ESI); PAdES Baseline Profile
  • En español: Firmas electrónicas e infraestructuras (ESI); perfil básico PAdES
  • Contenido: Perfil «baseline» anterior de las firmas PAdES (PDF), admitido de forma transitoria junto a la norma EN 319 142-1.
  • Citada en: CIR (UE) 2026/248 (anexo II, formatos heredados)

ETSI TS 103 173

  • Versión citada: (versión según el anexo II)
  • Título: Electronic Signatures and Infrastructures (ESI); CAdES Baseline Profile
  • En español: Firmas electrónicas e infraestructuras (ESI); perfil básico CAdES
  • Contenido: Perfil «baseline» anterior de las firmas CAdES (CMS), admitido de forma transitoria junto a la norma EN 319 122-1.
  • Citada en: CIR (UE) 2026/248 (anexo II, formatos heredados)

ETSI TS 103 174

  • Versión citada: (versión según el anexo II)
  • Título: Electronic Signatures and Infrastructures (ESI); ASiC Baseline Profile
  • En español: Firmas electrónicas e infraestructuras (ESI); perfil básico ASiC
  • Contenido: Perfil «baseline» anterior de los contenedores de firma asociada ASiC, admitido de forma transitoria junto a las normas EN 319 162-1/-2.
  • Citada en: CIR (UE) 2026/248 (anexo II, formatos heredados)

ETSI TS 119 101

  • Versión citada: V1.1.1 (2016-03)
  • Título: Electronic Signatures and Infrastructures (ESI); Policy and security requirements for applications for signature creation and signature validation
  • En español: Firmas electrónicas e infraestructuras (ESI); requisitos de política y seguridad para aplicaciones de creación y validación de firmas
  • Contenido: Requisitos de seguridad para las aplicaciones de software que crean y validan firmas: gestión del documento a firmar, presentación al firmante, integridad del proceso y control de los componentes.
  • Citada en: CIR (UE) 2025/1942 (servicios cualificados de validación); CIR (UE) 2025/1945 (validación de firmas y sellos); CIR (UE) 2025/1946 (preservación)

ETSI TS 119 102-2

  • Versión citada: V1.4.1 (2023-06)
  • Título: Electronic Signatures and Infrastructures (ESI); Procedures for Creation and Validation of AdES Digital Signatures; Part 2: Signature Validation Report
  • En español: Firmas electrónicas e infraestructuras (ESI); procedimientos de creación y validación de firmas digitales AdES; parte 2: informe de validación de firma
  • Contenido: Define la estructura y la semántica (XML) del informe de validación, de modo que el resultado y sus motivos sean legibles por máquinas e interoperables entre validadores.
  • Citada en: CIR (UE) 2025/1942; CIR (UE) 2025/1945; CIR (UE) 2025/2162 (anexo II)

ETSI TS 119 172-1

  • Versión citada: (citada por cláusulas)
  • Título: Electronic Signatures and Infrastructures (ESI); Signature Policies; Part 1: Building blocks and table of contents for human readable signature policy documents
  • En español: Firmas electrónicas e infraestructuras (ESI); políticas de firma; parte 1: componentes básicos e índice de contenidos de los documentos de política de firma legibles por personas
  • Contenido: Estructura de las políticas de firma y de validación. Los actos se remiten a ella para fijar restricciones concretas, como el modo de comprobar la revocación de los certificados.
  • Citada en: CIR (UE) 2025/1942; CIR (UE) 2025/1945; CIR (UE) 2025/1946

ETSI TS 119 172-4

  • Versión citada: V1.1.1 (2021-05)
  • Título: Electronic Signatures and Infrastructures (ESI); Signature Policies; Part 4: Signature applicability rules (validation policy) for European qualified electronic signatures/seals using trusted lists
  • En español: Firmas electrónicas e infraestructuras (ESI); políticas de firma; parte 4: reglas de aplicabilidad (política de validación) para firmas y sellos electrónicos cualificados europeos mediante listas de confianza
  • Contenido: Política de validación que permite determinar si una firma o un sello es cualificado a partir de las listas de confianza de la UE.
  • Citada en: CIR (UE) 2025/1942; CIR (UE) 2025/1945; CIR (UE) 2025/1946; CIR (UE) 2025/2162 (anexo II)

ETSI TS 119 411-5

  • Versión citada: V2.1.1 (2025-02)
  • Título: Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 5: Specification for the coexistence of EU qualified website authentication certificates and publicly-trusted website certificates
  • En español: Firmas electrónicas e infraestructuras (ESI); requisitos de política y seguridad para los prestadores que expiden certificados; parte 5: especificación para la coexistencia de los certificados cualificados de autenticación de sitios web de la UE y los certificados de sitio web de confianza pública
  • Contenido: Define cómo se presentan los QWAC junto a los certificados TLS reconocidos por los navegadores, incluidos los QWAC vinculados a TLS y los no vinculados a TLS, para cumplir el artículo 45 de eIDAS2.
  • Citada en: CIR (UE) 2025/2527 (QWAC); CIR (UE) 2025/2162 (anexo II)

ETSI TS 119 431-1

  • Versión citada: V1.3.1 (2024-12)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for trust service providers; Part 1: TSP service components operating a remote QSCD / SCDev
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); requisitos de política y seguridad para los prestadores; parte 1: componentes de servicio del prestador que operan un dispositivo cualificado o un dispositivo de creación de firma a distancia
  • Contenido: Requisitos del componente que gestiona dispositivos de creación de firma o sello a distancia (firma «en la nube»), incluida la activación de la clave bajo control exclusivo del firmante.
  • Citada en: CIR (UE) 2025/1567 (gestión a distancia de dispositivos); CIR (UE) 2025/2162 (anexo II)

ETSI TS 119 441

  • Versión citada: V1.2.1 (2023-10)
  • Título: Electronic Signatures and Infrastructures (ESI); Policy requirements for TSP providing signature validation services
  • En español: Firmas electrónicas e infraestructuras (ESI); requisitos de política para los prestadores que ofrecen servicios de validación de firmas
  • Contenido: Requisitos de organización y seguridad del servicio de validación: política de validación, firma de los informes y gestión de evidencias.
  • Citada en: CIR (UE) 2025/1942; CIR (UE) 2025/2162 (anexo II)

ETSI TS 119 442

  • Versión citada: (sin versión)
  • Título: Electronic Signatures and Infrastructures (ESI); Protocol profiles for trust service providers providing AdES digital signature validation services
  • En español: Firmas electrónicas e infraestructuras (ESI); perfiles de protocolo para los prestadores que ofrecen servicios de validación de firmas digitales AdES
  • Contenido: Protocolo de petición y respuesta entre el cliente y el servicio de validación.
  • Citada en: CIR (UE) 2025/2162 (anexo II)

ETSI TS 119 471

  • Versión citada: V1.1.1 (2025-05)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Policy and Security requirements for Providers of Electronic Attestation of Attributes Services
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); requisitos de política y seguridad para los proveedores de servicios de declaraciones electrónicas de atributos
  • Contenido: Requisitos de organización y seguridad para los proveedores de DEA y DECA, incluida la verificación de los atributos contra fuentes auténticas.
  • Citada en: CIR (UE) 2026/1735 (modifica el CIR (UE) 2025/1569, con adaptaciones); CIR (UE) 2025/2162 (anexo II)

ETSI TS 119 478

  • Versión citada: V1.1.1 (2026-01)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Specification of interfaces related to Authentic Sources
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); especificación de las interfaces relacionadas con las fuentes auténticas
  • Contenido: Interfaces para que los proveedores de DECA verifiquen atributos ante las fuentes auténticas y reciban resultados de verificación firmados o sellados.
  • Citada en: CIR (UE) 2026/1735 (modifica el CIR (UE) 2025/1569)

ETSI TS 119 495

  • Versión citada: V1.7.1 (2024-07)
  • Título: Electronic Signatures and Infrastructures (ESI); Sector Specific Requirements; Certificate Profiles and TSP Policy Requirements for Open Banking
  • En español: Firmas electrónicas e infraestructuras (ESI); requisitos sectoriales; perfiles de certificado y requisitos de política del prestador para la banca abierta
  • Contenido: Perfil de los certificados cualificados (QWAC y sellos) para proveedores de servicios de pago en el marco de PSD2 y la banca abierta, con sus roles y la autoridad competente.
  • Citada en: CIR (UE) 2025/2527 (QWAC); CIR (UE) 2025/2162 (anexo II)

ETSI TS 119 511

  • Versión citada: V1.1.1 (2019-06)
  • Título: Electronic Signatures and Infrastructures (ESI); Policy and security requirements for trust service providers providing long-term preservation of digital signatures or general data using digital signature techniques
  • En español: Firmas electrónicas e infraestructuras (ESI); requisitos de política y seguridad para los prestadores que ofrecen preservación a largo plazo de firmas digitales o de datos mediante técnicas de firma digital
  • Contenido: Requisitos de los servicios de preservación que mantienen la validez de las firmas a lo largo del tiempo (aumentos, resellado, evidencias de preservación).
  • Citada en: CIR (UE) 2025/1946 (preservación cualificada); CIR (UE) 2025/2162 (anexo II; en archivo electrónico la cita por error como «EN 119 511»)

ETSI TS 119 512

  • Versión citada: (sin versión)
  • Título: Electronic Signatures and Infrastructures (ESI); Protocols for trust service providers providing long-term data preservation services
  • En español: Firmas electrónicas e infraestructuras (ESI); protocolos para los prestadores que ofrecen servicios de preservación de datos a largo plazo
  • Contenido: Protocolo de interacción entre clientes y servicios de preservación (envío, recuperación y obtención de evidencias).
  • Citada en: CIR (UE) 2025/2162 (anexo II, servicios de preservación)

ETSI TS 119 612

  • Versión citada: V2.3.1 (2024-11); v2.4.1 en 2025/2162
  • Título: Electronic Signatures and Infrastructures (ESI); Trusted Lists
  • En español: Firmas electrónicas e infraestructuras (ESI); listas de confianza
  • Contenido: Formato y semántica de las listas de confianza nacionales y de la lista de listas (LOTL) de la Comisión.
  • Citada en: CIR (UE) 2025/1942; 2025/1945; 2025/1946; CID (UE) 2025/2164 (versión de la norma de la plantilla común); CIR (UE) 2025/2162 (anexo II, v2.4.1)

ETSI EN 301 549

  • Versión citada: (sin versión)
  • Título: Accessibility requirements for ICT products and services
  • En español: Requisitos de accesibilidad de productos y servicios TIC
  • Contenido: Norma europea armonizada de accesibilidad, que permite comprobar que los servicios de confianza pueden ser usados por personas con discapacidad (artículo 15 de eIDAS).
  • Citada en: CIR (UE) 2025/2162 (anexo II, en casi todos los servicios cualificados; en archivo electrónico aparece por error como «TS 301 549»)

ETSI EN 319 102-1

  • Versión citada: V1.4.1 (2024-06)
  • Título: Electronic Signatures and Infrastructures (ESI); Procedures for Creation and Validation of AdES Digital Signatures; Part 1: Creation and Validation
  • En español: Firmas electrónicas e infraestructuras (ESI); procedimientos de creación y validación de firmas digitales AdES; parte 1: creación y validación
  • Contenido: Norma central del algoritmo de validación de firmas avanzadas: modelo de validación, bloques de comprobación (formato, identificación del firmante, cadena de certificados, revocación, sellos de tiempo, validación a largo plazo) y resultados (TOTAL-PASSED, TOTAL-FAILED, INDETERMINATE). Los actos aclaran que las referencias a la antigua TS 119 102-1 se entienden hechas a esta EN.
  • Citada en: CIR (UE) 2025/1942; CIR (UE) 2025/1945; CIR (UE) 2025/1946; CIR (UE) 2025/2162 (anexo II, servicios de validación)

ETSI EN 319 403-1

  • Versión citada: v2.3.1
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Trust Service Provider Conformity Assessment; Part 1: Requirements for conformity assessment bodies assessing Trust Service Providers
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); evaluación de la conformidad de los prestadores de servicios de confianza; parte 1: requisitos para los organismos de evaluación de la conformidad que evalúan a los prestadores
  • Contenido: Completa la ISO/IEC 17065 con requisitos específicos para los organismos que auditan a prestadores: competencia de los auditores, proceso de auditoría y contenido del informe de evaluación.
  • Citada en: CIR (UE) 2025/2162 (acreditación de organismos de evaluación de la conformidad; régimen transitorio para los acreditados con la EN 319 403 v2.2.2)

ETSI EN 319 411-2

  • Versión citada: V2.6.1 (2025-06)
  • Título: Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 2: Requirements for trust service providers issuing EU qualified certificates
  • En español: Firmas electrónicas e infraestructuras de confianza (ESI); requisitos de política y seguridad para los prestadores que expiden certificados; parte 2: requisitos para los prestadores que expiden certificados cualificados de la UE
  • Contenido: Políticas de certificación de los certificados cualificados (QCP-n, QCP-l, QCP-n-qscd, QCP-l-qscd, QCP-w) y requisitos adicionales a la parte 1.
  • Citada en: CIR (UE) 2025/1943; CIR (UE) 2025/2527 (QWAC); CIR (UE) 2025/1942 (referencia informativa); CIR (UE) 2025/2162 (anexo II)

ETSI EN 319 412-4

  • Versión citada: (sin versión)
  • Título: Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 4: Certificate profile for web site certificates
  • En español: Firmas electrónicas e infraestructuras (ESI); perfiles de certificado; parte 4: perfil de certificado para certificados de sitio web
  • Contenido: Perfil de los certificados de autenticación de sitios web, base de los QWAC.
  • Citada en: CIR (UE) 2025/2162 (anexo II, certificados cualificados de autenticación de sitios web)

ETSI EN 319 421

  • Versión citada: V1.3.1 (2025-07)
  • Título: Electronic Signatures and Infrastructures (ESI); Policy and Security Requirements for Trust Service Providers issuing Time-Stamps
  • En español: Firmas electrónicas e infraestructuras (ESI); requisitos de política y seguridad para los prestadores que expiden sellos de tiempo
  • Contenido: Requisitos de las autoridades de sellado de tiempo: sincronización con UTC, precisión, gestión de claves y política de sellado.
  • Citada en: CIR (UE) 2025/1929 (sellos cualificados de tiempo, con adaptaciones); CIR (UE) 2025/2532 (archivo electrónico); CIR (UE) 2025/2162 (anexo II)

ETSI EN 319 422

  • Versión citada: V1.1.1 (2016-03)
  • Título: Electronic Signatures and Infrastructures (ESI); Time-stamping protocol and time-stamp token profiles
  • En español: Firmas electrónicas e infraestructuras (ESI); protocolo de sellado de tiempo y perfiles del token de sello de tiempo
  • Contenido: Perfil del protocolo de sellado de tiempo (RFC 3161) y del token resultante.
  • Citada en: CIR (UE) 2025/1929; CIR (UE) 2025/2162 (anexo II)

ETSI EN 319 521

  • Versión citada: V1.1.1 (2019-02)
  • Título: Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Electronic Registered Delivery Service Providers
  • En español: Firmas electrónicas e infraestructuras (ESI); requisitos de política y seguridad para los prestadores de servicios de entrega electrónica certificada
  • Contenido: Requisitos de organización y seguridad de los prestadores de entrega electrónica certificada.
  • Citada en: CIR (UE) 2025/1944 (QERDS); CIR (UE) 2025/2162 (anexo II)

ETSI EN 319 522-1 a 319 522-4

  • Versión citada: V1.2.1 (2024-01)
  • Título: Electronic Signatures and Infrastructures (ESI); Electronic Registered Delivery Services; Part 1: Framework and Architecture; Part 2: Semantic contents; Part 3: Formats; Part 4: Bindings
  • En español: Firmas electrónicas e infraestructuras (ESI); servicios de entrega electrónica certificada; parte 1: marco y arquitectura; parte 2: contenidos semánticos; parte 3: formatos; parte 4: vinculaciones
  • Contenido: Arquitectura, evidencias, formatos de mensajes y protocolos de los servicios de entrega electrónica certificada.
  • Citada en: CIR (UE) 2025/1944; CIR (UE) 2025/2162 (anexo II)

ETSI EN 319 531 y EN 319 532

  • Versión citada: (sin versión)
  • Título: Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Registered Electronic Mail (REM) Service Providers; Registered Electronic Mail (REM) Services
  • En español: Firmas electrónicas e infraestructuras (ESI); requisitos de política y seguridad para los prestadores de correo electrónico certificado (REM); servicios de correo electrónico certificado (REM)
  • Contenido: Versión de la entrega electrónica certificada basada en correo electrónico (REM): requisitos del prestador y perfiles técnicos.
  • Citada en: CIR (UE) 2025/2162 (anexo II, QERDS)

Normas ISO e ISO/IEC

ISO 14641

  • Versión citada: (sin versión)
  • Título: Electronic document management — Design and operation of an information system for the preservation of electronic documents — Specifications
  • En español: Gestión de documentos electrónicos — Diseño y explotación de un sistema de información para la conservación de documentos electrónicos — Especificaciones
  • Contenido: Requisitos técnicos y organizativos de los sistemas de archivo electrónico que garantizan la integridad y la trazabilidad de los documentos.
  • Citada en: CIR (UE) 2025/2162 (anexo II, archivo electrónico)

ISO 14721:2025

  • Versión citada: 2025
  • Título: Space data system practices — Reference model for an open archival information system (OAIS)
  • En español: Prácticas de los sistemas de datos espaciales — Modelo de referencia para un sistema abierto de información de archivo (OAIS)
  • Contenido: Modelo de referencia OAIS de preservación digital a largo plazo (ingreso, almacenamiento, gestión de datos, acceso y planificación de la preservación), nacido en el ámbito espacial y adoptado por los archivos de todo el mundo.
  • Citada en: CIR (UE) 2025/2532 (archivo electrónico); CIR (UE) 2025/2162 (anexo II)

EN ISO/IEC 17011:2017

  • Versión citada: 2017
  • Título: Conformity assessment — Requirements for accreditation bodies accrediting conformity assessment bodies
  • En español: Evaluación de la conformidad — Requisitos para los organismos de acreditación que realizan la acreditación de organismos de evaluación de la conformidad
  • Contenido: Requisitos para las entidades nacionales de acreditación (en España, ENAC).
  • Citada en: CIR (UE) 2025/2162

ISO 23257:2022

  • Versión citada: 2022
  • Título: Blockchain and distributed ledger technologies — Reference architecture
  • En español: Cadena de bloques y tecnologías de registro distribuido — Arquitectura de referencia
  • Contenido: Arquitectura de referencia de las tecnologías de registro distribuido. Su cláusula 9 sirve para describir el sistema DLT de los libros registro electrónicos cualificados.
  • Citada en: CIR (UE) 2025/2531 (libros registro electrónicos); CIR (UE) 2025/2162 (anexo II)

ISO/TS 23635:2022

  • Versión citada: 2022
  • Título: Blockchain and distributed ledger technologies — Guidelines for governance
  • En español: Cadena de bloques y tecnologías de registro distribuido — Directrices de gobernanza
  • Contenido: Directrices sobre la gobernanza de los sistemas DLT, aplicables a las políticas y prácticas del servicio de libro registro.
  • Citada en: CIR (UE) 2025/2531; CIR (UE) 2025/2162 (anexo II)

Notas y cautelas

  • Versiones. Cada acto fija una versión concreta de la norma, y a veces con adaptaciones o exclusiones de cláusulas. Antes de usar una referencia en un pliego, una política de certificación o una auditoría, conviene comprobar la versión y las adaptaciones en el anexo del acto publicado en el DOUE.
  • Erratas en los actos. Algunas referencias aparecen con errores tipográficos en el DOUE: «EN 3191 22-1» (CIR 2024/2979), «EN 310 401», «TS 301 549», «EN 119 511» y «EN 319 182-1» (anexo II del CIR 2025/2162). En este catálogo se han asignado a la norma correcta.
  • Especificaciones que no son de ETSI, CEN ni ISO. Los actos también citan especificaciones de otros organismos que no se incluyen aquí: RFC del IETF (por ejemplo, RFC 3161, RFC 5280, RFC 7515, RFC 7519, RFC 8392 o RFC 8949), el modelo W3C Verifiable Credentials Data Model 1.1, las especificaciones OpenID4VCI y OpenID4VP, la especificación del Cloud Signature Consortium (v2.0), FIPS PUB 140-3 y el documento Agreed Cryptographic Mechanisms del grupo de criptografía del ECCG publicado por ENISA, al que remite el nuevo anexo Ia del CIR 2024/2979.
  • Títulos recientes. Las especificaciones ETSI publicadas en 2025 y 2026 (TS 119 411-8, TS 119 412-6, TS 119 432 v1.3.1, TS 119 472-1/-2/-3, TS 119 475 y TS 119 478), así como la CEN/TS 18170:2025, conviene cotejarlas con el catálogo del organismo, porque sus títulos pueden variar entre versiones.

Como de costumbre, iré actualizando este catálogo a medida que se publiquen nuevos actos de ejecución o correcciones de errores.

Servicios Profesionales de EADTrust

La recopilación y el análisis de esta información forman parte de los Servicios Profesionales de EADTrust. Si tu organización, sea una administración pública o una empresa, está valorando proyectos relacionados con la Cartera de Identidad Digital Europea, las declaraciones electrónicas de atributos o la adaptación a eIDAS2, podemos acompañarte en el análisis normativo, el diseño y la implantación. Escríbenos a info@eadtrust.com o llámanos al 91 716 05 55. Más información en www.eadtrust.eu.

Cartera de Identidad Digital Europea: nuevo borrador de Real Decreto, a información pública (y con prisas)


El Ministerio para la Transformación Digital y de la Función Pública ha abierto el trámite de audiencia e información pública sobre el proyecto de real decreto por el que se regula el ecosistema de cartera europea de identidad digital en España de acuerdo con el marco europeo de identidad digital. Es la norma que debe completar en España el Reglamento eIDAS 2 en lo relativo a la cartera, y llega con muy poco margen: el plazo para enviar observaciones vence el 13 de octubre de 2026 y la cartera debe estar disponible, por mandato europeo, antes del 24 de diciembre de 2026.

He dedicado unos días a leer el borrador (versión V-12, de 29 de septiembre de 2026) y a compararlo con lo que ya han aprobado otros Estados miembros. Resumo aquí lo que regula, lo que echo en falta y cómo lo han resuelto fuera de nuestras fronteras, con la esperanza de animar a más personas y entidades a participar en el trámite.

Qué regula el proyecto

El proyecto es, sobre todo, una norma de designación de autoridades. En trece artículos, tres disposiciones adicionales y tres finales, reparte los papeles que el Reglamento (UE) n.º 910/2014, modificado por el Reglamento (UE) 2024/1183, encomienda a los Estados miembros:

FunciónOrganismo designadoArtículo
Proveedor de la cartera del EstadoAgencia Estatal de Administración Digital (AEAD)7
Punto de contacto únicoAEAD2
Organismo de supervisiónDirección General de Ordenación de los Servicios de Digitalización y de Comunicación Audiovisual (DGOSDCA)3
Propietario del esquema de certificación y organismo certificadorCentro Criptológico Nacional (CCN)4 y 9
Acreditación de organismos de evaluación de la conformidadENAC5
Correspondencia transfronteriza de la identidadAEAD, Agencia Tributaria y Dirección General de la Policía6
Registro nacional de partes usuarias de las carterasAEAD11
Autorización de proveedores de certificados de acceso y de registroDGOSDCA12
Catálogo nacional de fuentes auténticasDirección General del Dato13

Las disposiciones adicionales regulan la verificación previa de quienes expidan declaraciones electrónicas cualificadas de atributos y de los organismos públicos que expidan declaraciones electrónicas de atributos desde una fuente auténtica, y la representación de España en el Grupo de Cooperación sobre la Identidad Digital Europea.

Un plazo demasiado corto

El anuncio se publicó el 1 de octubre de 2026 y las observaciones pueden enviarse hasta el 13 oct 2026 a audienciapublica.prdcarteradigital@digital.gob.es. Son siete días hábiles, contando con que el 12 de octubre es festivo: el mínimo que permite la Ley del Gobierno.

La razón está en el propio anuncio. El Consejo de Ministros acordó el 29 de septiembre de 2026 la tramitación urgente del proyecto (art. 27.1.a de la Ley 50/1997), lo que suprime la consulta pública previa y reduce la audiencia a siete días hábiles (art. 27.2.b). La primera ocasión que tiene la sociedad para opinar sobre la norma es también la última, y dura poco más de una semana.

El anuncio añade algunos detalles prácticos. Las aportaciones deben identificar a su autor (nombre o razón social, datos de contacto y, en su caso, representación). Se consideran públicas, salvo las partes que se marquen y justifiquen como confidenciales. Junto al proyecto se publica la Memoria del Análisis de Impacto Normativo. Y llama la atención que el órgano responsable sea la Agencia Estatal de Administración Digital, la misma que el proyecto designa como proveedor de la cartera, punto de contacto único y registrador de partes usuarias.

Llegados a esta fecha, se entiende la urgencia: el Reglamento obliga a proporcionar al menos una cartera antes del 24 de diciembre de 2026, y las partes usuarias privadas obligadas deberán aceptarla antes del 24 de diciembre de 2027. Pero la prisa no debería reducir la participación a un trámite formal. Esta propuesta debería haberse publicado con más antelación, pero aprovechemos el escaso margen.

Mi manía: «cartera de identidad digital europea»

Quienes me leen ya saben que escribo «Cartera de Identidad Digital Europea» y no «cartera europea de identidad digital», que es la traducción oficial del artículo 3.42 del Reglamento. Es una manía, lo reconozco, pero tiene fundamento: lo europeo es la identidad, no la cartera. En inglés, European Digital Identity Wallet, el bloque European Digital Identity califica entero a Wallet.

La propia versión española del Reglamento me da la razón en otros pasajes:

  • habla del «Grupo de Cooperación sobre la Identidad Digital Europea» (art. 46 sexies);
  • define la «etiqueta de confianza de la UE para la cartera de identidad digital» (art. 3.50);
  • y usa «marco europeo de identidad digital», donde el adjetivo sí corresponde al marco.

No me hago ilusiones: el francés, el italiano o el alemán también ponen el adjetivo «europeo» junto a la cartera. Por eso no propongo cambiar la definición por las bravas, sino una cláusula de equivalencia en el real decreto y una corrección de la versión española del Reglamento. Fuera de esta excepción, defiendo lo contrario: que el real decreto respete la terminología oficial, cosa que hoy no siempre hace. Usa «autenticación fuerte» en lugar de «autenticación reforzada de usuario», habla de carteras «autorizadas» cuando el Reglamento dice «proporcionadas» y llama de cuatro maneras distintas al organismo de supervisión.

Lo que echo en falta y lo que me choca

Un real decreto que solo designa autoridades se queda corto. Estas son las carencias que me parecen más relevantes:

  1. Supervisor y supervisado bajo el mismo techo. El artículo 46 bis exige que el organismo de supervisión actúe de forma independiente, pero DGOSDCA y AEAD pertenecen al mismo Ministerio.
  2. Un punto de contacto único que no es único. El artículo 46 quater pide uno solo para servicios de confianza, carteras y sistemas de identificación notificados; el proyecto lo designa solo para las carteras y no coincide con el supervisor de los Prestadores Cualificados de Servicios de Confianza.
  3. Nada sobre la verificación de atributos frente a fuentes auténticas. El artículo 45 sexies obliga a que los prestadores cualificados puedan contrastar domicilio, edad, titulaciones, poderes o datos societarios con la fuente correspondiente. Sin ese mecanismo no habrá mercado de declaraciones electrónicas cualificadas de atributos.
  4. Personas jurídicas y representación, ausentes. El Reglamento incluye a las personas jurídicas y a quienes actúan en nombre de otros; el proyecto solo contempla titulares de DNI o NIE.
  5. Solo la cartera del Estado. No hay procedimiento para reconocer carteras proporcionadas por mandato o de forma independiente, como permite el artículo 5 bis.2. No se indica la posibilidad de certificar las Carteras en esquemas de certificación de otros países.
  6. El número de DNI o NIE como atributo obligatorio, que facilita vincular la actividad del usuario entre partes usuarias. La definición del PID indica que este número es opcional y probablemente no se incluirá en relaciones con ciudadanos de otros países.
  7. Un requisito que el Reglamento no exige: condicionar la cualificación de los prestadores de declaraciones cualificadas a la conformidad con el esquema de certificación de las carteras.
  8. Barreras a prestadores de otros Estados miembros para expedir certificados de acceso de parte usuaria.

Qué han hecho otros Estados miembros

Varios países ya han aprobado o tramitan su normativa, casi siempre con rango de ley y con bastante más contenido que la mera designación de autoridades. Doy el título en español y en la lengua original, y un resumen de lo principal. Los artículos citados proceden de los textos consultados y conviene contrastarlos con la publicación oficial.

Alemania — proyecto de ley en el Bundestag

Proyecto de Ley de aplicación de las disposiciones de la Unión sobre la Cartera de Identidad Digital Europea y de modificación de otras disposiciones (DIdG) — Entwurf eines Gesetzes zur Durchführung der unionsrechtlichen Vorschriften über die Europäische Brieftasche für die Digitale Identität sowie zur Änderung anderer Rechtsvorschriften, BT-Drs. 21/7408, de 29 de julio de 2026. Audiencia pública en el Bundestag el 6 de octubre de 2026.

  • Tres modelos de provisión a elección del Ministerio Federal de Digitalización: directa, por contrato público o reconociendo carteras privadas.
  • La Agencia Federal de Redes (BNetzA) es organismo de supervisión y punto de contacto único; la Oficina Federal de Administración (BVA), registrador de partes usuarias; la Oficina Federal de Seguridad de la Información (BSI), responsable de la certificación y de las violaciones de seguridad.
  • Datos de identificación de personas jurídicas a partir de los registros mercantil, de cooperativas, de fundaciones y de asociaciones; la representación se acredita con declaraciones electrónicas de atributos.
  • El emisor de los datos de identificación no puede ser el proveedor de la cartera, y este debe ser técnicamente incapaz de conocer su contenido.
  • En 24 meses, las autoridades federales deberán expedir sus documentos como declaraciones electrónicas de atributos, con valor equivalente a la forma escrita.
  • Multas de hasta 5 millones de euros o el 1 % del volumen de negocio (Ley de servicios de confianza).

Finlandia — en vigor desde el 1 de octubre de 2026

Proyecto de ley del Gobierno sobre la legislación complementaria del Reglamento de la UE relativo a la identificación electrónica transfronteriza, los servicios de confianza y la identidad digital europea — Hallituksen esitys eduskunnalle rajat ylittävää sähköistä tunnistamista, luottamuspalveluita ja eurooppalaista digitaalista identiteettiä koskevaa EU:n asetusta täydentäväksi lainsäädännöksi, HE 17/2026 vp. Incluye una nueva Laki digitaalisesta henkilöllisyystodistuksesta (Ley del documento de identidad digital).

  • Proveedor: la Agencia de Servicios Digitales y de Datos de Población (DVV). Supervisor y registrador: la Agencia de Transportes y Comunicaciones (Traficom), un organismo distinto.
  • Se admiten carteras privadas que cumplan los requisitos.
  • La Oficina de Patentes y Registros expide los datos de identificación de las personas jurídicas desde el Registro Mercantil.
  • Primera credencial: un certificado de identidad digital derivado del pasaporte o del documento de identidad.
  • Cartera gratuita y voluntaria; firma electrónica cualificada gratuita para uso no profesional.

Dinamarca — en vigor desde el 1 de abril de 2026

Ley sobre la cartera nacional de identidad digital — Lov om den nationale digitale identitetstegnebog, LOV nr. 301 af 24/02/2026.

  • La Agencia de Digitalización gestiona la cartera, el servicio de expedición de credenciales y el registro de partes usuarias.
  • Las autoridades responsables de fuentes auténticas deben expedir sus credenciales a través de ese servicio común.
  • Las entidades deben registrarse para recibir credenciales en línea, salvo para la mera verificación de edad; la Agencia puede suspender a quien actúe de forma fraudulenta.
  • Regula los efectos jurídicos de las credenciales, la responsabilidad e indemnización y el reparto de responsabilidades de tratamiento de datos.

Eslovaquia — en vigor desde el 1 de enero de 2025

Ley n.º 365/2024, de 27 de noviembre de 2024, por la que se modifica y completa la Ley n.º 272/2016 de servicios de confianza para las transacciones electrónicas en el mercado interior — Zákon z 27. novembra 2024, ktorým sa mení a dopĺňa zákon č. 272/2016 Z. z. o dôveryhodných službách pre elektronické transakcie na vnútornom trhu (n.º 365/2024 Z. z.).

  • El Ministerio del Interior proporciona la cartera y mantiene la lista de partes usuarias.
  • La Autoridad Nacional de Seguridad (NBÚ) supervisa tanto los servicios de confianza como el marco de la cartera.
  • Los proveedores de carteras deben ser prestadores cualificados de servicios de confianza o tener contrato con uno.
  • Multas de hasta 500.000 euros a proveedores de carteras y de hasta 5 millones o el 1 % a prestadores cualificados.

Luxemburgo — proyecto de ley

Proyecto de ley relativa a la implantación de la cartera de identidad digital europea y por la que se aplica el Reglamento (UE) 2024/1183 — Projet de loi relative à la mise en place du portefeuille européen d’identité numérique et portant mise en œuvre du règlement (UE) 2024/1183, n° 8583, presentado el 14 de julio de 2025.

  • Proveedor: el Centro de Tecnologías de la Información del Estado (CTIE). Supervisor: el Instituto Luxemburgués de Regulación (ILR), regulador independiente.
  • El registro de partes usuarias es público; para inscribirse se exige, entre otros, un certificado de antecedentes penales.
  • Los datos de identificación incluyen un número administrativo seudonimizado.
  • Inspecciones, medidas correctoras y multas de hasta 1 millón de euros; recurso ante el Tribunal administrativo.

Italia — en vigor, en fase de experimentación

Decreto-ley n.º 19, de 2 de marzo de 2024, de disposiciones urgentes para la aplicación del Plan de Recuperación — Decreto-legge 2 marzo 2024, n. 19, «Ulteriori disposizioni urgenti per l’attuazione del Piano nazionale di ripresa e resilienza (PNRR)», que introduce el artículo 64-quater del Código de la Administración Digital, «Sistema di portafoglio digitale italiano – Sistema IT-Wallet». Lo desarrolla el Decreto del Presidente del Consejo de Ministros de 31 de julio de 2026 sobre los organismos nacionales competentes para la identidad digital europea — «Organismi nazionali competenti per l’identità digitale europea».

  • Cartera pública en la aplicación IO, proporcionada por PagoPA, y carteras privadas acreditadas con requisitos de solvencia y seguros.
  • La Agencia para la Italia Digital (AgID) es organismo de supervisión, punto de contacto único y registrador; el Instituto Poligráfico (IPZS), proveedor de los datos de identificación; la Agencia Nacional de Ciberseguridad (ACN), propietaria del esquema de certificación.
  • Ocho declaraciones prioritarias, entre ellas títulos académicos, tarjeta sanitaria, permiso de conducir y tarjeta de discapacidad.

En tramitación o en estudio

  • Polonia: Projekt ustawy o zmianie ustawy o usługach zaufania oraz identyfikacji elektronicznej oraz niektórych innych ustaw (Proyecto de ley de modificación de la Ley de servicios de confianza e identificación electrónica y de otras leyes, UC122), publicado el 19 de febrero de 2026. Adapta mObywatel, ofrece firma cualificada gratuita para uso no profesional y obliga a las fuentes auténticas a ofrecer verificación a los prestadores cualificados.
  • Chequia: Návrh zákona, kterým se mění zákon č. 297/2016 Sb., o službách vytvářejících důvěru pro elektronické transakce, zákon č. 250/2017 Sb., o elektronické identifikaci, a zákon č. 634/2004 Sb., o správních poplatcích (Proyecto de ley por el que se modifican las leyes de servicios de confianza, de identificación electrónica y de tasas administrativas), aprobado por el Gobierno en marzo de 2026. La cartera la operará un concesionario privado.
  • Suecia: SOU 2024:45 Kompletterande bestämmelser till EU:s reviderade förordning om elektronisk identifiering (Disposiciones complementarias al Reglamento revisado de la UE sobre identificación electrónica), informe de 2024 que propone separar proveedor (Digg) y supervisor (PTS), admitir carteras privadas y sanciones de hasta 5 millones de euros.

Participar, aunque el tiempo apriete

La comparación deja una conclusión clara: España necesitará, además de este real decreto, una norma con rango de ley que regule aspectos pendientes no cubiertos por el Reglamento EIDAS2: el valor jurídico de las declaraciones electrónicas de atributos y el encaje de la cartera con la Ley 39/2015, uso de Cl@ve, Carpeta Ciudadana, utilización en Lexnet y Citius… Pero lo urgente es mejorar el texto que hoy está en audiencia.

Animo a todas las partes interesadas en los servicios de confianza a leer el proyecto y enviar sus observaciones, hasta el 13 de octubre de 2026, a audienciapublica.prdcarteradigital@digital.gob.es.

Quien quiera comentar conmigo estas ideas y otras que se le ocurran puede escribirme a julian (at) inza.net . También puede contactar con EADTrust en info@eadtrust.com o en el 91 716 05 55.

Tras pasar por Ginebra y Tallin, hoy estoy en Sophia Antipolis: siguiendo los avances que se producen en torno a la EUDI Wallet


A menos de tres meses del 24 de diciembre de 2026, fecha en la que cada Estado miembro debe ofrecer al menos una Cartera Europea de Identidad Digital (EUDI Wallet), septiembre me ha llevado a tres citas clave: Ginebra, Tallin y, esta semana, Sophia Antipolis, en la sede de ETSI.

Ginebra: la visión global

El mes arrancó en Ginebra con la Global Digital Collaboration Conference, del 1 al 3 de septiembre. Es un foro por invitación que coorganizan organismos intergubernamentales, de normalización y de código abierto, entre ellos ETSI, W3C, ISO, la OpenWallet Foundation, la Linux Foundation, el Banco Mundial y el PNUD.

La Cartera europea fue protagonista del tercer día, con sesiones sobre cómo se pasa de las normas exigidas por el Reglamento a la implantación real y sobre la infraestructura de confianza de la EUDI Wallet. El segundo día se habló de interconexión entre ecosistemas de identidad, de espacios de confianza globales y de cómo poner en práctica el Reglamento de Ciberresiliencia.

La conclusión de Ginebra: Europa marca el paso, pero la interoperabilidad con otras regiones exige que las listas de confianza y los formatos de credencial se entiendan fuera de la UE.

Estuve en Ginebra con Albi Rodríguez, de Garrigues. No teníamos ponencia, pero seguimos de cerca las intervenciones y aprovechamos para hablar con ponentes y asistentes. El objetivo: organizar en España, a primeros de diciembre, un evento que vaya más allá del que celebramos el 28 de abril en el Observatorio Legaltech Garrigues-ICADE, La Cartera de Identidad Digital de la Unión Europea: implementación y transformación de la gestión de la identidad. Aquella sesión en Comillas repasó el despliegue de la Cartera española, los pilotos europeos y las declaraciones electrónicas de atributos aplicadas a los poderes de representación.

Tallin: una semana de firma, confianza y certificación

Del 14 al 18 de septiembre, Tallin concentró en una sola semana buena parte del ecosistema europeo de la confianza digital. Lo conté con detalle en Una semana en Tallinn; este es el resumen:

  • Lunes 14: ETSI ESI CA Open Session y, por la noche, el 10.º aniversario del Cloud Signature Consortium.
  • Martes 15: 12.ª edición del Trust Services and eID Forum de ENISA, en el Kultuurikatel.
  • Miércoles 16: 18.ª edición del CA Day, organizado por D-TRUST y TÜV NORD Cert.
  • Jueves 17 y viernes 18: reunión del grupo de expertos ad hoc (AHWG) de ENISA sobre certificación de la Cartera.

La sesión abierta de ETSI ESI y la qDLT

El 14 de septiembre acudí a la sesión abierta de ETSI ESI como asistente y terminé como panelista. La intervención estaba prevista para Steffen Schwalm, que no pudo viajar, y me pidieron que hablara de cómo evoluciona la normalización de las tecnologías de registro distribuido (DLT, o RJT como prefiero llamarlas). Sustituir a Steffen Schwalm no era tarea fácil: pocos han hecho tanto como él por impulsar la normalización asociada a EIDAS y EIDAS2 y las tecnologías de registro distribuido en particular.  Ha participado activamente en la normalización nacional e internacional (DIN, ISO, BSI, etc.) en este campo durante muchos años y representa a Alemania en ISO para el desarrollo de un estándar global en gestión de registros y blockchain.

Defendí que los libros mayores electrónicos cualificados (qDLT) son una evolución coherente de la infraestructura de confianza europea: enlazan la conservación cualificada de firmas y sellos, el archivo electrónico y la ordenación cronológica de registros. Lo desarrollé después en De la conservación cualificada de firmas y sellos a los servicios cualificados de archivo con orden cronológico (qDLT).

El foro de ENISA y el CA Day

El foro y el CA Day reunieron a supervisores, prestadores cualificados, organismos de evaluación de la conformidad e instituciones europeas y nacionales. El eje fue el estado de implantación de la Cartera en cada Estado miembro, junto con la futura Cartera Europea de Empresa, el Reglamento de Ciberresiliencia, la normalización y la criptografía postcuántica.

El grupo de expertos de certificación de carteras

La semana terminó con trabajo técnico, no con un congreso abierto. Como miembro del AHWG de ENISA, participé el 17 y 18 en la reunión sobre el esquema candidato de certificación de ciberseguridad de las carteras y los requisitos de seguridad de los prestadores de servicios relacionados. Es el trabajo que después se traduce en normas europeas y en cómo se evaluarán las carteras, y enlaza directamente con la sesión 13 de Sophia Antipolis, donde Eric Vetillard (ENISA) presenta el marco europeo de certificación.

Sophia Antipolis: las normas que sostienen la Cartera

Del 29 de septiembre al 1 de octubre, en el «ETSI/CEN workshop on EU Digital Framework centring on the EU Identity Wallet» ETSI y CEN repasan en Sophia Antipolis, junto a la Comisión Europea y ENISA, el estado de la normalización que da soporte a la Cartera. Abre Ultan Mulligan (ETSI) y, en tres días y quince sesiones, se recorre casi todo el ecosistema:

  • Planes de normalización de la DG CONNECT, CEN TC 224, ETSI TC ESI y ENISA.
  • Pilotos y carteras nacionales: WE BUILD, APTITUDE y las carteras francesa y polaca.
  • Declaraciones electrónicas de atributos: protocolos (OpenID4VC, ISO mdoc, perfiles de ETSI), reglamentos de esquema (rulebooks) y la identidad de GLEIF como declaración.
  • Privacidad: control de acceso, RGPD, pruebas de conocimiento cero y verificación de edad.
  • Onboarding e identificación remota: ataques de inyección biométrica, requisitos europeos para productos biométricos y la visión de Dinamarca.
  • Confianza: registro y certificados de acceso de partes usuarias, listas de confianza y su internacionalización, y modelos de confianza alternativos.
  • Firma, pruebas y certificación: firma remota desde la Cartera, planes de prueba de la Comisión, OpenID, ISO y ETSI, y el marco europeo de certificación de ciberseguridad.
  • Servicios financieros y Cartera de Empresa: euro digital, casos de pago de la SEPA, banca abierta y el impacto del futuro Reglamento sobre la Business Wallet en las normas de ETSI y CEN, incluidos los servicios de entrega electrónica certificada.

Es, en la práctica, el mapa de lo que falta por cerrar antes y después del 24 de diciembre.

WE BUILD y APTITUDE: los pilotos a gran escala

Los dos pilotos lanzados en septiembre y octubre de 2025 son el banco de pruebas donde las normas se encuentran con casos de uso reales. En Sophia Antipolis los presentan Laurent Bailly (Visa) por WE BUILD y Philippe Nieto (Ministerio del Interior francés) por APTITUDE.

PilotoCoordinaciónParticipantesEnfoque
WE BUILDMinisterio de Asuntos Económicos y KVK (Países Bajos), Bolagsverket (Suecia)Casi 200 entidades de los 27 Estados miembros; unos 25 M€ en 24 mesesEmpresas (B2B, B2G, B2C): KYC, representación legal, poderes de firma, titularidad real; 13 casos de uso
APTITUDEFrancia (ANTS / France Titres)Más de 140 organizaciones de 13 paísesCredenciales de viaje, permiso de circulación móvil, billetes y check-in, pagos con autenticación reforzada

WE BUILD aporta además su propio reglamento de esquema, que presenta Esther Makaay (Signicat). Entre sus participantes hay unos 30 prestadores cualificados de servicios de confianza, lo que confirma que las declaraciones cualificadas de atributos y la firma son piezas centrales del modelo.

Los países ante el 24 de diciembre

El Reglamento (UE) 2024/1183 obliga a cada Estado miembro a ofrecer al menos una cartera certificada antes del 24 de diciembre de 2026. Según un análisis reciente de Brussels Signal, la mayoría llegará tarde:

  • Italia es el caso más avanzado, con cerca de 8 millones de usuarios mensuales.
  • Alemania prevé el lanzamiento el 2 de enero de 2027, nueve días después del plazo.
  • Países Bajos ha retrasado el despliegue a finales de 2027.
  • Bulgaria aún redacta la ley nacional necesaria para emitir carteras.

En Sophia Antipolis toman la palabra dos implantaciones nacionales: la francesa (Philippe Nieto) y la polaca (Joanna Koczorowska, Centro Central de Tecnologías de la Información). También se presentan el registro alemán de partes usuarias (Mirko Molik, SPRIND) y la visión danesa sobre identificación remota (Simon Holmgaard).

Después del plazo llega la presión de la demanda: la aceptación obligatoria por bancos y otras partes usuarias privadas se escalona durante 2027.

La agenda y sus protagonistas

Estos son los ponentes y moderadores del encuentro, sesión a sesión.

DíaSesiónModeraciónPonencias y ponentes
29 sept, 13:00Bienvenida—Ultan Mulligan (ETSI)
29 sept1. Planes de normalizaciónFranziska Granc (Nimbus)DG CONNECT: Paolo De Rosa y Stavros Kounis · CEN: Aylin Kip (Secretaría CEN TC 224) y Alban Feraud (presidente CEN TC 224) · ETSI: Andrea Röck (vicepresidenta ETSI TC ESI) · ENISA: Philippe Magnabosco
29 sept2. Implantación de la Cartera y pilotosFranziska Granc (Nimbus)WE BUILD: Laurent Bailly (Visa) · APTITUDE y cartera francesa: Philippe Nieto (Ministerio del Interior de Francia) · Cartera polaca: Joanna Koczorowska (Centro Central de TI de Polonia)
30 sept3. Control de acceso y RGPDAndreea Prian (IDAKTO)Control de acceso a los activos de la Cartera (CEN): Jan Lindquist (LinalTec) · Política de divulgación integrada (ETSI): Michal Tabor (Obserwatorium.biz) · Funciones de apoyo al RGPD: Konrad Lanz (GReev)
30 sept4. Declaraciones electrónicas de atributos: protocolosMirko Molik (SPRIND)OpenID4VC: Joseph Heenan (OpenID Foundation) · ISO mdoc: ponente por confirmar · Perfiles EAA de ETSI: Juan Carlos Cruellas (UPC)
30 sept5. Pruebas de conocimiento cero y declaraciones de la unidad de carteraJean-Emmanuel Perez Hernandez (Nowina)ZKP aplicado a la Cartera: Peter Altmann (DIGG) · WUA: Sebastian Elfors (IDnow) · Política de verificación de edad: Paolo De Rosa (DG CONNECT) · Requisitos técnicos de verificación de edad: Paloma Llaneza (Certeidas, ETSI STF 681)
30 sept6. Declaraciones de atributos: general y reglamento de esquemaWim Coulier (itsme)Interfaz del reglamento de esquema: Viktor Varga (Microsec) · Reglamento de WE BUILD: Esther Makaay (Signicat) · Identidad GLEIF como declaración: Christoph Schneider (GLEIF)
30 sept7. Verificación remota de la identidadAndrea Röck (SGDSN)Verificación de identidad: Jon Ølnes (Signicat) · Ataques de inyección biométrica: Chris Allgrove (Ingenium Biometric Laboratories) · Requisitos europeos para productos biométricos: Raúl Sánchez-Reillo (Universidad Carlos III de Madrid) · Visión de Dinamarca: Simon Holmgaard (DGIST) · Laboratorio de pruebas: Kevin Carta (Cabinet Louis Reynaud)
30 sept8. Onboarding de PID y declaraciones de atributosAndrea Röck (SGDSN)Onboarding de PID (CEN): Alban Feraud (IN Smart Identity) · Política de emisión de declaraciones (ETSI): Paloma Llaneza (Certeidas) · Identidad en el onboarding (ENISA): Eric Vetillard
30 sept9. Registro y certificados de partes usuariasFranziska Granc (Nimbus)Certificados de acceso: Iñigo Barreira (Sectigo) · Registro y certificados: Michal Tabor (Obserwatorium.biz) · Registro alemán: Mirko Molik (SPRIND)
30 sept10. Modelos de confianzaIñigo BarreiraModelos alternativos: Steffen Schwalm (CEN TC 19) · Listas de confianza eIDAS: Jean-Emmanuel Perez Hernandez (Nowina) · Certificados cualificados para la emisión pública de declaraciones: Viktor Varga (Microsec) · Internacionalización de las listas de confianza: Hiroshi Nakatake (GLEIF Japón)
1 oct11. La firma y la CarteraMichal Tabor (Obserwatorium.biz)Requisitos de firma remota: Andrea Röck (SGDSN) · Protocolos de firma remota: Luigi Rizzo (InfoCert) · Sistemas fiables de firma en servidor: Jan Kjærsgaard (INGROUP) · Arquitectura y protocolos del Cloud Signature Consortium: Thomas Pedersen (Cryptomathic)
1 oct12. Pruebas de la CarteraAndrea Röck (SGDSN)Planes de prueba de la Comisión: Oliver Terbu (CE) · Pruebas ISO mdoc: Kenichi Nakamura (Panasonic) · Pruebas OpenID: Joseph Heenan (OpenID Foundation) · Pruebas ETSI: Juan Carlos Cruellas (UPC) y Laurent Velez (ETSI)
1 oct13. Certificación de la CarteraRaúl Sánchez-Reillo (UC3M)Marco europeo de certificación: Eric Vetillard (ENISA) · Grupo informal de naciones: Stéfane Mouille (CLR Labs) · Registro de riesgos: Elżbieta Andrukiewicz (CEN) · Aplicación criptográfica segura: Jan Kjærsgaard (INGROUP / CEN) · Dispositivo criptográfico seguro: Annegret Schöffel (BSI / GlobalPlatform) · Pruebas de ciberseguridad de la instancia: Kevin Carta (Cabinet Louis Reynaud / CEN)
1 oct14. Carteras y servicios financierosMichal Tabor (Obserwatorium.biz)Euro digital: Fabien Deboyser (NXP) · Casos de pago de la SEPA para eIDAS: Lorenzo Gaston (Smart Payment Association) · Certificados para banca abierta: Luigi Rizzo (InfoCert)
1 oct15. Hacia la Cartera Europea de EmpresaArno Fiedler (vicepresidente ETSI TC ESI)Planes regulatorios de la Comisión: Paolo De Rosa y Stavros Kounis · Impacto en normas ETSI: Paloma Llaneza (Certeidas) · Impacto en normas CEN: Alban Feraud · ERDS al servicio de la Business Wallet: Juan Carlos Cruellas (UPC)
1 oct, 15:15Clausura—Arno Fiedler (ETSI) · Alban Feraud (CEN) · Paolo De Rosa (CE)

Destaca la presencia española: Paloma Llaneza, Iñigo Barreira, Juan Carlos Cruellas y Raúl Sánchez-Reillo intervienen o moderan en nueve de las quince sesiones.

La apuesta de EADTrust

En EADTrust llevamos años siguiendo de cerca la identidad digital europea, y este mes lo confirma: estar en Ginebra, Tallin y Sophia Antipolis es parte de nuestro compromiso por entender el mercado desde dentro y ayudar a impulsarlo. Como prestador cualificado de servicios de confianza, queremos estar listos para emitir declaraciones cualificadas de atributos, facilitar la firma desde la Cartera y acompañar a las partes usuarias que tendrán que aceptarla en 2027.

Ese seguimiento lo compartimos en usercentric.id, el escaparate de EADTrust sobre la identidad centrada en el usuario. Allí recogemos los avances de la Cartera en España y en Europa: explicaciones sobre su funcionamiento, el marco del Reglamento eIDAS2, qué empresas deberán adaptarse y un directorio de actores del ecosistema.

Y queremos traer esa conversación a España: junto con Garrigues estamos preparando un nuevo encuentro para primeros de diciembre, a las puertas del plazo del 24 de diciembre. Daremos los detalles muy pronto.

Si su organización se está preparando para la Cartera, puede escribirnos a info@eadtrust.com, llamar al 91 716 05 55 o visitar www.eadtrust.eu.

English Summary

Geneva, Tallinn and Sophia Antipolis: a September following the European Digital Identity Wallet.

Less than three months before 24 December, when every Member State must offer at least one certified EUDI Wallet, I have taken part in three key meetings:

  • Geneva (1-3 Sept). Global Digital Collaboration Conference. Together with Albi Rodríguez of Garrigues, I followed the sessions and talked with speakers and attendees to prepare a new event in Spain in early December, one that will go further than the event we held in April at the Observatorio Legaltech Garrigues-ICADE.
  • Tallinn (14-18 Sept). I joined the ETSI ESI Open Session as a panellist to talk about the standardisation of qualified electronic ledgers (qDLT), attended ENISA’s Trust Services and eID Forum and the CA Day, and closed the week with ENISA’s expert group on wallet certification.
  • Sophia Antipolis (29 Sept – 1 Oct). Across fifteen sessions, ETSI and CEN review the standards behind the Wallet: electronic attestations of attributes, zero-knowledge proofs, age verification, the relying party register, remote signing, certification and the upcoming European Business Wallet.

I also look at the WE BUILD and APTITUDE pilots and at how Member States are progressing: Italy is ahead, while most will miss the deadline.

At EADTrust we follow this market closely to help it grow, and we share what we learn on usercentric.id, our showcase of developments in Spain and across Europe.

#EUDIWallet #eIDAS2 #DigitalIdentity #ETSI #CEN #ENISA #TrustServices

Cómo incluir nombres y dos apellidos españoles compuestos en el PID (DIP) de la Cartera IDUE (EUDI Wallet)


En el PID se incluye un campo de nombre y otro de apellido, pero no se contempla un tratamiento de nombres compuestos españoles y de dos apellidos, que pueden ser también compuestos (los 2 apellidos).

Y es que hay que reconocer que la costumbre anglosajona de usar un único campo de apellido no encaja con la costumbre española, y nuestra preferencia «rasca» con la forma en que se regula el PID. Así que propongo en este artículo una forma de codificar y decodificar la estructura del nombre y los dos apellidos sin romper la interoperabilidad, y sugiero una propuesta de cómo debería evolucionar la descripción del PID en el «Rule Book» para que la cartera europea sea directamente usable en España.

Para la solución provisional me baso en la solución adoptada para las menciones científicas de autores hispanos en publicaciones internacionales, donde luna cierta normalización tipográfica resolvieron un problema análogo.

El problema de fondo

El modelo de datos de identificación de persona del PID (Person Identification Data) hereda, como casi todos los esquemas de identidad de origen anglosajón, una simplificación de partida: un campo para el nombre y un campo para el apellido. En concreto, el PID ofrece given_name (obligatorio, con los nombres intermedios incluidos), family_name (obligatorio), y opcionalmente given_name_birth y family_name_birth. Todos son cadenas de texto libre, sin subestructura.

Ese diseño encaja mal con la costumbre española, que descansa sobre dos rasgos que el campo único no sabe representar.

Primero, los dos apellidos. Un ciudadano español tiene primer y segundo apellido, y desde las reformas del Registro Civil su orden ya no es necesariamente el paterno-primero: los progenitores lo eligen y la persona adulta puede invertirlo. Por tanto, cualquier convención que hable de «apellido paterno» y «apellido materno» nace equivocada; lo correcto es hablar de primer y segundo apellido como posiciones, no como linaje.

Segundo, los componentes compuestos. Tanto el nombre de pila (José María, María del Carmen, Juan Carlos) como cada apellido pueden ser internamente compuestos: con partículas (García de la Torre, Fernández de Córdoba, del Río), con la conjunción copulativa (Ramón y Cajal, Martí i Franquès) o con guion (Sánchez-Cano).

La consecuencia es que, cuando toda esa riqueza se aplasta en family_name = "García de la Torre Martín", la cadena deja de ser decodificable sin ambigüedad: ¿es «García de la Torre» + «Martín», o «García» + «de la Torre Martín»? El espacio, que es el separador natural del texto, no distingue el hueco entre los dos apellidos del hueco interno de un apellido compuesto. Es exactamente el mismo fenómeno que llevó a la comunidad científica a normalizar la firma para que las bases de datos no descompusieran «García Pérez» en «Pérez, G.».

Dónde se regula el PID: actos de ejecución y ARF

Antes de proseguir con la propuesta conviene situar las piezas normativas, porque el PID no se regula en un solo texto. En el plano de los actos de ejecución del Reglamento eIDAS 2, el que define los atributos del PID (obligatorios y opcionales) y su ciclo de vida es el Reglamento de Ejecución (UE) 2024/2977, de 28 de noviembre de 2024, sobre datos de identificación de la persona y declaraciones electrónicas de atributos. Lo acompañan, en la misma tanda, el 2024/2979 (integridad y funcionalidades esenciales de la cartera), el 2024/2980 (notificaciones al ecosistema), el 2024/2981 (certificación de las carteras) y el 2024/2982 (protocolos e interfaces, es decir, el catálogo de estándares con los que el PID se emite y se presenta). La segunda serie, de 2025, lo roza de forma indirecta pero muy pertinente para este asunto (el 2025/846 regula el cross-border identity matching, el cotejo transfronterizo en el que la estructura del nombre es justamente lo que se compara), y en 2026 se han publicado enmiendas (que ya he mencionado en el blog) que tocan los actos nucleares, incluido el 2024/2977, por lo que conviene trabajar siempre sobre el texto consolidado.

En el plano técnico, el Architecture and Reference Framework (ARF, cuya última versión en este momento es la 3.0) desarrolla lo anterior en varias piezas: el documento principal; el Annex 1 (Definiciones); el Annex 2 (High-Level Requirements), con requisitos técnicos, algunos específicos del PID; y, sobre todo, el Annex 3.01 – PID Rulebook, que es donde se define el esquema de atributos y sus dos codificaciones, mdoc (ISO/IEC 18013-5) y SD-JWT VC. Como referencia paralela está el Annex 3.02 (mDL Rulebook), y para el ciclo completo, el Annex 4 (emisión y presentación) y el Annex 6 (certificación). Cuando en este artículo se habla de «evolucionar la descripción del PID», el objeto concreto es el Annex 3.01 y el anexo del Reglamento 2024/2977.

Esta es la relación de actos de ejecución, con indicación de cuáles inciden en el PID (los números enlazan al texto en EUR-Lex):

Acto de ejecuciónObjetoIncidencia en el PID
(UE) 2024/2977Datos de identificación de la persona y declaraciones electrónicas de atributosDefine el PID (atributos y ciclo de vida)
(UE) 2024/2979Integridad y funcionalidades esenciales de la carteraIndirecta
(UE) 2024/2980Notificaciones a la Comisión sobre el ecosistemaIndirecta
(UE) 2024/2981Certificación de las carterasIndirecta
(UE) 2024/2982Protocolos e interfaces (estándares de referencia)Formatos de emisión y presentación
(UE) 2025/846Cotejo transfronterizo de identidadesRelevante: coteja nombre y apellidos
(UE) 2025/847Notificación de brechas de seguridadIndirecta
(UE) 2025/848Registro de las partes usuariasIndirecta
(UE) 2025/849Lista de carteras certificadasIndirecta
(UE) 2025/2162Acreditación de los organismos de evaluación de la conformidadIndirecta
(UE) 2026/1731Enmienda a 2024/2977, 2024/2979, 2024/2980 y 2024/2982 (estándares y especificaciones)Modifica el 2024/2977

Qué exige el Reglamento sobre estos campos

El Reglamento 2024/2977 define family_name y given_name como texto libre destinado a mostrar y cotejar la identidad; es decir, como el valor legible que una parte usuaria (relying party) enseñará a un operador o comparará con otro documento. Esto impone una restricción de diseño ineludible: el valor de presentación debe seguir siendo la forma natural del nombre. No podemos contaminarlo con marcadores estructurales, porque una parte usuaria de otro Estado miembro que no conozca nuestra convención mostraría un artefacto con símbolos a un funcionario.

De aquí se deriva el principio rector de toda esta propuesta: separar el valor de presentación del valor estructurado. La estructura interna del nombre no debe viajar dentro del campo obligatorio de display, sino en un canal que degrade con elegancia: los campos opcionales o —mejor— un subcampo estructurado en el propio Rulebook.

Qué le pedimos a una solución provisional

Mientras el esquema del PID no incorpore subcampos de nombre, necesitamos una convención que preserve la estructura dentro de los campos que hoy existen. Para que sea sólida, esa convención debe cumplir cinco requisitos:

  1. Reversibilidad. codificar(decodificar(x)) == x. La estructura recuperada debe volver a producir exactamente la misma cadena, sin pérdida.
  2. Seguridad de presentación (degradación elegante). Si un sistema ignora la convención, lo que muestre debe seguir siendo un nombre legible, no un artefacto.
  3. Seguridad de codificación. El PID se serializa en CBOR/COSE (formato mdoc, ISO/IEC 18013-5) o en JSON (SD-JWT VC). El marcador elegido no debe crear peligros de escape ni de doble escape al atravesar esas capas, ni al pasar por LDAP, expresiones regulares o URLs.
  4. No colisión con caracteres legítimos del nombre. El marcador no puede ser un carácter que aparezca de forma natural en nombres españoles (ni el espacio, ni el guion, ni el punto, ni la conjunción «y/i»).
  5. Neutralidad respecto al orden. La convención codifica posición (primer/segundo apellido), nunca linaje.

La solución provisional: la barra inclinada

El carácter que satisface esos cinco requisitos es la barra inclinada (/). Es legal sin escape dentro de una cadena JSON y es un byte ordinario en CBOR, de modo que sobrevive intacta a ambas serializaciones y a su conversión mutua. No aparece nunca en nombres españoles, así que no colisiona con ningún componente legítimo. Y, si un sistema que desconoce la convención la muestra tal cual, produce «García de la Torre / Martín», que cualquier persona interpreta sin dificultad: degrada de forma legible en lugar de romperse.

La propuesta es, por tanto, un modelo de dos capas. La capa de presentación usa los campos obligatorios tal cual los concibe el Reglamento, con la forma natural y sin ningún marcador. La capa estructurada transporta la descomposición reversible: mientras el Rulebook no ofrezca subcampos, se codifica en banda —por ejemplo en family_name_birth o en un atributo nacional— con la barra separando solo el primer y el segundo apellido, y preservando cada componente con sus propios espacios, partículas y guiones.

El algoritmo es trivial y auditable. Estas son las reglas, con la normalización Unicode a NFC incluida y el escape por porcentaje para la —rarísima— barra literal dentro de un componente:

# Marcador y escape
SEP = " / "
esc(c) = c.replace("%","%25").replace("/","%2F")
unesc(c) = c.replace("%2F","/").replace("%25","%")
codificar(primer, segundo):
primer, segundo = NFC(primer), NFC(segundo)
if segundo == "": return esc(primer) # apellido único
return esc(primer) + SEP + esc(segundo)
decodificar(s):
partes = NFC(s).split(SEP)
if len(partes) == 1: return (unesc(partes[0]), "")
return (unesc(partes[0]), unesc(SEP.join(partes[1:])))

Casos límite, resueltos

  • Apellido único (extranjeros nacionalizados, o españoles con un solo apellido): ausencia de barra. "Smith" se codifica como "Smith" y la decodificación devuelve segundo apellido vacío. El round-trip se mantiene.
  • Conjunción copulativa. Ramón y Cajal o Martí i Franquès pueden ser un único apellido compuesto. La barra es la única frontera autoritativa; el «y»/«i» nunca lo es. Así, "Ramón y Cajal / Ferrer" se decodifica sin ambigüedad como primer apellido «Ramón y Cajal» y segundo «Ferrer».
  • Barra literal en un nombre (excepcional): se codifica por porcentaje (%2F), de modo que el separador nunca se confunde con un carácter del propio nombre.
  • Normalización Unicode. Todo componente se normaliza a NFC y se conserva el uso registral de mayúsculas y minúsculas (partículas «de», «de la», «del» en minúscula cuando no encabezan). Sin esto, el cotejo posterior falla por diferencias de composición de las tildes.

En este contexto NFC es Normalization Form C (Forma de Normalización C, o «composición canónica»).

Todas estas reglas están verificadas con round-trip automático sobre los cuatro casos —compuesto con partículas, apellido único, conjunción copulativa y barra literal— antes de escribir una sola línea del ejemplo que sigue.

Ejemplo completo

Tomemos una persona por su estructura: nombre de pila compuesto, primer apellido con partículas y segundo apellido simple.

ElementoValor
Nombre de pilaJosé María
Primer apellidoGarcía de la Torre
Segundo apellidoMartín
family_name (presentación)García de la Torre Martín
Forma estructurada (barra)García de la Torre / Martín

Un detalle que conviene tener presente en cualquier codificación binaria: «García de la Torre Martín» ocupa 27 bytes en UTF-8 pero solo 25 caracteres, porque cada «í» son dos bytes (0xC3 0xAD). Las longitudes que aparecen en el CBOR de abajo son de bytes, no de caracteres.

(A) Formato mdoc — ISO/IEC 18013-5 (CBOR)

En el namespace eu.europa.ec.eudi.pid.1, los atributos del PID se serializan como un mapa CBOR. Esta es la representación del ejemplo en notación diagnóstica:

{
"given_name": "José María",
"family_name": "García de la Torre Martín",
"birth_date": 1004("1978-05-14"), / tag full-date /
"birth_place": "ES",
"nationality": ["ES"],
"family_name_birth": "García de la Torre Martín",
"issuing_country": "ES",
"issuing_authority": "Ministerio del Interior"
}

Y su codificación real, byte a byte (hex), 230 bytes en total:

a8 # map(8)
6a 676976656e5f6e616d65 # "given_name"
6c 4a6f73c3a9204d6172c3ad61 # "José María"
6b 66616d696c795f6e616d65 # "family_name"
78 1b 47617263c3ad61206465206c6120 # text(27) "García de la
546f727265204d617274c3ad6e # Torre Martín"
6a 62697274685f64617465 d9 03ec # "birth_date" tag(1004)
6a 313937382d30352d3134 # "1978-05-14"
6b 62697274685f706c616365 62 4553 # "birth_place" "ES"
6b 6e6174696f6e616c697479 81 62 4553 # "nationality" ["ES"]
71 66616d696c795f6e616d655f6269727468 # "family_name_birth"
78 1b 47617263c3ad61...c3ad6e # text(27) "García…Martín"
6f 69737375696e675f636f756e747279 62 4553 # "issuing_country" "ES"
71 69737375696e675f617574686f72697479 # "issuing_authority"
77 4d696e6973746572696f2064656c20496e... # "Ministerio del Interior"

Cada atributo se firma, en realidad, dentro de un IssuerSignedItem envuelto en un byte string marcado con la etiqueta CBOR 24 (encoded-cbor). Para family_name:

# Tag 24 > bstr > { digestID, random, elementIdentifier, elementValue }
d818 5863 a4
68 646967657374494403 # "digestID": 3
66 72616e646f6d 48 8f9b6c2d1e4a7f30 # "random": h'8f9b…7f30'
71 656c656d656e744964656e746966696572 # "elementIdentifier"
6b 66616d696c795f6e616d65 # "family_name"
6c 656c656d656e7456616c7565 # "elementValue"
78 1b 47617263c3ad61...546f727265204d617274c3ad6e # "García de la Torre Martín"

La forma estructurada en mdoc. El atributo family_name mantiene la forma natural; la descomposición viaja aparte, en un elemento propuesto family_name_unit, como submapa CBOR —limpio, sin marcadores en banda y con divulgación selectiva independiente:

a1 70 66616d696c795f6e616d655f756e6974 # { "family_name_unit":
a2 65 6669727374 73 47617263c3ad612064... # "first": "García de la Torre",
66 7365636f6e64 67 4d617274c3ad6e # "second": "Martín" } }

(B) Formato SD-JWT VC (JSON con divulgación selectiva)

En SD-JWT VC cada atributo divulgable se materializa en una disclosure —base64url([salt, nombre, valor])— cuyo digest SHA-256 se referencia en el array _sd del payload. Las disclosures del ejemplo (incluida la estructurada) son:

# family_name
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwiZmFtaWx5X25hbWUiLCJHYXJj
w61hIGRlIGxhIFRvcnJlIE1hcnTDrW4iXQ
# [ "2GLC42sKQveCfGfryNRN9w", "family_name",
# "García de la Torre Martín" ]
# family_name_unit (estructura, divulgable por separado)
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwiZmFtaWx5X25hbWVfdW5pdCIs
eyJmaXJzdCI6IkdhcmPDrWEgZGUgbGEgVG9ycmUiLCJzZWNvbmQiOiJNYXJ0
w61uIn1d
# [ "6Ij7tM-a5iVPGboS5tmvVA", "family_name_unit",
# { "first": "García de la Torre", "second": "Martín" } ]
// payload del JWT
{
"vct": "urn:eudi:pid:1",
"iss": "https://pid-provider.eadtrust.example",
"iat": 1789000000,
"_sd_alg": "sha-256",
"_sd": [
"yfz5UHtG2F_rLi1yy91D4jhgTp4E1Drr622DHtTg2h0", // family_name
"fXAlOjDoJjc5bDmf-t2dbtV1I3sQ85dfQqPXQVQGYPc", // given_name
"6b1YOIoO3h9rWMav2ohyH6ngyJOmWnjqx682KF_FInk" // family_name_unit
]
}

La ventaja del submapa family_name_unit como disclosure propia es doble: la parte usuaria española que necesite el primer apellido para un cotejo registral puede pedirlo sin forzar la revelación del segundo, y la parte usuaria genérica sigue recibiendo family_name tal cual, sin enterarse de la estructura. Divulgación selectiva y degradación elegante en el mismo mecanismo.

(C) Formato W3C Verifiable Credentials (JSON-LD), como referencia

Donde se use el perfil W3C VC, la misma idea se expresa con un objeto anidado en credentialSubject, conservando el literal de presentación junto a la estructura:

"credentialSubject": {
"given_name": "José María",
"family_name": "García de la Torre Martín",
"family_name_unit": { "first": "García de la Torre", "second": "Martín" }
}

Por qué la solución robusta no está en el separador

Es una humilde propuesta para resolver el problema, pero no es la panacea. Igual que en la firma de publicaciones científicas la normalización tipográfica acabó siendo un paliativo y la respuesta estructural fue el identificador persistente (ORCID), aquí el separador en banda es una solución de compromiso para cuando no hay más remedio. La respuesta arquitectónicamente correcta es que la estructura del nombre la conoce el registro emisor —el PID Provider parte del Registro Civil, que sí distingue primer y segundo apellido— y que esa estructura se transporte en subcampos explícitos, no incrustada en una cadena de texto que otros sistemas cotejarán a ciegas. La barra nos salva mientras tanto; el subcampo nos salva para siempre.

Lo que enseña (y advierte) el MRZ del pasaporte

Antes de que existiera el PID había ya un sistema que llevaba décadas transportando nombres de medio mundo entre administraciones: la zona de lectura mecánica (MRZ) de los documentos de viaje, normalizada en ICAO Doc 9303 (Parte 3). Merece la pena mirarla, porque valida algunas de las decisiones que proponemos aquí… y advierte de sus límites.

El MRZ tiene tres formatos —TD3 (pasaporte, 2 líneas de 44 caracteres), TD1 (tarjetas de identidad, 3 líneas de 30) y TD2 (2 líneas de 36)— y un juego de caracteres deliberadamente pobre: solo A–Z, 0–9 y el relleno <. No hay minúsculas, ni espacios, ni signos diacríticos; el espacio se representa con <.

El nombre se codifica así: identificador primario (los apellidos) + << + identificador secundario (los nombres), y dentro de cada identificador los componentes se separan con un solo <. Para «Federico García Lorca»:

GARCIA<LORCA<<FEDERICO

Dos observaciones que interesan a nuestro problema. La primera: ICAO no habla de «apellido» y «nombre», sino de identificador primario y secundario, y deja al Estado emisor decidir cómo repartir el nombre entre ambos. La serialización está fija; el reparto semántico se delega. La segunda: el pasaporte ya funciona en dos capas. El MRZ (interoperable, con pérdidas) se replica en el DG1 del chip, mientras que el nombre completo en caracteres nacionales vive en el DG11 («datos personales adicionales»). Es exactamente el patrón «verdad canónica + representación derivada» que defendemos para el PID.

Ahora la advertencia. El MRZ separa con claridad apellidos y nombres, pero no resuelve la ambigüedad de fondo: la serializa. El delimitador < colapsa en un mismo símbolo dos cosas distintas (el espacio interno de un apellido compuesto y la frontera entre dos apellidos). Ante:

GARCIA<DE<LA<TORRE<<JUAN

no hay forma de saber si «García de la Torre» es un apellido, o si son «García» y «De la Torre», o cuatro componentes sueltos. Es nuestra misma «cadena no decodificable sin ambigüedad», con otro separador. Añádase la transliteración con pérdidas (la Ñ se vuelve N, las tildes desaparecen), el truncamiento de nombres largos y las mayúsculas forzadas, y queda claro que el MRZ no puede ser ni la capa de presentación ni la fuente canónica.

La lección, por tanto, es doble. Por un lado, el MRZ confirma que se puede interoperar fijando roles claros (primario/secundario) y reglas deterministas de serialización y parseo. Por otro, demuestra empíricamente que un delimitador único sin estructura no porta la cardinalidad (cuántos apellidos hay) y que la transliteración destruye información. Es el mejor argumento a favor de lo que proponemos: subcampos explícitos para los apellidos y un valor canónico en Unicode, en lugar de confiarlo todo a la codificación in-band.

Y es también donde los servicios intermediarios de confianza encajan de forma natural: ofrecer a cada parte usuaria (RP) una capa de normalización que traduzca el PID (family_name, given_name y, cuando existan, los subcampos) a exactamente los campos que su formulario espera (un apellido, dos apellidos, nombre para mostrar), con reglas documentadas y reversibles. Así el RP deja de reinventar el parsing de nombres, que es donde hoy se concentra el sufrimiento. En definitiva: quedémonos con lo bueno del MRZ (roles claros, reglas deterministas) sin heredar lo malo (delimitadores ambiguos y transliteración destructiva).

Referencia: ICAO, Doc 9303 — Machine Readable Travel Documents, Part 3: Specifications Common to all MRTDs, disponible en icao.int.

Cómo debería evolucionar la descripción del PID

El caso español no es una excepción folclórica: Portugal encadena hasta cuatro apellidos, los países árabes construyen cadenas patronímicas, Islandia usa patronímicos en lugar de apellido de familia. Un modelo de nombre que solo contempla «nombre + apellido» es, en realidad, un problema paneuropeo que España evidencia con especial claridad. Estas son las evoluciones que, a mi juicio, deberían incorporar el Annex 3.01 (PID Rulebook) y el anexo del Reglamento 2024/2977:

  1. Un atributo de nombre estructurado, opcional y normalizado. Añadir al esquema PID un family_name_unit (submapa first/second, ampliable a third/fourth para Portugal) y un given_name_unit con el nombre habitual marcado. Opcional, para no romper a nadie; estructurado, para no perder información.
  2. Posición, no linaje. Nombrar los componentes por orden (first, second) y nunca por origen (paterno/materno), en coherencia con la libre elección y la inversión del orden que permite la ley española.
  3. Divulgación selectiva por componente. Que cada subcomponente sea una claim divulgable de forma independiente, de modo que una parte usuaria pueda solicitar solo el primer apellido cuando es lo que necesita para un cotejo, minimizando datos.
  4. Reglas de normalización explícitas en el propio Rulebook. Fijar NFC obligatorio, tratamiento de mayúsculas/minúsculas de partículas y —para el escenario provisional en banda— la barra como separador con escape por porcentaje. Escrito en la norma, no dejado al criterio de cada emisor.
  5. Un anexo nacional (perfil español del PID). El mecanismo por el que el ARF admite perfiles y rulebooks de atributos debería acoger un anexo español que registre formalmente esta convención, del mismo modo que ya existen rulebooks para otros dominios de atributos.
  6. Coherencia con el cotejo transfronterizo. El acto de ejecución 2025/846 sobre identity matching se apoya precisamente en el nombre y los apellidos; un PID con nombre estructurado hace ese cotejo fiable y evita repetir en la cartera los apaños ad hoc que cada nodo nacional viene arrastrando desde el conjunto mínimo de datos de eIDAS SAML.

Conclusión

El PID no fue diseñado pensando en los dos apellidos ni en los compuestos con partículas, y el campo único de texto libre es, para el caso español, estructuralmente insuficiente. La vía sensata no es maltratar el campo obligatorio de presentación —que debe seguir mostrando el nombre natural—, sino separar presentación de estructura, adoptar mientras tanto un separador que sobreviva a CBOR, JSON, LDAP y a las expresiones regulares —la barra inclinada, con sus reglas de frontera reversibles—, y, sobre todo, promover que el Annex 3.01 y el Reglamento 2024/2977 incorporen la estructura del nombre como subcampo explícito. Mientras Europa no lo haga, cada emisor español lo resolverá a su manera; y la interoperabilidad, que es justo lo que la EUDI Wallet viene a traer, se resentirá precisamente en el dato más elemental de todos: cómo nos llamamos.

Referencias normativas y técnicas

Reglamento marco. Reglamento (UE) n.º 910/2014 (eIDAS), en su versión modificada por el Reglamento (UE) 2024/1183 (eIDAS 2).

Actos de ejecución. Reglamentos de Ejecución (UE) 2024/2977 (PID y declaraciones electrónicas de atributos), 2024/2979, 2024/2980, 2024/2981 y 2024/2982 (primera serie, 28-XI-2024); 2025/846, 2025/847, 2025/848, 2025/849 y 2025/2162 (segunda serie, 2025); y la enmienda (UE) 2026/1731 (2026).

Architecture and Reference Framework (ARF). Annex 3.01 – PID Rulebook, dentro del conjunto del ARF y sus anexos (repositorio oficial de la Comisión Europea).

Formatos. ISO/IEC 18013-5 (mdoc) para la codificación CBOR/COSE; SD-JWT VC (IETF) para la codificación JSON con divulgación selectiva.

Te ayudamos

En EADTrust (European Agency of Digital Trust) acompañamos a las entidades obligadas a aceptar la Cartera Europea de Identidad Digital en su adaptación técnica y jurídica. El artículo 5 septies del Reglamento (UE) n.º 910/2014, modificado por el Reglamento (UE) 2024/1183 (eIDAS 2), impone esa aceptación a las administraciones públicas y a las partes usuarias privadas de sectores como el transporte, la energía, la banca y los servicios financieros, la seguridad social, la salud, el agua potable, los servicios postales, la infraestructura digital y las telecomunicaciones, además de a las plataformas en línea de muy gran tamaño (VLOP). Si su organización está entre ellas, podemos ayudarle a preparar la integración de la cartera con garantías de interoperabilidad y valor probatorio. Contacte en www.eadtrust.eu, info@eadtrust.com o en los teléfonos 902 365 612 y 91 716 05 55.

Se acaban de publicar tres nuevos actos de ejecución del Reglamento eIDAS 2 que actualizan aspectos de la gestión de Carteras IDUE


Ayer, 22 de julio de 2026 el Diario Oficial de la Unión Europea publicó tres nuevos reglamentos de ejecución de la Comisión, todos ellos adoptados el 15 de julio de 2026, que continúan tejiendo el andamiaje normativo del Reglamento (UE) 2024/1183 (eIDAS 2) y de la Cartera Europea de Identidad Digital (Cartera IDUE / EUDI Wallet).

Los tres comparten un mismo hilo conductor —y un mismo título revelador: «en lo que respecta a las normas y especificaciones aplicables»—. No introducen figuras nuevas, sino que modifican actos de ejecución ya vigentes para alinear sus especificaciones técnicas con la evolución de la Arquitectura y el Marco de Referencia (ARF), que acaba de actualizarse a la versión 3.0.0. Dicho de otro modo: la Comisión está poniendo al día las remisiones a normas ETSI, perfiles y procedimientos para que el texto reglamentario no se quede atrás respecto de la ingeniería de la cartera.

El momento no es casual. Con el plazo del 24 de diciembre de 2026 —fecha en la que los Estados miembros deben poner al menos una cartera a disposición de la ciudadanía— cada vez más cerca, esta tanda de normas afina tres piezas sensibles del ecosistema: el registro de las partes usuarias (relying parties), el núcleo funcional de la propia cartera y las declaraciones electrónicas de atributos. A continuación, la lista con lo esencial de cada uno.

Para quien siga el hilo de este blog, estos tres textos no son una sorpresa: ya los comenté cuando se publicaron como borradores, en Nuevos borradores de actos de ejecución en relación con #eIDAS2 y la EUDI Wallet (febrero de 2026). Desde entonces he seguido cubriendo los desarrollos normativos —el último acto que reseñé fue el Reglamento de Ejecución (UE) 2026/798, sobre la incorporación a distancia de usuarios a la Cartera IDUE— y mantengo al día la lista completa de actos de ejecución que acompañan a #eIDAS2 que publiqué el 2 de febrero de 2026 en la que iré incorporando estas tres novedades.

Los 3 Reglamentos de Ejecución

1. Reglamento de Ejecución (UE) 2026/1730

  • Fecha: adoptado el 15 de julio de 2026; publicado en el DOUE el 22 de julio de 2026.
  • Qué modifica: el Reglamento de Ejecución (UE) 2025/848, de 6 de mayo de 2025, sobre el registro de las partes usuarias de las carteras (wallet-relying parties).
  • En breve: actualiza las normas y especificaciones aplicables al registro de las partes usuarias. Entre los ajustes destaca el reforzamiento de la información de transparencia —por ejemplo, que las partes usuarias faciliten una URL a su política de privacidad en relación con el uso previsto de la cartera—.
  • Entrada en vigor: a los veinte días de su publicación (11 de agosto de 2026).
  • Texto completo: Español · English.

2. Reglamento de Ejecución (UE) 2026/1731

  • Fecha: adoptado el 15 de julio de 2026; publicado en el DOUE el 22 de julio de 2026.
  • Qué modifica: de una sola vez, los cuatro reglamentos del núcleo normativo de la cartera adoptados el 28 de noviembre de 2024:
    • (UE) 2024/2977 — datos de identificación de la persona (DIP / PID) y declaraciones electrónicas de atributos expedidas a las carteras;
    • (UE) 2024/2979 — integridad y funcionalidades básicas de las carteras;
    • (UE) 2024/2980 — notificaciones a la Comisión relativas al ecosistema de la cartera;
    • (UE) 2024/2982 — protocolos e interfaces que admitirá el marco europeo de identidad digital.
  • En breve: es la modificación de mayor alcance de la tanda. Pone al día las normas y especificaciones técnicas del corazón de la cartera para reflejar la nueva versión del ARF, garantizando la interoperabilidad transfronteriza.
  • Entrada en vigor: a los veinte días de su publicación.
  • Texto completo: Español · English.

3. Reglamento de Ejecución (UE) 2026/1735

  • Fecha: adoptado el 15 de julio de 2026; publicado en el DOUE el 22 de julio de 2026.
  • Qué modifica: el Reglamento de Ejecución (UE) 2025/1569, de 29 de julio de 2025, sobre las declaraciones electrónicas cualificadas de atributos (DECA / QEAA) y las declaraciones electrónicas de atributos expedidas por un organismo del sector público responsable de una fuente auténtica (o en su nombre).
  • En breve: actualiza los requisitos de expedición y revocación de estas declaraciones y —novedad relevante— introduce la firma o sellado de los resultados de la verificación frente a fuentes auténticas, exigiendo al menos una firma electrónica avanzada basada en certificado cualificado (o un sello electrónico avanzado basado en certificado cualificado). Incorpora remisiones a normas ETSI (TS 119 471 y TS 119 478) y contó con dictamen del Supervisor Europeo de Protección de Datos (SEPD) de 17 de abril de 2026.
  • Entrada en vigor: a los veinte días de su publicación (11 de agosto de 2026), con una salvedad: el artículo 1.3 se aplica desde el 1 de enero de 2027.
  • Texto completo: Español · English.

La velocidad en la generación de normas conlleva que pueda ser necesaria su modificación

Vistos en conjunto, estos tres reglamentos confirman la tendencia de los últimos meses: el marco de eIDAS 2 ya no crece tanto en nuevas piezas como en mantenimiento fino de las existentes, sincronizándolas con un ARF vivo. Para quienes desarrollan carteras, actúan como partes usuarias o emiten declaraciones de atributos, el mensaje operativo es claro: conviene revisar las referencias normativas actualizadas antes del hito de nochebuena, con especial atención a la transparencia hacia el usuario (2026/1730) y a la firma/sellado de las verificaciones frente a fuentes auténticas (2026/1735).


Referencias

Antecedentes en este blog:

La Cartera de Identidad Digital Europea en el programa de radio «Cruce de Cables»


Cartera digital europea, iconos del pasado y un Papa robótico

En el programa de radio de RNE«Cruce de cables» del 14/06/2026 charlamos sobre la próxima llegada de la cartera digital europea, de porqué seguimos usando iconos del pasado en la tecnología actual y nos detemos en ‘Project Pope’, un relato futurista sobre un «Papa electrónico» -un superordenador al que alimentan con todo el conocimiento del universo.

Esta semana, en Cruce de cables (93), ponemos el foco en la futuracartera digital europea, una aplicación oficial impulsada por la Unión Europea que permitirá a los ciudadanos identificarse, almacenar documentos como el DNI o el carnet de conducir y realizar gestiones online de forma segura en cualquier país miembro. Analizamos sus implicaciones conJulián Inza, director del Laboratorio de Confianza Digital del Observatorio Legaltech Garrigues-ICADE.

Además,Álvaro Ibáñez, ‘Alvy’ de Microsiervos, nos explica por quéseguimos utilizando iconos heredados de hace décadasen nuestros ordenadores y por qué, probablemente, no van a desaparecer.Carolina Denia nos trae «tecnología que no lo parece», como la nueva pulsera cuantificadora de Google, Fitbit Air, que prescinde de pantalla. Y aprovechando la actualidad,Gisela Bañosnos habla sobre‘Project Pope’(Clifford D. Simak, 1981) que plantea la historia de un planeta donde una inteligencia artificial intenta calcular todas las posibles interpretaciones de Dios.

Desde la redacción deDevuego, Jon Fernández recomienda el videojuego de la semana:‘007 First Light’. Y, por último,Antonio Pulidonos presenta a cuatro participantes delproyecto europeo EITIC-EU, impulsado por Erasmus+ y coordinado por Fundación Cibervoluntarios, que busca inspirar y empoderar a niñas y jóvenes de entre 10 y 16 años para que se acerquen a las carreras STEAM.

Gracias a David Sierra, por contar con el Laboratorio de Confianza Digital del Observatorio Legaltech Garrigues-ICADE para comentar estas cosas en su programa Cruce Cables.

Formación sobre «Identidad Digital» en el Cyber Bootcamp Málaga de 2026


Agradezco a la organización de Cyber Bootcamp Málaga que haya vuelto a contar conmigo este año 2026 para impartir la sesión sobre Identidad Digital en el Módulo Avanzado.

Mi clase tendrá lugar la mañana del lunes 6 de julio de 2026 tras la inauguración. Inicialmente de 9 a 13:30, aunque se empezará un poco más tarde para dar tiempo a los discursos de apertura en el auditorio y para pasar desde el auditorio hasta el aula concreta en la que se imparte.

Seguramente haré una pequeña pausa de un minuto a las 12 de la mañana, porque, siendo de Pamplona, me acordaré de que a esa hora se lanza el chupinazo con el que se inician las fiestas de San Fermín.

Cyber Bootcamp Málaga está dirigido a todos los estudiantes de universidades públicas españolas. Es posible inscribirse hasta el 6 de junio de 2026.

El programa de Cyber Bootcamp Málaga se articula en dos itinerarios formativos simultáneos, diseñados para adaptarse al nivel previo del alumnado y maximizar el aprovechamiento del curso. Se denominan Módulo Básico y Módulo Avanzado.

  • La modalidad básica de Cyber Bootcamp Málaga tiene un carácter interdisciplinar, dirigido a todos los perfiles universitarios que estén interesados en iniciarse en el campo de la ciberseguridad.
  • La modalidad avanzada tiene un carácter de especialización en la materia, y está dirigido al alumnado que ya tenga previamente formación reglada universitaria en ciberseguridad. 

No es posible compaginar ambas modalidades, dado que además están orientadas a perfiles distintos de alumnado.

Para la edición de 2026, el curso se celebrará del 6 al 16 de julio. Las dos modalidades del curso se impartirán simultáneamente de forma presencial. Esta es la segunda edición (tras la de 2025) y será la última.

El coste de este curso está completamente financiado por Google.org. Es decir, es completamente gratuito para todos los alumnos que participen en el Cyber Bootcamp Málaga. Incluye la formación, los traslados desde su ciudad y el alojamiento durante el periodo del curso. 

La edición Cyber Bootcamp Málaga 2026 vuelve a contar con un total de 100 plazas, 50 para la modalidad Básica y 50 para la modalidad Avanzada, que se impartirán simultáneamente, y de forma estrictamente presencial (no será posible la participación online).