ETSI publicó en julio de 2026 el informe técnico de su primer Plugtests sobre declaraciones electrónicas de atributos, celebrado en remoto entre el 4 de mayo y el 30 de junio de 2026. Por primera vez, fabricantes, prestadores de servicios de confianza y laboratorios han puesto a prueba, unos contra otros, las declaraciones generadas conforme a la especificación ETSI TS 119 472-1 V1.2.1.
Las declaraciones electrónicas de atributos son una de las piezas centrales de la Cartera de Identidad Digital Europea (EUDI Wallet). Son las que permiten que la cartera vaya más allá de la identificación y se convierta en un contenedor portátil de credenciales verificables: títulos académicos, permisos de conducir, apoderamientos o certificados profesionales. Que funcionen igual con independencia de quién las emita es condición imprescindible para que el ecosistema funcione.
Cómo se organizó
El Plugtests lo organizó el Centro de Pruebas e Interoperabilidad de ETSI (CTI) a través de un portal accesible 24 horas, sin pruebas en tiempo real. Estaba previsto hasta el 1 de junio, pero se amplió hasta el 30 de junio a petición de los participantes, por el elevado número de pruebas. La participación fue gratuita e InfoCert facilitó certificados cualificados de prueba para firmar las declaraciones.
Se probaron los dos perfiles de la ETSI TS 119 472-1, en sus tres variantes: declaraciones no cualificadas, declaraciones cualificadas y declaraciones expedidas por o en nombre de un organismo del sector público responsable de una fuente auténtica.
- SD-JWT VC (formato JSON, cláusula 5 de la especificación).
- ISO/IEC mdoc (formato CBOR basado en ISO/IEC 18013-5, cláusula 6), tanto para permisos de conducir móviles (mDL) como para otras declaraciones.
Hubo tres tipos de prueba:
- Generación y verificación cruzada. Cada participante generaba declaraciones válidas según 54 casos de prueba y el resto las verificaba. El portal actualizaba automáticamente las matrices de interoperabilidad.
- Pruebas negativas. ETSI preparó 24 declaraciones SD-JWT VC deliberadamente defectuosas, que las herramientas de los participantes debían rechazar.
- Conformidad. Un verificador de conformidad en línea, todavía en versión beta, comprobaba la estructura de cada declaración frente a la especificación.
Por los acuerdos de confidencialidad, el informe no publica resultados por caso de prueba ni por empresa: solo estadísticas globales y anónimas.
Participantes
Se inscribieron 116 organizaciones de 41 países y 215 personas: 207 participantes, 4 miembros del personal de ETSI y 4 expertos. Alemania (14) y España (13) fueron los países con más organizaciones, seguidos de Francia (10) y los Países Bajos (9).
La presencia española fue muy notable e incluyó al Ministerio para la Transformación Digital y de la Función Pública, prestadores de servicios de confianza, empresas tecnológicas y la UPC. También participaron organizaciones latinoamericanas: GSE (Colombia), Certisign y e-Sec (Brasil) y la Subsecretaría de Economía de Chile.
| País | Organizaciones | N.º |
|---|---|---|
| Alemania | AUTHADA GmbH; Bundesamt für Sicherheit in der Informationstechnik (BSI); Deutsche Telekom AG; DiaLOGIKa; ecsec GmbH; Governikus GmbH & Co. KG; IDunion SCE; Independiente (experto); Lissi Gmbh; procilon GmbH; SIGN8 GmbH; Space Acceleration Industries; SPRIND GmbH; Technical University of Munich (TUM) | 14 |
| España | Bull; Centro Tecnológico del Notariado; Desteba Productions, S.L.; Digitel on Trusted Services, S.L.U; Entrust EU; ISTEC; Izertis; Lleida.net; Ministerio para la Transformación Digital y de la Función Pública; Mobbeel Solutions, S.L.; Servicios de MailCertificado – Codicert; UPC; Validated ID, SL | 13 |
| Francia | Atos Eviden; Cabinet Louis Reynaud; DOCAPOSTE CSP; Erick Virapatrin Consulting; iDAKTO; KEREVAL; MINISTERE DE L’INTERIEUR; NEOWAVE; TOPPAN Security; Verifiables | 10 |
| Países Bajos | Cleverbase; Credenco B.V.; Datakeeper; Digidentity B.V.; Forkbomb B.V.; iLabs Technologies B.V.C; Secumail B.V.; Truvity; Ver.iD | 9 |
| Eslovaquia | Ardaco, a.s.; Disig a.s.; DITEC, a.s.; National Agency for Network and Electronic Services (NASES); National Security Authority; Plaut Slovensko s.r.o.; Triveria | 7 |
| Italia | ARIA S.p.A.; Aruba PEC S.p.A.; InfoCert; INTESI GROUP S.p.A.; Namirial | 5 |
| Austria | A-SIT Plus; GrEEV; walt.id | 3 |
| Chequia | Bankovni identita, a.s.; CZ.NIC; NEWPS.CZ s.r.o. | 3 |
| Hungría | IdomSoft; Microsec Ltd; POLYSYS Ltd | 3 |
| Reino Unido | Allied Bits Ltd.; British Standards Institution (BSI); Entrust | 3 |
| Serbia | Chamber of Commerce and Industry of Serbia; E-Smart Systems; Post of Serbia | 3 |
| Suecia | Comfact AB; Iris Development-PassportReader; LCubed AB (iGrant.io) | 3 |
| Albania | First shpk; National Agency for Information Society (NAIS) | 2 |
| Brasil | Certisign; e-Sec Digital Security | 2 |
| Bulgaria | Evrotrust Technologies AD; Trustvestor Ltd. | 2 |
| Bélgica | BOSA; Msg systems ag | 2 |
| Finlandia | Digi- ja väestötietovirasto (DVV), Digital and Population Data Services Agency; Hovi ID | 2 |
| Grecia | Greek Universities Network (GUnet); Ministry of Digital Governance | 2 |
| Japón | NTT Data; Otip Office | 2 |
| Polonia | Asseco Data Systems; Authologic Sp. z o.o. | 2 |
| Rumanía | AlfaTrust Certification; certSIGN | 2 |
| Túnez | Higher School of Communications, University of Carthage (Sup’Com); OneTech B.S. (OTBS) | 2 |
| Ucrania | EGA; State Enterprise «DIIA» | 2 |
| Australia | SITA | 1 |
| Chile | Subsecretaría de Economía | 1 |
| Colombia | Gestión de Seguridad Electrónica (GSE) | 1 |
| Dinamarca | dewa ApS | 1 |
| Eslovenia | Netis d.o.o. | 1 |
| Estonia | SK ID Solutions AS | 1 |
| Irlanda | Adobe Systems Software Ireland Limited | 1 |
| Kenia | Mobile Solution Network ltf | 1 |
| Letonia | EUSO | 1 |
| Lituania | MIT-SOFT, UAB | 1 |
| Luxemburgo | Nowina Solutions | 1 |
| Macedonia del Norte | Nextsense | 1 |
| Moldavia | e-Governance Agency of Moldova | 1 |
| Pakistán | Ascertia | 1 |
| Portugal | DEVISE FUTURES – IT SOLUTIONS, LDA | 1 |
| Suiza | Procivis AG | 1 |
| Taiwán | Chunghwa Telecom Laboratories (CHTTL) | 1 |
| Turquía | Duru Bilişim | 1 |
Fuente: lista de participantes del informe (cláusula 4). Denominaciones tal como figuran en él, salvo el nombre del ministerio español, traducido.
Resultados en cifras
Los participantes generaron 959 declaraciones y emitieron 11.172 informes de verificación: de media, cada declaración fue verificada por unas 12 herramientas distintas. El formato SD-JWT VC concentró casi dos tercios de la actividad.
| Formato | Declaraciones generadas | Verificaciones | Subidas al verificador de conformidad |
|---|---|---|---|
| SD-JWT VC | 597 | 7.842 | 698 |
| ISO mDL (permiso de conducir móvil) | 96 | 887 | 330 (mDL y mdoc) |
| ISO mdoc (otras declaraciones) | 266 | 2.443 | |
| Total | 959 | 11.172 | 1.028 |
El informe no publica los porcentajes de éxito: los acuerdos de confidencialidad limitan la difusión a estas cifras globales.
Principales conclusiones
La conclusión de fondo es que la especificación funciona, pero todavía no encaja del todo con el resto del ecosistema normativo. El informe recoge 17 cuestiones sobre las especificaciones, que ETSI trasladará a su comité técnico ESI para las próximas versiones. Las agrupo en cinco bloques.
1. Desajustes con otras normas y con el ARF
- Datos de identificación personal (PID). La TS 119 472-1 exige que toda declaración mdoc que no sea un mDL use el espacio de nombres org.iso.23220.1. El PID Rulebook del ARF impone eu.europa.ec.eudi.pid.1 con su propio catálogo, de modo que un PID conforme al ARF no cumple la especificación de ETSI.
- Firmas CB-AdES y mdoc. ISO/IEC 18013-5 sitúa el elemento x5chain en la cabecera no protegida, mientras que la ETSI TS 119 152-1 lo exige dentro de uHeaders. El resultado es que ninguna firma mdoc puede ser conforme con CB-AdES.
- Reglamento de Ejecución (UE) 2026/248. Sus requisitos sobre el identificador del emisor y la cabecera x5c en firmas JAdES cualificadas chocan con los de la especificación, lo que impediría generar declaraciones cualificadas conformes con ambos textos.
2. Certificados de firma de las declaraciones
- Exigir el uso de clave digitalSignature contrasta con los perfiles de certificados de ETSI EN 319 412-2 y -3. Se plantea definir un perfil específico para los certificados con que se firman las declaraciones electrónicas de atributos.
- El Reglamento eIDAS (anexos IV y VII) exige indicar «la ubicación en la que está disponible gratuitamente» el certificado de firma. La especificación lo resuelve con las cabeceras x5u y x5t#S256, que fijan SHA-256. Los participantes pidieron admitir otros algoritmos (por ejemplo, x5t#o de JAdES) para no atar el formato a una función resumen concreta. Se propone elevar la consulta a la Comisión.
3. Estado y validez de las declaraciones
- El servicio de estado se especifica de forma distinta en SD-JWT VC y en mdoc. Además, el RFC 9901 remite a la versión 13 del borrador de Token Status List, cuando la vigente es la 21.
- No queda claro por qué las declaraciones de un solo uso (oneTime) deben llevar servicio de estado, si por definición no se conservan.
- Los campos adm_nbf y adm_exp se atribuyen a normas del IETF que no los definen.
- Se confirma que un sello de tiempo firmado con un certificado de TSU caducado sigue siendo válido mientras el servicio figure en la lista de confianza. Se aclarará en EN 319 102-1, TS 119 615 y TS 119 172-4.
4. Detalles de codificación que rompen la interoperabilidad
- Muchas declaraciones codificaron el resumen de vct#integrity en base64url, cuando debe ir en base64.
- Los parámetros del certificado del titular (x5c, x5t#S256, x5u) deben ir dentro de un miembro jwk anidado en cnf, no directamente en cnf.
- Hay que aclarar si una SD-JWT VC compacta debe ser una firma JAdES completa o basta un JWS simple, y cómo se relaciona el parámetro iat de la cabecera con el claim iat.
- Un mDL no debería admitir seudónimo, porque ISO 18013-5 exige nombre, apellidos y número de documento. Los nuevos claims deberían indicar si admiten divulgación selectiva.
5. El verificador de conformidad
La herramienta de ETSI, en beta, recibió 1.028 declaraciones. Los participantes notificaron 9 incidencias: 7 se resolvieron durante el evento y 2 quedaron pendientes (el tipo de fecha de expiry_date y la detección de vct y vct#integrity). Todavía no comprueba el perfil mdoc de la cláusula 6 ni las presentaciones de la TS 119 472-2.
En lo organizativo, ETSI concluye que el formato remoto era la única opción viable para un ejercicio de este tamaño, y destaca el papel de Discord como canal técnico y de actas.
Valoración
Este primer Plugtests demuestra que el ecosistema de declaraciones electrónicas de atributos tiene masa crítica: 116 organizaciones y más de 11.000 verificaciones cruzadas en dos meses. También muestra que la interoperabilidad no depende solo de cumplir una norma, sino de que todas las normas implicadas (ETSI, ISO, IETF, el ARF y los actos de ejecución) digan lo mismo.
Destacan tres mensajes para quienes vayan a emitir o verificar declaraciones electrónicas de atributos:
- Alinear la TS 119 472-1 con el ARF y los actos de ejecución es urgente, sobre todo en el PID y en las declaraciones cualificadas, antes de que las carteras lleguen a los ciudadanos.
- La criptoagilidad tiene que estar en el diseño. Fijar SHA-256 en la referencia al certificado de firma es una decisión que habrá que revisar, y es mejor hacerlo ahora que con millones de declaraciones emitidas. La criptografía tiene que ser ya postcuántica.
- Los detalles de codificación importan. Errores como base64 frente a base64url bastan para que una declaración válida sea rechazada por otro verificador.
La fuerte participación española, que incluye al propio Ministerio para la Transformación Digital y de la Función Pública, es una buena noticia de cara al despliegue de la Cartera de Identidad Digital Europea en España.
Fuente: ETSI CTI, Technical Report of the EAA Remote Plugtests™ Event (May-June 2026), versión 1.0, 1 de julio de 2026.
