Identidad digital, Cartera IDUE, Firma electrónica, Archivo digital, blockchain, Medios de pago, eBanca, administración de justicia. administración pública, Seguridad Jurídica Preventiva Digital
He revisado el procedimiento que se utiliza en @firma para explicar la inclusión y clasificación de certificados electrónicos de los Prestadores de Servicios Electrónicos de Confianza y su validación electrónica en entornos de Administraciones Públicas. Es la versión 3.9 del documento «Procedimiento de inclusión y clasificación de certificados en @firma«, publicado en 2018.
Es un documento útil y, en algunos aspectos ya tuvo en cuenta algunos términos alineado con eIDAS —habla de certificados cualificados y de dispositivos QSCD—, pero conserva referencias del marco regulatorio anterior (la Ley 59/2003, terminología de «certificación reconocida», mención al extinto MINETUR y varias URLs obsoletas) que conviene depurar. A continuación resumo las actualizaciones que sugeriría, agrupadas en cuatro bloques. He preparado además una tabla de correcciones que he puesto a disposición de la unidad responsable de publicar el documento oficial.
1. Legislación
Ley 59/2003, de firma electrónica: está derogada. La norma vigente en el ámbito nacional es la Ley 6/2020, de 11 de noviembre, reguladora de determinados aspectos de los servicios electrónicos de confianza. Todas las remisiones a la Ley 59/2003 deberían sustituirse.
Reglamento (UE) 910/2014 (eIDAS): sigue vigente, pero está modificado por el Reglamento (UE) 2024/1183 (eIDAS2). Conviene citar esta modificación y, donde proceda, los reglamentos de ejecución de 2024, 2025 y 2026.
2. Terminología
El vocabulario de la Directiva 1999/93/CE y de la Ley 59/2003 quedó sustituido por el de eIDAS:
el «certificado reconocido» se denomina ahora «certificado cualificado«; la «firma reconocida» es ahora la «firma electrónica cualificada«.
un «prestador de servicios de certificación (PSC)» es ahora un «prestador (cualificado) de servicios electrónicos de confianza» (PSCC / QTSP). El acrónimo «PSC» ya no se lee igual.
un «dispositivo seguro de creación de firma (DSCF/SSCD)» ahora se denomina «dispositivo cualificado de creación de firma (QSCD)». El documento aún mezcla los términos SSCD y QSCD; convendría unificar al uso de las siglas QSCD.
En la lógica de lectura de la lista de confianza (TSL), las extensiones QCWithSSCD/QCNoSSCD fueron sustituidas por QCWithQSCD, QCNoQSCD y QCQSCDManagedOnBehalf (ETSI TS 119 612 v2).
Los estados y tipos heredados del modelo de acreditación anterior a eIDAS (accredited, undersupervision, supervisionceased/revoked, accreditationceased/revoked, setbynationallaw, recognisedatnationallevel, NationalRootCA-QC…) deberían revisarse: con eIDAS el estatus cualificado se expresa esencialmente como granted / withdrawn (más los transitorios), y desaparece el concepto de «acreditación».
3. Organismos
MINETUR – Ministerio de Industria, Energía y Turismo ya no existe. El organismo supervisor de los servicios electrónicos de confianza es hoy el Ministerio para la Transformación Digital y de la Función Pública – Secretaría de Estado de Digitalización e Inteligencia Artificial (SEDIA) (con una etapa intermedia como Ministerio de Asuntos Económicos y Transformación Digital).
La plataforma @firma, el Portal de Administración Electrónica (PAe) y la publicación de la lista de confianza dependen de la Secretaría General de Administración Digital (SGAD) de ese mismo ministerio (antes adscrita a Hacienda).
4. URLs y recursos
Los enlaces a minetur.gob.es (incluida la ubicación de la TSL en sede.minetur.gob.es/Prestadores/TSL/TSL.pdf) reflejan una marca ministerial obsoleta; conviene actualizarlos a la sede del Ministerio para la Transformación Digital y añadir, para la consulta a nivel UE, el eIDAS Dashboard / LOTL de la Comisión Europea.
La forja CTT (forja-ctt.administracionelectronica.gob.es) está descatalogada: los clientes y componentes de @firma se publican ahora en GitHub (github.com/ctt-gob-es) y en el PAe.
También conviene sustituir el prefijo http:// por https:// en todos los enlaces (las comunicaciones con TLS son ahora la versión por defecto), y verificar las rutas del PAe (p. ej. el «Anexo PSC» de @firma) y del soporte a integradores (CAID), que han podido cambiar de dirección.
*Esta es una sugerencia de mejora en clave colaborativa; el detalle «texto actual → propuesta → motivo» lo he recogido en una tabla que facilito a la unidad responsable. No constituye asesoramiento jurídico.*
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.
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).
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.
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.
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
Reglamento de Ejecución (UE) 2026/1730 — DOUE 22/07/2026 · BOE/DOUE · ELI
Reglamento de Ejecución (UE) 2026/1731 — DOUE 22/07/2026 · BOE/DOUE · ELI
Reglamento de Ejecución (UE) 2026/1735 — DOUE 22/07/2026 · BOE/DOUE · ELI
España es, con diferencia, el país europeo con mayor número de Prestadores Cualificados de Servicios de Confianza (QTSP) activos en la lista de confianza europea (TSL). Mientras que la mayoría de los Estados miembros cuentan con una decena o menos, España supera los cincuenta prestadores registrados, si bien varios se dedican solo a los Sellos de tiempo. Esta alto número de prestadores ha permitido cierta especialización, de modo que existen variantes de certificados poco conocidas incluso entre los propios profesionales del sector.
Este artículo intenta trazar un mapa completo de los tipos de certificados cualificados que se emiten en España y señalar cuáles son los más inusuales y quiénes los emiten.
La taxonomía básica de certificados: lo que todos conocen
El Reglamento eIDAS establece tres grandes familias de certificados cualificados:
Certificados de firma electrónica (art. 28 eIDAS): se emiten a personas físicas para que firmen en su propio nombre.
Certificados de sello electrónico (art. 38 eIDAS): se emiten a personas jurídicas para sellar documentos de forma automatizada.
Certificados de autenticación de sitios web (art. 45 eIDAS): los QWAC, que autentican servidores web.
Dentro de los certificados de firma, el más habitual es el de persona física simple, que identifica al titular únicamente por su nombre y número de documento. Le sigue el de representante de persona jurídica, que añade los datos de la entidad en cuyo nombre actúa el firmante. En el ámbito del sello, el más extendido es el sello de entidad genérico.
Estos tres tipos los emite prácticamente la totalidad de los QTSPs españoles: que emiten certificados FNMT, Camerfirma, Izenpe, ACCV, Firmaprofesional, ANF, Uanataca, DigitelTS, EADTrust, AC Notarial, Logalty y muchos otros. Son el producto de catálogo estándar.
Tipos de certificados específicos del sector público español
Aquí empiezan a verse diferencias. La legislación española —en particular la Ley 40/2015 y sus desarrollos técnicos— define tipos de certificados propios para la Administración Pública que no tienen equivalente directo en otros países europeos:
Certificado de empleado público
Identifica a la persona física como funcionario o trabajador de una administración determinada. Incluye el cargo u órgano al que pertenece. Existen varias modalidades según el nivel de seguridad definido por el ENS: medio/sustancial y alto.
No todos los QTSPs lo emiten porque requiere diseñar perfiles especiales con la expectativa de ser proveedor de las administraciones públicas, o o ser, de hecho uno de tales proveedores. .requieren, además, diseñar un proceso de verificación de los datos de empleo. Entre los que sí lo hacen destacan la FNMT, ACCV, Izenpe (para el País Vasco) y, entre los prestadores privados de ámbito estatal, EADTrust y Camerfirma.
Sello de órgano de la Administración Pública
Es el equivalente al sello de entidad, pero con el perfil técnico definido en el documento «Perfiles de Certificados Electrónicos» de la AAPP (cuya gestión corresponde gestionado al Ministerio de Transformación Digital). Identifica al órgano administrativo —no a la entidad jurídica completa— como la Dirección General X de un ministerio, por ejemplo. Se usa para el sellado automatizado de notificaciones, resoluciones y otros actos administrativos.
La casuística incluye también un uso particular: el Document Signing Certificate (DSC) para los Pasaportes COVID de la UE. EADTrust operó como CSCA (Certificate Signing Certificate Authority) de España en este contexto, emitiendo certificados de sello de órgano con OIDs específicos para test, vacunación y recuperación.
Sede electrónica administrativa (QWAC EV)
El certificado de sede electrónica es técnicamente un QWAC de Extended Validation, pero con perfil específico para administraciones públicas. Identifica el dominio web como sede electrónica oficial de un organismo público, con los campos de razón social y número de registro propios de la AAPP. Es obligatorio para toda sede electrónica de la Administración General del Estado y muchas autonómicas.
La combinación de los tres tipos anteriores —empleado público, sello de órgano y sede electrónica— la ofrecen muy pocos prestadores privados. EADTrust es uno de ellos, lo que la sitúa en un segmento especializado que la mayoría de los QTSPs genéricos no cubre.
Los certificados con seudónimo: los grandes desconocidos
Este es, probablemente, el territorio menos explorado del ecosistema de certificados cualificados español. La norma eIDAS permite que un certificado cualificado incluya un seudónimo en lugar del nombre real del titular (art. 28.4 eIDAS), siempre que así lo exija la legislación nacional. En España, dos ámbitos hacen uso de esta posibilidad.
Certificado de empleado público con seudónimo (AAPP)
Diseñado para funcionarios que realizan actuaciones que deben quedar amparadas por la confidencialidad de la función pública —por ejemplo, inspectores, investigadores o personal de inteligencia— pero que necesitan firmar electrónicamente con validez cualificada. El certificado contiene un seudónimo que permite identificar al titular ante la administración competente, pero no lo expone públicamente.
Existen perfiles de nivel alto (para firma y para autenticación por separado) definidos por el CTEAJE (en Justicia) y la AAPP española.
Certificado de empleado de la Administración de Justicia con seudónimo
Perfil específico desarrollado por el Comité Técnico Estatal de la Administración Judicial Electrónica (CTEAJE), recogido en el documento «Perfil de Certificado con Seudónimo Justicia V1.0». Lo usan jueces, fiscales y otros operadores jurídicos que necesitan firmar resoluciones judiciales electrónicamente sin que su identidad real quede expuesta en el documento firmado. El seudónimo los identifica ante los sistemas de la administración de Justicia, pero no ante el público general.
Estos dos tipos de certificado con seudónimo los emite en España un número muy reducido de prestadores. La FNMT los emite para los sistemas de Justicia del Estado; EADTrust los tiene recogidos en su DPC (v5.5) tanto para el ámbito AAPP como para Justicia. Sin embargo, a pesar de estar técnicamente disponibles, estos certificados tienen poca visibilidad en los catálogos públicos de los prestadores. Es una de las áreas con mayor potencial de difusión.
Certificados PSD2: un nicho regulatorio
La Directiva de Servicios de Pago (PSD2) obliga a las entidades financieras a exponer APIs abiertas para el acceso a cuentas y servicios asociados como los AISP y PISP. Para autenticar en esas APIs se utilizan dos tipos específicos de certificados, definidos en la norma ETSI TS 119 495:
QWAC PSD2 (Qualified Web Authentication Certificate para PSD2): autenticación mutua TLS entre el proveedor de servicios de pago y el banco.
QSealC PSD2 (Qualified Seal Certificate para PSD2): sellado de mensajes en la comunicación entre PSPs.
Ambos incluyen atributos especiales en la extensión `qcStatements` que indican los roles del prestador: PISP (Payment Initiation Service Provider), AISP (Account Information Service Provider) o PSP-IC (Issuing of Card-based Payment Instruments).
Los emiten en España varios QTSPs, entre ellos ACCV, Camerfirma, EADTrust, Firmaprofesional y algunos otros. El proceso de verificación requiere acreditar ante el Banco de España (u otro supervisor nacional) la autorización del solicitante como PSP, lo que limita este mercado a entidades financieras reguladas.
Certificados para la AEAT: la entidad sin personalidad jurídica
La Agencia Tributaria utiliza certificados cualificados para una variedad de trámites. Además de los tipos estándar (persona física, representante de persona jurídica, sello de entidad), existe un tipo poco conocido: el certificado de representante de entidad sin personalidad jurídica.
Este tipo cubre comunidades de bienes, herencias yacentes, UTEs (uniones temporales de empresas) y otras figuras que operan con NIF pero no tienen personalidad jurídica propia. En la práctica, el representante firma en nombre de la comunidad o UTE con un certificado que identifica explícitamente esta relación.
La FNMT es el emisor principal de este tipo de certificado en España, vinculado directamente a los procedimientos de la AEAT.
Certificados de titulado
SIGNE es un QTSP que colabora frecuentemente con las universidades españolas. Además de los tipos estándar, emite el eTítulo, un certificado cualificado que acredita que el titular posee un título universitario oficial reconocido en España.
Este es uno de los tipos más singulares del panorama español. No es simplemente un certificado de persona física con atributos adicionales: incluye información sobre la titulación, la universidad emisora y el número de registro del título. Su uso principal es la firma de documentos académicos con la garantía de que el firmante posee la titulación que declara.
Certificados de colegiado
Varios colegios profesionales tienen su propia CA o acuerdo con un QTSP: el Consejo General de la Abogacía (CGAE) emite certificados de abogado a través de su propia infraestructura, los colegios de médicos operan a través del Consejo General de Colegios Oficiales de Médicos, el Consejo General del Notariado cuenta con ANCERT, y los registradores tienen su propia CA. El Prestador Firmaprofesional ha definido perfiles de certificado de Colegiado adecuados para múltiples colegios profesionales.
Estos certificados identifican al titular no solo como persona física, sino también como profesional en ejercicio de una determinada disciplina, con número de colegiado verificado por la institución emisora. Su validez para trámites específicos —firma de escrituras notariales, prescripciones médicas electrónicas, comunicaciones judiciales— está reconocida en la legislación sectorial correspondiente.
Certificados EPREL: un nicho europeo
EPREL (European Product Registry for Energy Labelling) es el registro europeo de etiquetado energético de la Comisión Europea. Las empresas que comercializan productos sujetos a etiquetado energético deben registrar sus productos en EPREL, y para ello necesitan un certificado cualificado de sello electrónico de persona jurídica (QSeal) que cumpla ciertos requisitos técnicos.
La mayoría de los QTSPs exigen que el solicitante figure en el Registro Mercantil para verificar su existencia como persona jurídica. Sin embargo, la obligación de registrar productos en EPREL afecta también a autónomos, asociaciones, fundaciones y otras entidades que no están inscritas en el Registro Mercantil. EADTrust es, hasta donde se conoce, el único QTSP español que emite certificados EPREL para este tipo de entidades, verificando su identidad a través de otros registros públicos o medios alternativos. Este detalle no suele aparecer en los comparativos de QTSPs, pero es determinante para muchas pymes y profesionales autónomos que comercializan productos con etiquetado energético.
Tabla resumen: tipos de certificados y QTSPs representativos
Tipo de certificado
Categoría eIDAS
QTSPs representativos
Singularidad
Persona física (PF)
Firma
Todos los principales
Estándar
Representante de PJ
Firma
Todos los principales
Estándar
Sello de entidad (PJ)
Sello
Todos los principales
Estándar
Empleado público
Firma
FNMT, ACCV, Izenpe, Camerfirma, EADTrust
España-específico
Sello de órgano AAPP
Sello
FNMT, ACCV, Izenpe, EADTrust
España-específico
Sede electrónica (QWAC EV)
Web
FNMT, Camerfirma, EADTrust
España-específico
Seudónimo AAPP
Firma
FNMT, EADTrust
Muy infrecuente
Seudónimo Justicia
Firma
FNMT, EADTrust
Muy infrecuente
QWAC PSD2
Web
ACCV, Camerfirma, EADTrust, Firmaprofesional
Regulatorio PSD2
QSealC PSD2
Sello
ACCV, Camerfirma, EADTrust, Firmaprofesional
Regulatorio PSD2
Representante entidad sin PJ
Firma
FNMT
AEAT-específico
eTítulo (titulado)
Firma
SIGNE
Único en España
Colegiado (abogado, médico, notario…)
Firma
CGAE, CGOCOM, ANCERT, Firmaprofesional
Sectorial
EPREL
Sello
EADTrust (documentado)
Nicho europeo
Conclusiones
Una de las conclusiones más llamativas de este análisis es que los catálogos públicos de los QTSPs suelen mostrar solo una fracción de los tipos de certificados que técnicamente emiten. Los casos más evidentes son los certificados con seudónimo: aunque EADTrust los tiene perfectamente definidos en su DPC con perfiles técnicos completos, apenas aparecen en la web comercial. Ocurre algo similar con los certificados de sede electrónica o con la validación explícita para EPREL.
En un mercado donde los compradores toman decisiones de licitación o contratación basándose en lo que ven en la web, la cobertura real de un QTSP puede ser muy superior a lo que parece. Publicar y difundir adecuadamente los tipos de certificado disponibles —especialmente los más especializados— no es solo marketing: es información técnica relevante para quienes los necesitan.
Contacte con EADtrust
Contacte con EADTrust si necesita certificados especiales info(at)eadtrust.com – 917160555
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.
La Autoridad de Sistemas de Información de Estonia (RIA) ha convocado una licitación para desarrollar e implementar una cartera de identidad digital europea (EUDI/IDUE) que cumpla con la normativa para su uso a nivel nacional.
La licitación refleja el cambio de rumbo de la política de identidad digital de la UE y los programas piloto hacia la implementación operativa de la infraestructura de la cartera en todos los Estados miembros, antes de que entren en vigor los requisitos de disponibilidad obligatoria de la cartera IDUE.
La licitación, por un importe de 21,65 millones de euros (25,1 millones de dólares estadounidenses), incluye la gestión del servicio durante cinco años a partir de su puesta en marcha. El contrato abarcará el desarrollo de software, la integración y la prestación continua del servicio en todo el Espacio Económico Europeo (EEE).
La licitación busca un único socio responsable de crear e implementar la cartera de acuerdo con los requisitos de la UE, y que también debe ser compatible con el ecosistema de identificación electrónica (eID) existente en Estonia. La empresa estonia de ciberseguridad e identidad digital Cybernetica, socio actual de la RIA, ha realizado previamente un análisis técnico de la arquitectura de la cartera y su potencial de interoperabilidad en los Estados miembros de la UE.
«Buscamos una solución integral de los licitadores que permita a los usuarios almacenar y presentar de forma segura datos de autenticación, utilizar diversos tipos de certificación de atributos y realizar firmas digitales», afirmó Margit Aus, responsable de la cartera EUDI en RIA.
RIA está utilizando un procedimiento de diálogo competitivo y espera invitar a entre tres y cinco candidatos a la segunda fase. El contrato, de 96 meses de duración, incluye múltiples opciones de prórroga.
El proyecto está clasificado como una contratación pública estratégica innovadora. Estonia tiene previsto crear el primer ecosistema de identidad digital centrado en el usuario y alineado con el marco de arquitectura común de la UE.
El enfoque de Estonia refleja el cambio generalizado en Europa de los sistemas de identidad centralizados basados en bases de datos hacia modelos de credenciales descentralizados y autosoberanos que permiten a los usuarios compartir de forma selectiva atributos verificados a través de las fronteras.
En el contrato se incluirán requisitos medioambientales y criterios de accesibilidad para personas con discapacidad. La licitación no se divide en lotes debido a las interdependencias técnicas y de seguridad del sistema.
Las solicitudes deben presentarse por vía electrónica antes del 29 de junio. La licitación está abierta en estonio e inglés. Se han publicado más detalles en el Registro de Contratación Pública.
A medida que los Estados miembros de la UE pasan de los programas piloto a las implementaciones a escala real, las licitaciones nacionales de carteras digitales se están convirtiendo en un campo de batalla clave para la próxima generación de infraestructura de identidad digital de Europa.
En Navarra, la Comunidad Foral en la que nací, está muy extendido el uso del euskera, aunque, por desgracia, yo no lo hablo, salvo algunas palabras aprendidas de mi abuela María.
Me hacía ilusión preparar una versión del documento «Cartera de Identidad Digital Europea – Arquitectura y Marco de Referencia V2.9.0» en euskera, ya que estoy seguro de que en Navarra y en el País Vasco existirá un buen número de «early adopters» (usuarios pioneros) que irán adoptando la terminología, inicialmente en ingles, del documento «EUDI Wallet – Architecture and Reference Framework «
Afortunadamente existen herramientas que ayudan en la traducción, pero nada comparable a que revise el texto final una persona que hable el idioma, especialmente en casos en los que, como en este, se usa mucha terminología técnica.
Pero de momento, no lo ha revisado una persona que hable el euskera como primera lengua y es por ello por lo que solicito voluntarios que me ayuden a perfeccionar el texto.
Si alguien se ofrece, que me contacte a través de julian (at) inza.net y vemos la forma de acometerlo. Si fueran varias personas, podría dividirse la faena asignando rangos de páginas a revisar a cada persona.
Lo más importante es definir el glosario de términos preferidos, ya que con este glosario, las futuras versiones del ARF que se obtengan por traducción automatizada serán mejores.
Otro punto de posible mejora sería definir el glosario para la traducción desde el inglés, por lo que la traducción sería más fiable. En este caso, la traducción se ha hecho desde el castellano.
Arkitektura eta Erreferentzia Marko V2.9.0
Nafarroan, nire jaioterrian, euskara oso zabalduta dago, nahiz eta, zoritxarrez, ez dudan hitz egiten, nire amama Mariarengandik ikasitako hitz batzuk izan ezik.
«European Digital Identity Wallet – Architecture and Reference Framework V2.9.0» dokumentuaren euskara bertsioa prestatzeko gogotsu nengoen, ziur nago Nafarroan eta Euskal Herrian terminologia pixkanaka hartuko duten «early adopters» asko egongo direla, hasieran ingelesez, «EUDI Wallet – Architecture and Reference Framework» dokumentutik.
Zorionez, itzulpenean laguntzeko tresnak daude eskuragarri, baina ezerk ez du parekorik azken testua hiztun jatorriko batek berrikustea, batez ere hemen bezala terminologia tekniko ugari erabiltzen denean.
Hala ere, orain arte ez du eusko hiztun jatorriko batek berrikusi, eta horregatik deitzen dut boluntarioak testua zehaztasun handiagoz landatzen laguntzeko.
Norbaitek laguntzeko prest badago, mesedez, jarri nirekin harremanetan julian (at) inza.net helbidean eta eztabaidatu dezakegu nola jokatu. Pertsonak badira, lana banatu daiteke, bakoitzari berrikusteko orrialde-tarte batzuk esleituz.
Garrantzitsuena da termino nagusien glosarioa definitzea, glosario horri esker makina-itzulpen bidez sortutako ARFren etorkizuneko bertsioek kalitate handiagoa izango dutela ziurtatuko baita.
Hobekuntza potentzialerako beste arlo bat ingelesetik itzultzeko glosarioa definitzea litzateke, itzulpena fidagarriagoa egiteko. Kasu honetan, itzulpena espainieratik egin da.
Explica la arquitectura: detalla los componentes del sistema y sus interacciones, Cartera de Identidad Digital Europea sirviendo de información de referencia para los requisitos de alto nivel (HLR) que figuran en el anexo 2.
Orienta la implementación: actúa como referencia común para la implementación armonizada del [Reglamento sobre la Identidad Digital Europea], orientando el desarrollo de especificaciones técnicas, normas y procedimientos operativos.
Apoya el desarrollo de la implementación de referencia: se utiliza para desarrollar la implementación de referencia de la solución de cartera digital y servirá de base para futuras actualizaciones de los actos de ejecución en función de los avances tecnológicos.
Este ARF tiene carácter informativo y está destinado a apoyar la implementación; no sustituye al [Reglamento sobre la Identidad Digital Europea], que es jurídicamente vinculante, ni a sus actos de ejecución y delegados adoptados, que son los únicos requisitos obligatorios.
Este documento se aplica exclusivamente a los ecosistemas de Cartera IDUE que cumplen con el Reglamento. Representa el estado actual de la situación del Grupo de Cooperación sobre la Identidad Digital Europea y se actualizará con el tiempo.
El público destinatario del ARF está compuesto por:
Entidades que actúan como prestadores de DIP, prestadores de DECA, prestadores de DEA-AAPP o prestadores de DEA no cuaificadas,
Prestadores de carteras,
Partes usuarias (o informadas),
Organismos de Evaluación de Conformidad (OEC) y
Organismos de supervisión.
En esta versión del ARF se han introducido los siguientes cambios:
Cambios derivados de los comentarios recibidos de la Agencia ENISA en el contexto de la línea de trabajo sobre certificación de Carteras.
Cambios debidos al documento de debate de la ronda de revisión para el Tema C (Declaraciones clave y declaraciones de instancias de cartera).
Se han resuelto varias cuestiones planteadas a través de Confluence y GitHub.
Aparte de estos cambios, se han corregido algunos errores editoriales
Las Unidades de Cartera para personas jurídicas, que podrían contener un DIP de Persona Jurídica, se han eliminado de este ARF en vista del desarrollo de una cartera empresarial independiente que se está impulsando a nivel normativo.
El Artículo 5 septies del Reglamento (UE) 2024/1183, conocido como eIDAS 2, introduce una obligación directa para algunas empresas del sector privado: a más tardar en diciembre de 2027 (36 meses después de la entrada en vigor tras su publicación de los actos de ejecución correspondientes), las entidades obligadas deberán aceptar la Cartera de Identidad Digital de la Unión Europea (EUDI Wallet) como medio de identificación y autenticación reforzada del usuario.
Esta obligación afecta a todas las entidades que, por disposición legal o contractual, deban realizar una autenticación reforzada del cliente (SCA – Strong Customer Authentication) conforme al Reglamento (UE) 2016/679 (RGPD), la Directiva PSD2 o normativa sectorial específica.
Salvo microempresas y pequeñas empresas de los sectores aludidos.
La Cartera funciona mediante declaraciones electrónicas de atributos basadas en estándares abiertos (ISO/IEC 18013-5, OpenID4VCI y OpenID4VP), lo que permite la divulgación selectiva de atributos y la firma criptográfica de pruebas de posesión, sin que el prestador de servicios almacene datos biométricos ni documentos.
A continuación se detallan los casos de uso técnicos principales de onboarding (contratación inicial) y autenticación posterior por cada sector referenciado en el artículo 5 septies.
1. Banca y servicios financieros
Onboarding: El usuario presenta su Cartera a través de un flujo OpenID4VP. El banco recibe, en tiempo real los Datos de Identificación Personal (DIP) del titular de la Cartera (DNI/NIE, datos de residencia, fecha de nacimiento y, opcionalmente, mediante Declaraciones Electrónicas de Atributos complementarias, otros datos como nivel de ingresos o scoring crediticio). Se elimina la necesidad de videoidentificación o carga manual de documentos. La cartera puede gestionar la firma electrónica cualificada (QES, Qualified Electronic Signature) del contrato, por lo que todo el proceso podría completarse en uno o dos minutos.
Autenticación para acceder al servicio: Login en banca online o app móvil mediante protocolo OpenID Connect con presentación de credencial firmada. La Cartera actúa como segundo factor criptográfico (equivalente a un dispositivo seguro), cumpliendo los requisitos de SCA de PSD2 y sustituyendo o complementando OTP y contraseñas.
2. Suministros (empresas eléctricas, de gas y de agua)
Onboarding: Contratación de nuevo punto de suministro o cambio de comercializadora. La Cartera entrega atributos verificados de titularidad y domicilio, permitiendo la activación inmediata del contrato sin intervención manual. La cartera puede gestionar la firma electrónica cualificada a distancia del contrato,
Autenticación para acceder al servicio: Acceso al área de cliente para consulta de consumos, facturas o modificación de potencia contratada. La integridad criptográfica garantiza que solo el titular autorizado pueda modificar datos sensibles.
3. Telecomunicaciones
Onboarding: Alta de línea móvil, fibra óptica, servicios audiovisuales o paquete convergente. Verificación automática de identidad y titularidad sin videollamada ni envío de documentación. El operador recibe, en tiempo real los Datos de Identificación Personal (DIP) del titular de la Cartera (DNI/NIE, datos de residencia, fecha de nacimiento).
Autenticación para acceder al servicio: Login en la app del operador para gestión de la línea, portabilidades o contratación adicional de servicios complementarios. Ideal para procesos que requieren SCA (cambio de titular, eSIM, etc.).
4. Transporte
Onboarding: Compra de abonos de transporte, alquiler de vehículos o contratación de seguros de viaje. La Cartera puede entregar atributos verificados del carnet de conducir o pasaporte.
Autenticación para acceder al servicio: Validación de títulos de transporte digitales o acceso a plataformas de movilidad compartida. La credencial permite la verificación offline y online con firma de prueba de posesión. Podría controlar la interfaz NFC para que la propia cartera se pueda usar como título de transporte.
5. Sanidad
Onboarding: Alta en plataformas de telemedicina, contratación de seguros médicos privados o integración en sistemas de historial clínico compartido.
Autenticación para acceder al servicio: Login seguro para consulta de resultados, recetas electrónicas o citas. La divulgación selectiva protege datos de salud especialmente sensibles (art. 9 RGPD). Posible uso en farmacias para la dispensación de medicamentos.
6. Educación
Onboarding: Matrícula en universidades privadas, plataformas de formación continua o cursos de posgrado. Con posibilidad de aportar Declaraciones Electrónicas de Atributos de haber superado cierto nivel formativo cuando se exige para matricularse en otro superior.
Autenticación para acceder al servicio: Acceso a campus virtuales, entrega de exámenes o consulta de calificaciones, presentación de trabajos. La Cartera puede portar credenciales académicas verificadas (títulos, certificados de competencias).
7. Otros servicios básicos y plataformas en línea de muy gran tamaño (VLOPs)
Onboarding: Contratación de servicios postales premium, infraestructuras críticas o cualquier servicio que requiera SCA.
Autenticación para acceder al servicio: Gestión de envíos, seguimiento o acceso a portales de infraestructuras.
Caso específico de VLOPs (X, Google y Microsoft)
El párrafo 3 del artículo 5 septies impone una obligación específica a las plataformas definidas como Very Large Online Platforms (VLOPs) conforme al artículo 33 del Digital Services Act (Reglamento (UE) 2022/2065): cuando requieran autenticación del usuario para acceder a sus servicios en línea, deberán aceptar y facilitar el uso de la Cartera de Identidad Digital Europea (EUDI Wallet) para la autenticación, siempre bajo petición voluntaria del usuario y limitándose a los datos mínimos necesarios para el servicio concreto.
Esta obligación entra en vigor en el mismo plazo que para el resto del sector privado (diciembre de 2027) y busca reducir el fraude, mejorar la verificación de edad, combatir cuentas falsas y garantizar el cumplimiento del principio de minimización de datos del RGPD.
X: Autenticación reforzada para cuentas verificadas, funciones premium (X Premium) o publicación de contenido monetizado. La Cartera permite verificación de identidad real mediante divulgación selectiva y firma de prueba de posesión, reduciendo significativamente cuentas falsas y bots sin necesidad de vincular cuentas externas. Soporte técnico mediante OpenID4VP.
Google: Login en Gmail, YouTube, Google Workspace o Google Play Store mediante protocolo OpenID4VP. Ejemplos prácticos incluyen verificación de edad para contenido restringido (sin revelar la fecha de nacimiento), autenticación en Workspace para empresas o compras en Play Store. La Cartera actuaría como credencial única, eliminando la necesidad de contraseñas o factores adicionales y facilitando el cumplimiento de normativas de protección de menores.
Microsoft: Autenticación en Microsoft 365, Azure (Entra ID), Outlook o Xbox. Especialmente relevante en entornos B2B y educativos, donde la trazabilidad criptográfica y la Wallet Attestation garantizan el cumplimiento de políticas de seguridad corporativa y permiten single sign-on (SSO) con credenciales verificadas de forma nativa.
En todos los casos, las VLOPs deben implementar los flujos de presentación de credenciales (OpenID4VP) y respetar el principio de minimización de datos.
Cómo prepararse: hoja de ruta técnica para entidades obligadas
Se sugiere a las empresas obligadas que reserven presupuesto para llevar a cabo los trabajos de adaptación durante 2026 y 2027:
Diagnóstico (Q3-Q4 2026): Mapear todos los procesos que requieren SCA y evaluar el impacto de la obligación.
Integración técnica (2026-2027):
Implementar endpoints OpenID4VCI / OpenID4VP y soporte para Wallet Attestation.
Conectar con un servicio cualificado de archivo electrónico (conforme al Reglamento de Ejecución (UE) 2025/2532) para conservar las evidencias de presentación.
Adaptar sistemas de backend para procesar Verifiable Credentials y Selective Disclosure.
Certificación y auditoría: Obtener certificación eIDAS como Qualified Trust Service Provider (QTSP) o contratar uno ya acreditado.
Formación y gobernanza: Designar un Responsable de la Cartera Digital y actualizar políticas de privacidad y seguridad.
Pruebas piloto: Participar en los entornos sandbox de la Comisión Europea o en los pilotos nacionales.
Las entidades que inicien la preparación en 2026 contarán con ventaja competitiva y evitarán sanciones por incumplimiento.
EADTrust, tu aliado para la transición
En EADTrust ya prestamos servicios cualificados de confianza (certificados para la firma electrónica cualificada y para el sello electrónico cualificado, sello de tiempo cualificado y archivo electrónico) y ya contamos con implementaciones de cartera que se adaptan a los proyectos.
Participamos en el CSC Interoperability Event 2026 en Bucarest con nuestra herramienta de Firma Remota que se puede invocar desde diferentes despliegues de Cartera.
Ofrecemos consultoría especializada para la integración de la EUDI Wallet.
Nuestro equipo de especialistas en Confianza Digital puede ayudarte a cumplir el artículo 5 septies de forma ágil y conforme a la normativa publicada.
La cartera de Identidad Digital Europea (EUDI Wallet, en inglés) es una aplicación digital segura y controlada por el usuario que permite a los ciudadanos gestionar su identidad oficial y otros datos personales. Permite a los usuarios solicitar información digital verificada (denominada «declaración») a prestadores de confianza (denominados «prestadores de DIP» y «prestadores de declaraciones de atributos»), almacenar dicha información y presentarla a partes usuarias (informadas) de una manera que prioriza la privacidad y la seguridad.
Se describe en un documento denominado «Arquitectura y Marco de Referencia» que va por la versión V2.8.0
Se trata de la “hoja de ruta técnica” publicada y mantenida por la Comisión Europea (en colaboración con los Estados miembros a través del European Digital Identity Cooperation Group) para garantizar que todas las carteras digitales nacionales sean interoperables, seguras y respetuosas con la privacidad en toda la Unión Europea.
Su primera versión se creó a partir de la Recomendación de la Comisión (UE) 2021/946 de junio de 2021, que pidió a los Estados miembros desarrollar una “Caja de Herramientas Común de la Unión” (Toolbox). Dentro de esa caja, el ARF es el pilar técnico principal. Posteriormente se ha ido actualizando para alinearse con el Reglamento de Identidad Digital Europea (eIDAS 2.0, Reglamento (UE) 2024/1183) y con decenas de Reglamentos de Ejecución (CIR) adoptados entre 2024 y 2026.
El ARF por sí mismo no es una norma legal (es un documento informativo y de referencia), pero recopila el articulado de actos de ejecución y es la base que usan:
Los Estados miembros para desarrollar sus propias carteras.
Los proveedores de carteras (Wallet Providers).
Los pilotos a gran escala (Large-Scale Pilots o LSP).
La propia Comisión para crear la implementación de referencia.
He traducido varias versiones anteriores y ahora presento la traducción correspondiente a la versión 2.8.0 (de febrero de 2026),
El documento de «Arquitectura y Marco de Referencia» define los siguientes aspectos del ecosistema de Cartera IDUE:
El capítulo 2 describe las principales funcionalidades de una Unidad de Cartera, desde la perspectiva del usuario.
El capítulo 3 describe las funciones clave dentro del ecosistema de Cartera IDUE, con sus responsabilidades asociadas.
El capítulo 4 describe la arquitectura del ecosistema de Cartera IDUE, incluidos sus principios de diseño, los componentes que conforman una Unidad de Cartera y las interfaces entre una Unidad de Cartera y otras entidades, los flujos de presentación de declaraciones de proximidad y remotas, las diferentes arquitecturas que pueden utilizarse para implementar un DCSC, los ciclos de vida de las principales entidades y componentes, y la implementación de la generación y presentación de seudónimos.
El capítulo 5 describe los elementos que componen una declaración de atributos, las diferentes categorías de declaraciones de atributos y los catálogos asociados, y los diferentes protocolos de presentación de cada declaración.
El capítulo 6 contiene el modelo de confianza para el ecosistema de Cartera IDUE. Para cada una de las principales entidades y componentes del ecosistema, este capítulo describe los mecanismos utilizados para garantizar que las entidades con las que interactúa puedan confiar en él a lo largo de su vida útil. Estos mecanismos pueden incluir la inscripción, la revocación, la autenticación y la autorización.
El capítulo 7 aborda la certificación de la solución de Cartera y la gestión de riesgos.
El capítulo 8 aborda la accesibilidad de todos los componentes del ecosistema de Cartera IDUE orientados al usuario.
El capítulo 9 describe cómo se ha elaborado y se seguirá elaborando este documento.
El capítulo 10 contiene una lista de referencias.
En el documento se han tenido en cuenta los Reglamentos de Ejecución de la Comisión adoptados:
CIR 2024/2977 relativo al DIP y al DEA,
CIR 2024/2979 relativo a la integridad y las funcionalidades básicas,
CIR 2024/2980 relativo a las notificaciones del ecosistema,
CIR 2024/2981 relativo a la certificación de soluciones de cartera,
CIR 2024/2982 sobre protocolos e interfaces,
CIR 2025/846 sobre la verificación transfronteriza de la identidad,
CIR 2025/847 sobre violaciones de seguridad de las Carteras de Identidad Digital Europea,
CIR 2025/848 sobre la inscripción de las Partes usuarias (o informadas) que confían en las carteras,
CIR 2025/849 relativa a la lista de carteras de Identidad Digital Europea certificadas,
CIR 2025/1566 sobre la verificación de la identidad y los atributos de un titular de un QC o DECA,
CIR 2025/1567 sobre la gestión de QSCD remotos como servicios de confianza cualificados,
CIR 2025/1568 sobre revisiones por pares de los sistemas de identificación electrónica,
CIR 2025/1569 relativa a los DECA y los DEA proporcionados por un organismo del sector público responsable de una fuente auténtica, o en su nombre,
CIR 2025/1570 relativa a la notificación de información sobre QSCD certificados,
CIR 2025/1571 sobre los formatos y procedimientos para los informes anuales de los organismos de supervisión,
CIR 2025/1572 sobre el formato y los procedimientos de notificación de la intención y la verificación en relación con el inicio de servicios de confianza cualificados,
CIR 2025/1929 relativa a la vinculación de la fecha y la hora a los datos y al establecimiento de la precisión de las fuentes de tiempo para la prestación de sellos de tiempo electrónicos cualificados,
CIR 2025/1942 sobre los servicios de validación cualificados para firmas electrónicas cualificadas y los servicios de validación cualificados para sellos electrónicos cualificados,
CIR 2025/1943 sobre normas de referencia para certificados cualificados de firma electrónica y certificados cualificados de sello electrónico,
CIR 2025/1944 sobre normas de referencia para los procesos de envío y recepción de datos en los servicios de envío certificado electrónico cualificado y en lo que respecta a la interoperabilidad de dichos servicios,
CIR 2025/1945 sobre la validación de firmas electrónicas cualificadas y de sellos electrónicos cualificados, así como sobre la validación de firmas electrónicas avanzadas basadas en certificados cualificados y de sellos electrónicos avanzados basados en certificados cualificados,
CIR 2025/1946 sobre los servicios de conservación cualificados para las firmas electrónicas cualificadas y para los sellos electrónicos cualificados,
CIR 2025/2160 sobre normas de referencia, especificaciones y procedimientos para la gestión de riesgos en la prestación de servicios de confianza no cualificados,
CIR 2025/2162 sobre la acreditación de Organismos de Evaluación de Conformidad que realizan la evaluación de los prestadores de servicios de confianza cualificados y de los servicios de confianza cualificados que prestan, el informe de evaluación de la conformidad y el sistema de evaluación de la conformidad,
CID 2025/2164 sobre la versión de la norma en la que se basa la plantilla común para las listas de confianza,
CIR 2025/2527 sobre normas de referencia para certificados cualificados para la autenticación de sitios web,
CIR 2025/2530 sobre los requisitos para los prestadores de servicios de confianza cualificados que prestan servicios de confianza cualificados,
CIR 2025/2531 sobre normas de referencia y especificaciones para los registros electrónicos cualificados,
CIR 2025/2532 sobre normas de referencia y especificaciones para los servicios de archivo electrónico cualificados.
CIR 2026/248 — Firmas y sellos electrónicos avanzados: formatos que deben reconocer los organismos del sector público
CIR 2026/798 — Incorporación a distancia de usuarios a las carteras europeas de identidad digital
Con el fin de apoyar el desarrollo de una implementación de referencia de una solución de Cartera y poner a prueba su uso en diferentes casos de uso prioritarios, la Comisión lanzó una convocatoria de propuestas el 22 de febrero de 2022 en el marco del Programa Europa Digital para poner a prueba casos de uso del ecosistema de Cartera IDUE a gran escala.
El objetivo de la convocatoria de Grandes-Proyectos-Piloto (GPP, Large Scale Pilots, LSP en inglés)) es apoyar la puesta en marcha del ecosistema de Cartera IDUE en torno a una serie de casos de uso en los que participen partes interesadas tanto del sector público como del privado. Los GPP pondrán a prueba el ecosistema de Cartera IDUE tanto en contextos nacionales como transfronterizos y se integrarán en el desarrollo iterativo de la aplicación de referencia.
Los trabajos de los LSP se alinean con el ARF, que guía el diseño del sistema piloto y el desarrollo de la arquitectura, junto con el lanzamiento de la implementación de referencia.
Los LSP han proporcionado comentarios sobre el ARF a medida que desarrollaban e interactuaban con los servicios de las Partes usuarias (o informadas), los prestadores de Declaraciones Electrónicas Cualificadas de Atributos (DECA) los prestadores de Datos de identificación de Persona (DIP), los prestadores de servicios de confianza cualificados y no cualificados y los usuarios en interacciones significativas en el marco de los casos de uso propuestos.
Un «rulebook» en el contexto de la EUDI Wallet (European Union Digital Identity Wallet) es un documento técnico de especificación que forma parte del «Architecture and Reference Framework» (ARF) o Arquitectura y Marco de Referencia, de la cartera de identidad digital europea. Los rulebooks definen los requisitos específicos para cada tipo de declaración de atributos o caso de uso dentro del ecosistema EUDI (regulado por eIDAS 2.0 y los Actos de Ejecución como el CIR 2024/2977 y 2024/2979).
No son documentos legales vinculantes en sí mismos (son «working documents» documentos de trabajo del eIDAS Expert Group), pero son obligatorios para lograr interoperabilidad, certificación y cumplimiento técnico entre Carteras, proveedores de PID (Person Identification Data», Datos de Identificación Personal) y Partes usuarias (Relying Parties) en toda la UE.
El PID Rulebook (o Annex 3.01 – PID Rulebook) es el específico para los Person Identification Data (PID): la declaración de atributos de identidad básica obligatoria emitida por un Estado miembro (o su PID Provider designado). Contiene requisitos adicionales a los del ARF general, que aplican a todos los casos de uso (incluyendo EAAs,(Electronic Attribute Attestation o Declaración Electrónica de Atributos, QEAAs, Qualified Electronic Attribute Attestation o Declaración Electrónica Cualificada de Atributos, etc.). Define cómo se estructura, codifica, emite y valida el PID para garantizar privacidad (selective disclosure, unlinkability), seguridad (firmas criptográficas) y portabilidad transfronteriza.
Detalles técnicos del PID Rulebook
El PID Rulebook especifica:
Namespaces y schema de atributos:
Namespace europeo principal: eu.europa.ec.eudi.pid.1 (para el tipo de documento y atributos comunes).
Domestic namespaces: Cada Estado miembro puede definir atributos nacionales adicionales (ej. eu.europa.ec.eudi.pid.es.1 para España). Se publican públicamente y se usan tanto en codificación ISO como SD-JWT.
Atributos obligatorios (M) y opcionales (O), basados en el Anexo del CIR 2024/2977 y codificados según CDDL (RFC 8610):
Código Alpha-2 (ISO 3166-1); multi-valor en domestic
O
array de tstr
Metadatos del PID (tratados como atributos técnicos): issuance_date (M), expiry_date (M), issuing_authority (M), document_number, issuing_country (ISO 3166-1, M), issuing_jurisdiction (ISO 3166-2, O), etc.
Formatos de codificación y presentación (PID_01 requiere soporte dual):
ISO/IEC 18013-5 (mdoc / CBOR): Para verificación offline/proximidad (tap NFC o QR). Usa CBOR (RFC 8949), MSO (Mobile Security Object) firmado por el PID Provider. Canonical CBOR obligatorio. Nacionalidad como array; portrait (foto) como JPEG puro (ISO/IEC 19794-5, sin headers).
SD-JWT VC (IETF RFC): Para online (OpenID4VP). JSON + selective disclosure (disclosure salts para privacidad). Soporta batch issuance y re-issuance para unlinkability.
Los datos deben ser válidos en el momento del validFrom del MSO o del VP Token. La firma siempre la hace el PID Provider (no el wallet). Los elementos domestic pueden firmarse opcionalmente por el wallet.
Trust infrastructure: PID Providers se listan en Trusted Issuer Lists (formato ETSI TS 119 612). Revocación vía status lists o embedded en el MSO/SD-JWT.
Otros requisitos: Soporte OpenID4VCI para emisión (incluyendo batch y re-issuance), Wallet Unit Attestation (WUA) previa, y activación del PID a LoA High (según Reglamento de Ejecución 2015/1502).
El rulebook asegura que el PID sea interoperable, minimice datos (data minimization) y cumpla privacy-by-design (zero-knowledge proofs para edad, etc.).
En el caso de España, aunque el número de DNI no forma parte de la lista de atributos obligatorios, se incluirá en todo caso, ya que es posible hacerlo en los opcionales (documet_number o personal_administrative_number) junto con otros datos correspondientes a la entidad emisora del DNI.
Reto principal para los países miembros al inicializar la cartera con el PID.
La inicialización (onboarding/provisioning) del PID es el paso crítico y más complejo. El wallet solo es plenamente operativo tras recibir un PID válido emitido por un «PID Provider» certificado del Estado miembro.
Retos técnicos y operativos:
Autenticación fuerte (LoA High): El usuario debe probar su identidad real frente al PID Provider (usando eID nacional, biometría, NFC, etc.). Esto requiere integración segura con fuentes auténticas nacionales.
Protocolos de emisión: Soporte completo de OpenID4VCI + activación del PID (verificación de que llegó al Wallet Secure Cryptographic Application – WSCA, normalmente en Secure Element del móvil o software certificado).
Certificación: Toda la solución (wallet + PID Provider) debe certificarse según CIR 2024/2981/CIR 2024/2982 (Common Criteria EAL4+ o equivalente). Incluye hardware/software del móvil, NFC reader mode y WSCA.
Privacidad y escalabilidad: Batch issuance para evitar linkability, soporte de selective disclosure, revocación eficiente y gestión de millones de usuarios sin fricción.
Interoperabilidad transfronteriza: El PID debe ser aceptable en toda la UE independientemente del formato (ISO o SD-JWT).
Infraestructura de confianza: Crear y mantener Trusted Issuer Lists, integrar con eIDAS nodes y garantizar que el wallet sea «certified EUDI Wallet Solution».
Experiencia de usuario vs. seguridad: Evitar fricción (muchos usuarios no tienen NFC o no quieren tapear el DNI físico) mientras se cumple el nivel High de assurance.
Muchos países usan lectura NFC del documento físico (DNIe, eID, pasaporte) como método principal de onboarding inicial, combinado con selfie + verificación biométrica y backend de autenticación.
Caso específico de España: Inicialización con NFC del móvil leyendo el DNIe
En España, el PID Provider se espera que sea la FNMT (Fábrica Nacional de Moneda y Timbre), que emitirá el PID vinculado al DNI (Documento Nacional de Identidad). La cartera nacional en desarrollo es la Cartera Digital (presentada en EUDI Wallet Launchpad 2025), que se prevé que se integrará con Cl@ve (que ya cuenta con más de 24 millones de usuarios) y aprovecha el DNIe 3.0/4.0 (con chip NFC obligatorio desde 2021).
Flujo técnico detallado de inicialización (onboarding con NFC):
El usuario descarga la app oficial de la Cartera Digital IDUE e inicia la configuración (crea PIN, asocia biometría captada con el móvil, obtiene la «Wallet Unit Attestation» – WUA).
Para solicitar el PID: la app activa el NFC reader mode del móvil (Android e iOS soportan lector de tarjetas ISO 14443 tipo A/B; el DNIe usa PACE/BAC para acceso seguro al chip).
El usuario acerca el DNIe físico al móvil. La app lee criptográficamente:
Datos del chip (MRZ, foto, datos personales, certificados de autenticación).
Verifica la integridad y autenticidad del chip (firmas, claves de lectura protegidas).
Autenticación del titular:
Comparación biométrica: mediante foto del usuario vs. foto conservada en el chip (usando verificación facial certificada según la norma ETSI TS 119 461).
Posible PIN del DNIe .
La app envía datos anonimizados o challenge-response al servidor de la FNMT para validación (en teoría relativa a la información del registro civil (fuente auténtica).
Una vez autenticado (LoA High), el PID Provider genera el PID:
En ambos formatos: mdoc (ISO 18013-5/CBOR) + SD-JWT VC.
Firma con clave del emisor (listada en Trusted Issuer List).
Emite vía OpenID4VCI (posiblemente batch para privacidad futura).
El wallet recibe, verifica y activa el PID (WSCA lo almacena de forma segura). El usuario puede ahora usarlo para identificación online/offline en toda la UE.
Retos específicos en España:
Compatibilidad NFC: El DNIe 4.0 está optimizado, pero requiere que la app gestione correctamente protocolos PACE (Password Authenticated Connection Establishment) y que el móvil tenga interfaz NFC (casi todos los actuales lo tienen). iOS restringe algo más el acceso NFC a apps de terceros, por lo que la app oficial debe estar pre-aprobada por Apple.
Integración con Cl@ve: La identificación y autenticación en Cl@ve con la Cartera dará lugar seguramente a un nuevo icono de autenticación en la página web de Cl@ve que posiblemente desencadene la apertura de una página con código QR que lea la Cartera y desencadene la autenticación.
Certificación y escalabilidad: La solución completa (app + obtención del PID) debe superar la auditoría establecida por la norma de certificación de carteras de ENISA, posiblemente mediante el esquema Lince del CCN.
El «Rulebook» del PID marca la primera implementación de una «Declaración Electrónica de Atributos» (contando con que cada tipo de «Declaración Electrónica de Aributos» tiene su propio «Rulebook»). Los «rulebooks» son las reglas de juego de tipo técnico para el PID y para las DEA e indican los tipos de datos necesarios para cada caso de uso..
En España, el uso del interfaz NFC del DNIe posiblemente sea el método más directo y seguro para la inicialización de los datos de identidad de la Cartera, con el aliciente de aprovechar la infraestructura ya existente y convirtiendo el móvil en lector de DNIe criptográficamente seguro. Esto minimizaría la fricción y maximizaría la adopción.
En todo caso, se requiere que la app esté certificada en cuanto a los requisitos de seguridad.
Todo es electrónico 