Archivo de la categoría: Estandarización

Resumen del Plugtests de ETSI 2026 de declaraciones electrónicas de atributos


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:

  1. 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.
  2. Pruebas negativas. ETSI preparó 24 declaraciones SD-JWT VC deliberadamente defectuosas, que las herramientas de los participantes debían rechazar.
  3. 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ísOrganizacionesN.º
AlemaniaAUTHADA 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ñaBull; 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, SL13
FranciaAtos Eviden; Cabinet Louis Reynaud; DOCAPOSTE CSP; Erick Virapatrin Consulting; iDAKTO; KEREVAL; MINISTERE DE L’INTERIEUR; NEOWAVE; TOPPAN Security; Verifiables10
Países BajosCleverbase; Credenco B.V.; Datakeeper; Digidentity B.V.; Forkbomb B.V.; iLabs Technologies B.V.C; Secumail B.V.; Truvity; Ver.iD9
EslovaquiaArdaco, a.s.; Disig a.s.; DITEC, a.s.; National Agency for Network and Electronic Services (NASES); National Security Authority; Plaut Slovensko s.r.o.; Triveria7
ItaliaARIA S.p.A.; Aruba PEC S.p.A.; InfoCert; INTESI GROUP S.p.A.; Namirial5
AustriaA-SIT Plus; GrEEV; walt.id3
ChequiaBankovni identita, a.s.; CZ.NIC; NEWPS.CZ s.r.o.3
HungríaIdomSoft; Microsec Ltd; POLYSYS Ltd3
Reino UnidoAllied Bits Ltd.; British Standards Institution (BSI); Entrust3
SerbiaChamber of Commerce and Industry of Serbia; E-Smart Systems; Post of Serbia3
SueciaComfact AB; Iris Development-PassportReader; LCubed AB (iGrant.io)3
AlbaniaFirst shpk; National Agency for Information Society (NAIS)2
BrasilCertisign; e-Sec Digital Security2
BulgariaEvrotrust Technologies AD; Trustvestor Ltd.2
BélgicaBOSA; Msg systems ag2
FinlandiaDigi- ja väestötietovirasto (DVV), Digital and Population Data Services Agency; Hovi ID2
GreciaGreek Universities Network (GUnet); Ministry of Digital Governance2
JapónNTT Data; Otip Office2
PoloniaAsseco Data Systems; Authologic Sp. z o.o.2
RumaníaAlfaTrust Certification; certSIGN2
TúnezHigher School of Communications, University of Carthage (Sup’Com); OneTech B.S. (OTBS)2
UcraniaEGA; State Enterprise «DIIA»2
AustraliaSITA1
ChileSubsecretaría de Economía1
ColombiaGestión de Seguridad Electrónica (GSE)1
Dinamarcadewa ApS1
EsloveniaNetis d.o.o.1
EstoniaSK ID Solutions AS1
IrlandaAdobe Systems Software Ireland Limited1
KeniaMobile Solution Network ltf1
LetoniaEUSO1
LituaniaMIT-SOFT, UAB1
LuxemburgoNowina Solutions1
Macedonia del NorteNextsense1
Moldaviae-Governance Agency of Moldova1
PakistánAscertia1
PortugalDEVISE FUTURES – IT SOLUTIONS, LDA1
SuizaProcivis AG1
TaiwánChunghwa Telecom Laboratories (CHTTL)1
TurquíaDuru Bilişim1

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.

FormatoDeclaraciones generadasVerificacionesSubidas al verificador de conformidad
SD-JWT VC5977.842698
ISO mDL (permiso de conducir móvil)96887330 (mDL y mdoc)
ISO mdoc (otras declaraciones)2662.443
Total95911.1721.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:

  1. 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.
  2. 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.
  3. 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.

From qualified preservation of electronic signatures and seals to qualified chronological-order archiving services (qDLT)


On 14 September 2026 I took part, in Tallinn (Estonia), in the ETSI ESI Certification Authority (CA) Open Session. I went as an attendee, but by the end of the afternoon I ended up on the panel as a speaker.

The slot had been planned for Steffen Schwalm, who in the end could not attend, and I was asked to step in to talk about how the standardisation of distributed ledger technologies (DLT) is evolving and, in particular, about what we are beginning to call qDLT: the qualified distributed ledger.

I was glad to accept, although (given the short time available to think about what to say) I told my own ideas, not those of the announced speaker.

And in this summary I set out those ideas about what is happening in the standardisation of DLTs: not so much a technological revolution arriving from outside to reinvent digital trust, but a very coherent evolution of something we have been building in Europe for almost a decade. The line of reasoning runs from the preservation of qualified signatures and seals to the ordering of archived files with respect to the moment their custody was requested from the Trust Service Provider. This is how I see it.

The starting point: preserving qualified electronic signatures and seals

The first piece is the one that has been standardised longest, and the one we sometimes forget to mention when we talk about blockchain as if it were virgin territory. Under the umbrella of the first eIDAS, ETSI developed the standard TS 119 511 (the one we usually cite simply as «511») which sets the policy and security requirements for providers offering long-term preservation of electronic signatures (or of data in general) using digital-signature techniques. Its companion, TS 119 512, defines the protocols for interoperating with those preservation services. This first variant (the qualified preservation of qualified electronic signatures and qualified electronic seals) already has its own implementing act: Commission Implementing Regulation (EU) 2025/1946, adopted on the basis of Articles 34(2) and 40 of the eIDAS Regulation. It is worth noting that these are original eIDAS articles, plain numbers, with none of the letter suffixes (Article 45a, 45b, 45c…) that English-language EU legislation uses to mark the provisions eIDAS2 kept inserting; its annex points to ETSI TS 119 511 (together with TS 119 172-4) as the reference standard.

The problem 511 solves is subtle but enormous: an electronic signature is valid today because the certificate backing it is still in force, because the cryptographic algorithms used are considered robust, and because there is an infrastructure that confirms it. But time erodes all of that. Certificates expire, authorities change, and (increasingly relevant ) algorithms age. A qualified preservation service keeps the evidence alive: it periodically reasserts integrity and validity through new time stamps or preservation techniques (such as chained hashes) and new layers of cryptographic protection, so that twenty years from now one can still prove that the document was signed and has not been altered.

This is worth pausing on, because it is exactly the ground where crypto-agility and post-quantum cryptography stop being an academic debate. Preserving for the long term means, by definition, surviving the moment when today’s algorithms cease to be trustworthy. A good preservation service is, at heart, a machine designed to migrate algorithms without losing the evidentiary thread. Whoever understands 511 already understands half of why the rest of this story matters.

The second step: qualified electronic archiving

The second eIDAS (Regulation (EU) 2024/1183) threw nothing away. It broadened. Among the new qualified trust services appears qualified electronic archiving, abbreviated in English jargon as q-earchiving, which in the European standardisation work relies on the technical specification CEN/TS 18170. Its implementing act is Commission Implementing Regulation (EU) 2025/2532, of 16 December 2025, adopted on the basis of Article 45j(2) of the Regulation (the provision eIDAS2 added for qualified electronic archiving) whose annex points precisely to CEN/TS 18170:2025 as the reference standard.

The difference with signature preservation is one of scope. 511 focuses on maintaining the validity of the cryptographic evidence of a signed document. Qualified archiving goes a step further and deals with the document as an object that must be kept intact, legible and available over time, whether signed or not, including the guarantee of its integrity, the traceability of access, and retention policies. It is the regulatory translation of a very old need — the archive — into the language of qualified trust services. For the first time, a provider can offer archiving with the same level of legal assurance already enjoyed by the signature, the seal or the time stamp.

And it is worth clearing up a common misunderstanding: archiving does not replace signature preservation, it relies on it. 511 remains the piece that guarantees the survival of the signature evidence, so a qualified electronic archiving provider can use the services of a preservation provider for that part, turning to a 511 service to keep alive the signatures and seals of the documents it holds. These are not competing services but complementary ones: archiving orchestrates the custody of the file and delegates to preservation the long-term care of the cryptographic evidence. It is exactly the layered logic that runs through this whole article.

There is also a second function of archiving worth highlighting, because it often goes unnoticed: format conversion. Keeping a document for decades is not only about its bits not changing; it is about it remaining legible. And formats age too. A file format that is universal today may become obsolete and fall out of use in favour of others, and when that happens the archiving service must be able to convert the document to the new format while preserving its content, its faithful rendering and its evidentiary value. It is, in the realm of formats, the exact parallel of what preservation does in the realm of algorithms: just as a 511 service migrates cryptographic algorithms before they cease to be trustworthy, an archiving service migrates formats before they cease to be openable. Future legibility of the data and future robustness of the cryptography are two sides of the same promise: that twenty years from now the document will not only exist, but can be opened and proven.

If preservation protects the signature, archiving protects the file. And the next step is to ask what happens when what we need to protect is not an isolated document, but the relationship among many facts over time.

The third step: temporal ordering

Here comes the most interesting novelty of the second eIDAS: electronic ledgers as a new qualified trust service. The reference specification is CEN/TS 18264, published in 2025.

And its implementing act, from the same December 2025 batch, is Commission Implementing Regulation (EU) 2025/2531, adopted on the basis of Article 45l(3) of the Regulation (the provision eIDAS2 devoted to qualified electronic ledgers).

I prefer to explain it with a simple idea: an electronic ledger is a chronologically ordered archive. It does not merely store data entries; it guarantees their temporal sequence in such a way that none can be inserted, deleted or reordered without it showing. It is, if you like, time-stamping raised to the level of a structure: we do not mark a single document with a date, but build a chain of events whose ordering is itself the proof.

And once we accept that what adds value is the guaranteed chronological ordering, the technical question that gives the session its name arises: how is that order built? And there are two legitimate answers.

The first is to use a centralised infrastructure: a single qualified provider maintains the ledger, seals it and is accountable for its integrity. It is simple to audit and fits perfectly into the qualified-provider model we already know.

The second is to use an infrastructure of interconnected nodes that replicate the information (sometimes called a distributed infrastructure): the chronological order is built through the connection of nodes that agree among themselves (through governance rules) on the sequence of entries. This is where distributed ledger technology (DLT) comes into play — not as a fashion, but as a concrete way of achieving that ordering without depending on a single point. When that distributed ledger is provided with the guarantees of a qualified trust service, we speak of qDLT: a qualified distributed ledger.

Allow me a terminological note here that I have been making for some time. The Regulation has enshrined the term DLT (Distributed Ledger Technology), and I stick to it for regulatory rigour. But, if we were to name the idea precisely, I would rather speak of RJT (Replicated Journal Technology). The reason is accounting: in double-entry bookkeeping, the chronological order of events is not kept in the ledger (the general ledger, which groups entries by account) but in the journal (the day book, which records them one after another as they happen). And since what we are preserving here is precisely the temporal sequence, the fitting name for this technology should point to the replicated journal rather than to the distributed ledger. It is, most likely, a terminological battle already lost against the official text, but no less accurate for that.

A good European example of this approach is EBSI, the European Blockchain Services Infrastructure, today governed through the figure of the Europeum-EDIC (a European digital-infrastructure consortium). EBSI shows that the distributed model is not incompatible with qualified trust: the nodes can be operated by identified administrations and providers, with governmental trust anchors, so that the result combines the resilience of distribution with the legal accountability that the eIDAS framework demands.

And it is worth noting a detail of Commission Implementing Regulation (EU) 2025/2531, because it captures this duality precisely. The implementing act requires all providers of qualified electronic ledgers to comply with the standard ETSI EN 319 401 (general policy requirements for trust service providers) and adds specific requirements for the distributed variant: when the ledger is built through nodes, the provider must also comply with ISO 23257:2022 (reference architecture for distributed ledger technologies) and ISO/TS 23635:2022 (governance guidelines). In other words, it is the implementing act itself that recognises the two variants and reserves the DLT consensus and governance standards for the distributed case, which is when we speak, properly, of qDLT. Regulation, once again, does not impose a technology: it describes guarantees and leaves the way of achieving them open.

It is worth underlining the regulatory continuity: from preservation (511) we move to qualified archiving (18170), and from there to chronological ledger, or qDLT (18264). These are not three worlds but three layers of a single idea that keeps gaining ambition: first, keeping an electronic signature fully effective; then, holding a document (signed or not) while guaranteeing its future recovery; and finally, ordering and relating the facts in a verifiable way, when that order can produce legal effects.

What a chronological ledger makes possible

The part I find most interesting (and to which I devoted much of my intervention) is not the ledger technology itself, but the functionalities it enables when we register not only the document but also its context: who its owner is, what rights it embodies and how it evolves. A well-designed chronological ledger opens the door to three capabilities that until now were hard to bring into the digital world with full guarantees.

The first is transferability (or endorsability). If the ledger records not only that a document exists, but also who its holder is, then it can equally record the transfer of that ownership. This is what allows an electronic file to be treated as an asset that changes hands: think of commercial paper, of documents of title to goods, or of any right that was traditionally «endorsed» on paper. The chronological ledger turns the chain of endorsements into a verifiable sequence of entries.

The second is obliterability (or cancellability). A right is not only transferred: it is also consumed. If a file represents a cinema ticket or admission to a show, we need to be able to mark that the right has already been exercised, so that it cannot be used twice. The ledger does not delete the entry (the evidence remains) but records indelibly its change of state: issued, transferred, consumed. It is the difference between crossing out and throwing away: the fact that a right has been exhausted is, in itself, a fact worth recording. The postmark is a good example.

The third is completeness, which I like to describe as an electronic staple. A document rarely travels alone. A contract carries annexes; a deed carries endorsements; an agreement evolves through successive versions. Think of contractual novations, in which the parties agree to modify the clauses: what matters legally is not only the latest text, but the complete relationship between the original document, its annexes and each of its evolutions. Completeness consists of keeping the document and everything that accompanies it (notes, annexes and their own versions) verifiably bound together, so that the whole is preserved as an indivisible and traceable unit. The staple does not just hold papers together: it records the order in which they were joined.

These three functionalities share one trait: they are only possible if the ledger stores more than the document. It stores its ownership, its state and its relationships. And they are only trustworthy if that information is ordered in time in a way that cannot be tampered with. That is why the qualified chronological ledger is not a technical whim, but the substrate on which one can build services that until now were tied to paper or to closed trusted intermediaries.

A database with legal ancestry: book-entry securities and EADTrust’s Cartulario

For these three functionalities to be more than a promise, one needs to manage a database associated with the service, with very specific properties: it must record, for each archived object, who its holder is, in what state the embodied right stands (and where or against whom that right is exercised) and how it relates to other documents; and it must do so in such a way that every change is recorded in sequence and is enforceable against third parties. Anyone familiar with securities law will recognise the pattern at once, because it is exactly the one governing the representation of securities through book entries («anotaciones en cuenta» in spanish): an accounting register in which ownership, transfers, encumbrances and the extinction of rights are not documented on a physical certificate but are constituted and proven by their inscription. Transferability is, in that language, the transfer of the entry; obliterability, its cancellation; completeness, the link between the principal entry and its ancillary ones. It is no coincidence: the qualified chronological ledger and the book-entry register solve the same problem (giving certainty about the ownership and state of a right over time) with the same tool: a reliable, ordered database.

At EADTrust we have been working on this idea for a long time. Our Cartulario service was designed many years ago on precisely those premises: treating the archive not as a mere repository of files, but as a register that records ownership, state and relationships, with an eye on functionalities such as endorsability, cancellability and completeness long before the European regulatory framework captured them explicitly.

And since we are on the subject of the name: Cartulario is simply the Spanish word for a cartulary (also spelled chartulary) — in the Middle Ages, the codex in which monasteries and cathedral chapters copied and safeguarded their charters, privileges and donations so they would not be lost (it is, roughly, the great-grandfather of the notarial protocol). So, all things considered, at EADTrust we have been in this business of chronological-order archiving for several centuries before the PDF was invented; the only difference is that we have swapped the vellum for a digital server and the copyist monk for a millisecond-precision time stamp.

And to that foundation Cartulario now adds a refinement that goes straight to the heart of what we were discussing in Tallinn: millisecond-precision (1 ms) time stamps associated with every archiving request. When the proof is the ordering, temporal resolution matters: having a millisecond-precision mark on each operation makes it possible to guarantee the chronological order of entries with far greater fineness, and to resolve the sequence unambiguously even when several requests pile up within a very short interval. It is, in practice, the materialisation of that idea of a «chronologically ordered archive» from which this whole line of reasoning starts.

Why this fits with the rest of the ecosystem

I do not want to close the article without connecting this story to the broader conversation about European digital identity. The ecosystem of the European wallet (EUDI Wallet) and of electronic attestations of attributes needs solid trust anchors: places where one can verifiably record who said what, about whom and when. A qualified chronological ledger (centralised or in the form of qDLT) is precisely one of those anchors. It can join the world of identity with the legal accountability of the eIDAS framework.

And all of this still rests on the first stone I mentioned at the beginning: the ability to preserve evidence over the long term and to migrate algorithms when needed. The arrival of post-quantum cryptography does not invalidate this architecture; on the contrary, it makes it more necessary. A ledger that orders documents in time must be, by design, a ledger capable of surviving the passage of time, including the time when today’s algorithms cease to protect us or the document-encoding formats are replaced by others.

That was, in essence, my thesis in Tallinn: that DLT and qDLT do not appear out of nowhere, but are the next natural rung on a ladder that began by preserving signatures, went on to archive documents, and is now learning to order facts. Seeing it this way helps a great deal not to get lost: each new standard does not replace the previous one, it adds a layer of ambition to it.

And here is my presentation summarising this article:

Try Cartulario

If you would like to experiment with these ideas on a real service, at EADTrust we make Cartulario available to anyone who wishes to try it. Its current nature is worth stating with full transparency: today it is offered as a non-qualified trust service and is pending audit to be considered a qualified service within the eIDAS framework. This distinction is no minor nuance (it is, precisely, the line that separates a trust service from a qualified trust service), and we prefer to make it clear from the outset.

Anyone who wishes to learn about it, propose a pilot project or discuss use cases (endorsability, cancellability, completeness or millisecond-precision time-stamping) can write to us at info@eadtrust.com or call us at +34 902 365 612 / +34 91 716 05 55. More information at www.eadtrust.eu.

De la conservación cualificada de firmas y sellos a los servicios cualificados de archivo con orden cronológico (qDLT)


El pasado 14 de septiembre de 2026 participé en Tallin (Estonia) en el evento ETSI ESI Certification Authority (CA) Open Session. Al principio como asistente, pero al final de la tarde participé como panelista.

La intervención estaba prevista para Steffen Schwalm, que finalmente no pudo asistir, y me pidieron que me incorporara para hablar de cómo evoluciona la estandarización de las tecnologías de registro distribuido (DLT) y, en particular, de lo que empezamos a llamar qDLT: el registro distribuido cualificado.

Acepté encantado, aunque conté mis ideas, no las del ponente anunciado, tras el corto plazo disponible para reflexionar sobre qué contar.

Y en este resumen recojo esas ideas sobre lo que está ocurriendo en la normalización de DLTs, no tanto como una revolución tecnológica que llega de fuera para reinventar la confianza digital, sino una evolución muy coherente de algo que llevamos casi una década construyendo en Europa. La cadena de razonamiento va desde la conservación de firmas y sellos cualificados a la ordenación de archivos respecto al momento en el que se pidió su custodia al Prestador de Servicios de Confianza. Así es como lo veo:

El punto de partida: conservar firmas y sellos cualificados

La primera pieza es la que lleva más tiempo normalizada y la que a veces olvidamos citar cuando hablamos de blockchain como si fuera terreno virgen. Bajo el paraguas del primer eIDAS, ETSI desarrolló la norma TS 119 511 (la que solemos citar simplemente como «511»), que fija los requisitos de política y de seguridad para los prestadores que ofrecen conservación a largo plazo de firmas electrónicas (o de datos en general) mediante técnicas de firma digital. Su compañera, la TS 119 512, define los protocolos para interoperar con esos servicios de conservación. Esta primera variante —la conservación cualificada de firmas electrónicas cualificadas y de sellos electrónicos cualificados— cuenta ya con su propio acto de ejecución: el Reglamento de Ejecución (UE) 2025/1946, dictado al amparo de los artículos 34, apartado 2, y 40 del Reglamento EIDAS. Conviene reparar en que estos son artículos originales de eIDAS y, por tanto, no llevan la numeración latina bis, ter, quater… propia de los preceptos que eIDAS2 fue insertando; su anexo remite a la ETSI TS 119 511 (con la TS 119 172-4) como norma de referencia.

El problema que resuelve la 511 es sutil pero enorme: una firma electrónica es válida hoy porque el certificado que la respalda está vigente, porque los algoritmos criptográficos empleados se consideran robustos y porque existe una infraestructura que lo confirma. Pero el tiempo erosiona todo eso. Los certificados caducan, las autoridades cambian, y (esto es cada vez más relevante) los algoritmos envejecen. Un servicio de conservación cualificado mantiene viva la evidencia: reafirma periódicamente la integridad y la validez mediante nuevos sellos de tiempo o técnicas de preservación (como hashes encadenados) y nuevas capas de protección criptográfica, de modo que dentro de veinte años se pueda seguir demostrando que aquel documento estaba firmado y que no ha sido alterado.

Aquí conviene detenerse, porque este es exactamente el terreno donde la criptoagilidad y la criptografía postcuántica dejan de ser un debate académico. Conservar a largo plazo significa, por definición, sobrevivir al momento en que los algoritmos actuales dejen de ser fiables. Un buen servicio de conservación es, en el fondo, una máquina diseñada para migrar de algoritmos sin perder el hilo probatorio. Quien entienda la 511 entiende ya la mitad de por qué el resto de esta historia importa.

El segundo paso: el archivado electrónico cualificado

El segundo eIDAS (el Reglamento (UE) 2024/1183) no tiró nada de lo anterior. Lo amplió. Entre los nuevos servicios cualificados de confianza aparece el archivado electrónico cualificado, lo que en la jerga anglosajona se abrevia como q-earchiving y que en el desarrollo normativo europeo se apoya en la especificación técnica CEN/TS 18170. Su acto de ejecución es el Reglamento de Ejecución (UE) 2025/2532, de 16 de diciembre de 2025, dictado al amparo del artículo 45 undecies, apartado 2, del Reglamento (el precepto que eIDAS2 añadió para el archivado electrónico cualificado), cuyo anexo remite precisamente a la CEN/TS 18170:2025 como norma de referencia.

La diferencia con la conservación de firmas es de alcance. La 511 se centra en mantener la validez de la evidencia criptográfica de un documento firmado. El archivado cualificado va un paso más allá y se ocupa del documento como objeto que debe conservarse íntegro, legible y disponible a lo largo del tiempo, esté firmado o no, incluyendo la garantía de su integridad, la trazabilidad de accesos y las políticas de retención. Es la traducción normativa de una necesidad muy antigua (el archivo) al lenguaje de los servicios cualificados de confianza. Por primera vez, un prestador puede ofrecer archivado con el mismo nivel de garantía jurídica que ya tenían la firma electrónica, el sello electrónico o el sellado de tiempo.

Y merece la pena deshacer un malentendido frecuente: el archivado no sustituye a la conservación de firmas, sino que se apoya en ella. La propia 511 sigue siendo la pieza que garantiza la pervivencia de la evidencia de firma, de modo que un prestador de archivado electrónico cualificado puede utilizar los servicios de un prestador de conservación para esa parte (recurrir a un servicio 511 para mantener vivas las firmas y sellos de los documentos que custodia). No estamos ante servicios que compiten, sino ante servicios que se complementan: el archivado orquesta la custodia del expediente y delega en la conservación el cuidado a largo plazo de la evidencia criptográfica. Es exactamente la lógica de capas que recorre todo este artículo.

Hay además una segunda función del archivado que merece destacarse porque a menudo pasa desapercibida: la conversión de formatos. Custodiar un documento durante décadas no consiste solo en que sus bits no cambien; consiste en que siga siendo legible. Y los formatos también envejecen. Un formato de fichero que hoy es universal puede quedar obsoleto y dejar de utilizarse en favor de otros, y cuando eso ocurra el servicio de archivado debe poder convertir el documento al nuevo formato preservando su contenido, su presentación fiel y su valor probatorio. Es, en el plano de los formatos, el paralelo exacto de lo que la conservación hace en el plano de los algoritmos: así como un servicio 511 migra de algoritmos criptográficos antes de que dejen de ser fiables, un servicio de archivado migra de formatos antes de que dejen de poder abrirse. Legibilidad futura de los datos y robustez futura de la criptografía son las dos caras de la misma promesa: que dentro de veinte años el documento no solo exista, sino que se pueda abrir y demostrar.

Si la conservación protege la firma, el archivado protege el expediente. Y el siguiente paso es preguntarse qué ocurre cuando lo que necesitamos proteger no es un documento aislado, sino la relación entre muchos hechos a lo largo del tiempo.

El tercer paso: orden temporal

Aquí entra la novedad más interesante del segundo eIDAS: los registros electrónicos (electronic ledgers) como nuevo servicio cualificado de confianza. La especificación de referencia es CEN/TS 18264, publicada en 2025.

Y su acto de ejecución, del mismo lote de diciembre de 2025, es el Reglamento de Ejecución (UE) 2025/2531, dictado al amparo del artículo 45 terdecies, apartado 3, del Reglamento (el precepto que eIDAS2 dedicó a los registros electrónicos cualificados).

Yo prefiero explicarlo con una idea sencilla: un registro electrónico es un archivo de orden cronológico. No solo guarda entradas de datos, sino que garantiza su secuencia temporal de forma que ninguna se pueda insertar, borrar o reordenar sin que se note. Es, si se quiere, un sellado de tiempo elevado a la categoría de estructura: no marcamos un único documento con una fecha, sino que construimos una cadena de acontecimientos cuya ordenación es en sí misma la prueba.

Y una vez que aceptamos que lo que aporta valor es la ordenación cronológica garantizada, surge la pregunta técnica que da nombre a la sesión: ¿cómo se construye ese orden? Y hay dos respuestas legítimas.

La primera es usando una infraestructura centralizada: un único prestador cualificado mantiene el registro, lo sella y responde de su integridad. Es sencillo de auditar y encaja perfectamente en el modelo de prestador cualificado que ya conocemos.

La segunda es usando una infraestructura de nodos interconectados que replican la información (a veces llamada infraestructura distribuida): el orden cronológico se construye mediante la conexión de los nodos que acuerdan entre sí (por las reglas de gobernanza) la secuencia de las entradas. Aquí es donde la tecnología de registro distribuido (DLT) entra en juego, no como una moda, sino como una forma concreta de lograr esa ordenación sin depender de un único punto. Cuando ese registro distribuido se presta con las garantías de un servicio cualificado de confianza, hablamos de qDLT: un registro distribuido cualificado.

Permítaseme aquí un apunte terminológico que vengo defendiendo desde hace tiempo. El Reglamento ha consagrado el término DLT (Distributed Ledger Technology, tecnología de registro distribuido), y a él me atengo por rigor normativo. Pero, puestos a bautizar la idea con precisión, yo preferiría hablar de RJT (Replicated Journal Technology). La razón es contable: en la partida doble, el orden cronológico de los hechos no se guarda en el ledger (el libro mayor, que agrupa los apuntes por cuenta), sino en el journal (el libro diario, que los anota uno tras otro según van ocurriendo). Y como lo que aquí estamos preservando es justamente la secuencia temporal, el nombre idóneo a adoptar para esta tecnología debería orientarse al diario replicado antes que al mayor distribuido. Es, seguramente, una batalla terminológica ya perdida frente al texto oficial, pero no por ello menos exacta.

Un buen ejemplo europeo de esta aproximación es EBSI, la infraestructura europea de servicios blockchain, hoy gobernada a través de la figura del Europeum-EDIC (un consorcio de infraestructura digital europea). EBSI muestra que el modelo distribuido no es incompatible con la confianza cualificada: los nodos pueden estar operados por administraciones y prestadores identificados, con anclas de confianza gubernamentales, de modo que el resultado combina la resiliencia de la distribución con la responsabilidad jurídica que exige el marco eIDAS.

Y vale la pena fijarse en un detalle del Reglamento de Ejecución (UE) 2025/2531, porque recoge con precisión esta dualidad. El acto de ejecución exige a todos los prestadores de registros electrónicos cualificados cumplir con la norma ETSI EN 319 401 (requisitos generales de política para prestadores de servicios de confianza) y añade requisitos específicos para la variante distribuida: cuando el registro se construye mediante nodos, el prestador debe cumplir además la ISO 23257:2022 (arquitectura de referencia de las tecnologías de registro distribuido) y la ISO/TS 23635:2022 (directrices de gobernanza). Dicho de otro modo, es el propio acto de ejecución el que reconoce las dos variantes y reserva las normas de consenso y gobernanza de DLT para el caso distribuido, que es cuando hablamos con propiedad de qDLT. La regulación, una vez más, no impone una tecnología: describe garantías y deja abierta la forma de alcanzarlas.

Merece la pena subrayar la continuidad normativa: de conservación (511) pasamos a archivado cualificado (18170) y de ahí a registro cronológico o qDLT (18264). No son tres mundos, sino tres capas de una misma idea que va ganando ambición: primero mantener con plenos efectos una firma electrónica, luego custodiar un documento (firmado o no) garantizando su recuperación futura, y finalmente ordenar y relacionar los hechos de forma verificable, cuando ese orden pueda producir efectos legales.

Lo que un registro cronológico permite hacer

La parte que más me interesa, y a la que dediqué buena parte de mi intervención, no es la tecnología del registro en sí, sino las funcionalidades que habilita cuando registramos no solo el documento, sino también su contexto: quién es su propietario, qué derechos incorpora y cómo evoluciona. Un registro cronológico bien diseñado abre la puerta a tres capacidades que hasta ahora eran difíciles de trasladar al mundo digital con plenas garantías.

La primera es la transferibilidad (o endosabilidad). Si el registro no anota únicamente que existe un documento, sino también quién es su titular, entonces puede anotar igualmente la transmisión de esa titularidad. Esto es lo que permite tratar un archivo electrónico como un bien que cambia de manos: pensemos en los efectos comerciales, en los títulos representativos de mercancías o en cualquier derecho que tradicionalmente se «endosaba» sobre un papel. El registro cronológico convierte la cadena de endosos en una secuencia verificable de entradas.

La segunda es la obliterabilidad (o cancelabilidad). Un derecho no solo se transmite: también se consume. Si un archivo representa una entrada de cine o el acceso a un espectáculo, necesitamos poder marcar que ese derecho ya se ha ejercido, de forma que no pueda usarse dos veces. El registro no borra la entrada (la evidencia permanece), pero anota de manera indeleble su cambio de estado: emitido, transferido, consumido. Es la diferencia entre tachar y tirar: el hecho de que un derecho se agotó es, en sí mismo, un hecho que merece quedar registrado. Es el caso del matasellos, por ejemplo.

La tercera es la completitud, que a mí me gusta describir como una grapa electrónica. Un documento raramente viaja solo. Un contrato lleva anexos; una escritura lleva anotaciones; un acuerdo evoluciona mediante versiones sucesivas. Pensemos en las novaciones contractuales, en las que las partes acuerdan modificar el clausulado: lo que importa jurídicamente no es solo el último texto, sino la relación completa entre el documento original, sus anexos y cada una de sus evoluciones. La completitud consiste en mantener unidos, de forma verificable, el documento y todo lo que le acompaña (anotaciones, anexos y sus propias versiones), de modo que el conjunto se conserve como una unidad indivisible y trazable. La grapa no solo junta papeles: registra en qué orden se fueron juntando.

Estas tres funcionalidades comparten un rasgo: solo son posibles si el registro guarda más que el documento. Guarda su titularidad, su estado y sus relaciones. Y solo son fiables si esa información está ordenada en el tiempo de forma que no pueda manipularse. Por eso el registro cronológico cualificado no es un capricho técnico, sino el sustrato sobre el que se pueden construir servicios que hasta ahora vivían atados al papel o a intermediarios de confianza cerrados.

Una base de datos con genealogía jurídica: las anotaciones en cuenta y el Cartulario de EADTrust

Para que estas tres funcionalidades sean algo más que una promesa, hace falta gestionar una base de datos asociada al servicio con unas propiedades muy concretas: que registre, para cada objeto archivado, quién es su titular, en qué estado se encuentra el derecho que incorpora (y donde o frente a quien se ejerce este derecho) y cómo se relaciona con otros documentos; y que lo haga de modo que cada cambio quede anotado en secuencia y resulte oponible frente a terceros. Quien conozca el Derecho del mercado de valores reconocerá el patrón de inmediato, porque es exactamente el que rige la representación de valores mediante anotaciones en cuenta: un registro contable en el que la titularidad, las transmisiones, los gravámenes y la extinción de los derechos no se documentan sobre un título físico, sino que se constituyen y se prueban por su inscripción. La transferibilidad es, en ese lenguaje, la transmisión de la anotación; la obliterabilidad, su cancelación; la completitud, el vínculo entre la anotación principal y sus accesorias. No es una coincidencia: el registro cronológico cualificado y el registro de anotaciones en cuenta resuelven el mismo problema —dar certeza sobre la titularidad y el estado de un derecho a lo largo del tiempo— con la misma herramienta: una base de datos fiable y ordenada.

En EADTrust llevamos tiempo trabajando sobre esta idea. Nuestro servicio Cartulario se diseñó hace ya bastantes años partiendo precisamente de esas premisas: tratar el archivo no como un simple depósito de ficheros, sino como un registro que anota titularidad, estado y relaciones, con la vista puesta en funcionalidades como la endosabilidad, la cancelabilidad y la completitud mucho antes de que el marco normativo europeo las recogiera de forma explícita.

Y ya que hablamos del nombre: un cartulario era, en la Edad Media, el códice en el que monasterios y cabildos copiaban y custodiaban sus escrituras, privilegios y donaciones para que no se perdieran (viene a ser el bisabuelo de la matriz notarial). Así que, bien mirado, en EADTrust llevamos en esto del archivo de orden cronológico desde varios siglos antes de que se inventara el PDF; la única diferencia es que hemos cambiado la vitela por un servidor digital y al monje amanuense por un sello de tiempo de precisión de milisegundo.

Y a esa base de partida Cartulario añade ahora un refinamiento que va justo al corazón de lo que discutíamos en Tallinn: sellos de tiempo de precisión de milisegundo (1 ms) asociados a cada solicitud de archivo. Cuando la prueba es la ordenación, la resolución temporal importa: disponer de una marca de tiempo con precisión de milisegundo en cada operación permite garantizar con mucha mayor finura el orden cronológico de las entradas, y resolver sin ambigüedad la secuencia incluso cuando varias solicitudes se acumulan en un intervalo muy breve. Es, en la práctica, la materialización de esa idea de «archivo de orden cronológico» de la que parte todo este razonamiento.

Por qué esto encaja con el resto del ecosistema

No quiero concluir el artículo sin conectar esta historia con la conversación más amplia sobre identidad digital europea. El ecosistema de la cartera europea (EUDI Wallet) y de las declaraciones electrónicas de atributos necesitan anclas de confianza sólidas: lugares donde asentar de forma verificable quién ha dicho qué, sobre quién y cuándo. Un registro cronológico cualificado (centralizado o en forma de qDLT) es precisamente uno de esos anclajes. Puede unir el mundo de la identidad con la responsabilidad jurídica del marco eIDAS.

Y todo ello sigue descansando sobre la primera piedra que mencionaba al principio: la capacidad de conservar la evidencia a largo plazo y de migrar de algoritmos cuando haga falta. La llegada de la criptografía postcuántica no invalida esta arquitectura; al contrario, la hace más necesaria. Un registro que ordena documentos en el tiempo debe ser, por diseño, un registro capaz de sobrevivir al paso del tiempo, incluido el tiempo en que los algoritmos de hoy dejen de protegernos o los formatos de codificación de documentos se sustituyan por otros..

Esa fue, en esencia, mi tesis en Tallinn: que las DLT y el qDLT no aparecen de la nada, sino que son el siguiente peldaño natural de una escalera que empezó conservando firmas, siguió archivando documentos y ahora aprende a ordenar los hechos. Verlo así ayuda mucho a no perderse: cada norma nueva no sustituye a la anterior, sino que le añade una capa de ambición.

Probar Cartulario

Si quieres experimentar con estas ideas sobre un servicio real, en EADTrust ponemos Cartulario a disposición de quienes deseen probarlo. Conviene precisar su naturaleza actual con total transparencia: hoy se ofrece como servicio de confianza no cualificado y está pendiente de auditoría para ser considerado servicio cualificado en el marco de eIDAS. Esa distinción no es un matiz menor (es, precisamente, la línea que separa un servicio de confianza de un servicio cualificado de confianza), y preferimos dejarla clara desde el principio.

Quien quiera conocerlo, plantear un proyecto piloto o comentar casos de uso (endosabilidad, cancelabilidad, completitud o el sellado de tiempo de precisión de milisegundo) puede escribirnos a info@eadtrust.com o llamarnos al 902 365 612 / 91 716 05 55. Más información en www.eadtrust.eu.

Candidatura de Ismael Arribas a la Presidencia del Subcomité CTN71/SC307 «Blockchain y tecnologías de registro distribuido»


Se ha abierto el plazo para votar las candidaturas a la Presidencia del Subcomité CTN 71/SC 307 «Blockchain y tecnologías de registro distribuido» de UNE. Ismael Arribas es uno de los candidatos a la presidencia.

Cuando Ismael me llamó, me dijo: “sería un honor, si prospera la candidatura, que estés a mi lado como Vicepresidente”. Como Presidente de la Comisión de Blockchain de AMETIC, este ofrecimiento resulta un refuerzo que con gusto estoy dispuesto a compartir con su candidatura.

El subcomité ha funcionado porque ha sabido articular expertos de administraciones, empresas, asociaciones, universidad y prestadores de servicios. Esa es la cultura que conviene preservar.

Gracias a César Pérez-Chirinos

Cualquier relevo que no comience con el agradecimiento sería injusto. César Pérez-Chirinos ha presidido el CTN 71/SC 307 desde su constitución, en marzo de 2017, y lo ha hecho con la discreción, el rigor y la constancia que exige un órgano de normalización.

Bajo su presidencia, España no se limitó a seguir el trabajo internacional: contribuyó a definirlo. El subcomité se alineó con ISO/TC 307 y con CEN/CLC JTC 19, y dio cauce a un hito que todavía hoy se cita como referencia: la UNE 71307-1, primer estándar mundial sobre gestión de identidades digitales descentralizadas basada en blockchain y otras DLT, después elevado al ámbito europeo.

César ha sostenido durante años una posición española coherente en foros donde es fácil fragmentarse. Ha representado al subcomité con la mirada de quien conoce tanto la tecnología como las exigencias de un entorno regulado (su trayectoria en el Banco de España no es un detalle menor) y ha permitido que el trabajo técnico primara sobre las adscripciones de cada uno. Esa es una deuda colectiva. Gracias, César, por el tiempo, por la paciencia institucional y por haber dejado el listón alto.

Ismael Arribas: el candidato que ha estado en todos los frentes de trabajo

Si hay un rasgo que distingue a Ismael Arribas no es la visibilidad puntual, sino la continuidad en los grupos de trabajo. Quienes participan en el ámbito de la normalización saben que el valor no está en la reunión plenaria, sino en las horas de redacción, de comentarios, de «liaisons», de conciliación de textos y de seguimiento de ítems que avanzan a un ritmo distinto en ISO, en CEN-CENELEC, en ETSI o en UIT.

Ismael no ha sido un observador periférico. Ha sido, y es, vicepresidente del propio CTN-UNE 71/SC 307. A escala internacional es convenor del ISO/TC 307/WG 3, Smart contracts and their applications, el grupo que trabaja la taxonomía, la clasificación y el encaje de los contratos inteligentes en sistemas DLT.

Esa responsabilidad no es aislada. Su actividad se ha extendido, de forma sostenida, por varios de los espacios en los que se decide de verdad la agenda:

  • Convenor del PNE 71308 en UNE, sobre el uso de blockchain y DLT para la gestión de evidencias digitales.
  • Participación y liaison entre CEN/CLC JTC 19 y ETSI ISG PDL, además de rapporteur en este último.
  • Cofundador de INATBA y copresidente de su Comité de Estándares.
  • Enlace entre ISO/TC 307 y ISO/TC 292 (seguridad y resiliencia).
  • Presencia en ITU-T, incluida la vicepresidencia del grupo de aplicaciones y servicios del Focus Group sobre el metaverso.
  • Asesoría en normalización para LACChain y el BID Lab.

También ayudó a la gobernanza de Alastria y fue el lider de su comisión de estándares.

Ese mapa no es un currículum ornamental. Es la prueba de que ha invertido esfuerzo en todos los grupos de trabajo relevantes, nacionales e internacionales, no solo en el que le resultaba más cómodo. Quien ha coordinado el WG3 de contratos inteligentes, ha impulsado normas nacionales de evidencias digitales y ha mantenido los puentes con ETSI, CEN-CENELEC, INATBA e ITU entiende la interdependencia real del programa de trabajo: identidad, gobernanza, sostenibilidad, smart contracts, interoperabilidad y usos.

Hay un dato reciente que resume bien esa capacidad de ejecución: Ismael fue el convenor del ISO/TC 307/WG 3 que impulsó la reunión internacional del comité en Valladolid, en junio de 2024, con el apoyo de UNE, del Ayuntamiento y de la Agencia de Innovación de la ciudad. Convertir a España en sede de la plenaria mundial no es un gesto protocolario; es el resultado de años de presencia técnica y de credibilidad ante secretarías y delegaciones.

Por eso su candidatura a la Presidencia es la evolución natural de quien ya ha hecho el trabajo menos vistoso: estar, aportar, convenir y sostener el hilo entre el subcomité español y los foros en los que se escriben las normas que después adoptamos.

Una propuesta para la nueva etapa del CTN 71/SC 307

La candidatura parte de la continuidad con el trabajo realizado desde 2017 y propone reforzar al CTN 71/SC 307 como punto español de referencia para la normalización de blockchain y las tecnologías de registro distribuido. La prioridad será anticipar los ámbitos en los que la normalización pueda aportar interoperabilidad, seguridad jurídica, confianza y capacidad de adopción industrial.

Esto requiere mantener una participación española activa en ISO/TC 307 y CEN/CLC JTC 19, reforzar la coordinación con otros organismos como ETSI e ITU-T y favorecer la participación de administraciones públicas, empresas, pymes, universidades, centros de investigación, prestadores de servicios de confianza y otras organizaciones relevantes.

Especial atención deberán recibir la interoperabilidad, los contratos inteligentes, la gestión de evidencias digitales, la identidad y las credenciales cuando resulte pertinente el uso de DLT, la tokenización, la gobernanza, la sostenibilidad y la relación entre estas tecnologías y los nuevos marcos regulatorios europeos.

La Presidencia supone la coordinación y servicio al Subcomité: facilitar consensos, promover nuevas iniciativas normativas, mejorar la conexión entre los trabajos nacionales e internacionales y favorecer que España mantenga una presencia relevante en la construcción de los estándares que definirán la próxima generación de infraestructuras digitales de confianza.

Animo a las vocalías a ejercer el voto con conocimiento de causa. Y, sea cual sea el resultado, el subcomité seguirá necesitando lo que César practicó durante años: rigor, paciencia y sentido de país.

Actualización (2.10.2026)

Finalmente Ismael Arribas ha sido elegido Presidente del Subcomité CTN71/SC307 «Blockchain y tecnologías de registro distribuido».

Gracias a todos los participantes





CSC Trust without Borders Summit 2026: la cumbre de la confianza digital sin fronteras en Bogotá


En mayo de 2026, Bogotá acogerá una de las citas más relevantes del año en el ámbito de la identidad digital y los servicios de confianza interoperables: el CSC Trust without Borders Summit 2026, organizado por el Cloud Signature Consortium (CSC).

El lema “Trust without Borders” capta muy bien el espíritu del evento: tender puentes entre marcos regulatorios, infraestructuras y servicios de confianza en Europa y América, con foco especial en la interoperabilidad de la firma electrónica, la identidad digital y las wallets de identidad.

Datos prácticos del evento

  • Nombre: CSC Trust without Borders Summit 2026.
  • Fechas: 13 y 14 de mayo de 2026.
  • Lugar: Bogotá, Colombia. El 13 de mayo en el Hilton Bogotá Corferias y el 14 de mayo en la Universidad de los Andes, Edificio Mario Laserna
  • Organización: Cloud Signature Consortium (CSC).
  • Inscripción:
    • Página oficial en español: https://cscsummit.com/es (desde ahí se accede al registro de asistentes, condiciones para expositores y, si procede, a la convocatoria de ponentes).

Tema central: confianza digital sin fronteras

La cumbre se plantea como un punto de encuentro entre reguladores, autoridades de identidad, proveedores de servicios de confianza, fabricantes de infraestructuras de seguridad, academia y estándares, con el objetivo común de avanzar hacia un ecosistema de confianza globalmente interoperable.

Entre los temas clave que se abordarán:

  • Interoperabilidad de la firma electrónica y servicios de confianza en el contexto de eIDAS 2.0 europeo y marcos latinoamericanos.
  • Identidad digital, wallets y cómo alinear infraestructuras europeas (EUDI Wallet, eID de base eIDAS) con ecosistemas de identidad en Colombia y en la región.
  • Criptografía Post‑cuántica, infraestructuras de confianza resilientes y estándares abiertos (CSC, ETSI, W3C, FIDO, etc.).
  • Regulación, reciprocidad jurídica y comercio internacional seguro, con especial atención a la interoperabilidad entre la UE y las Américas.

Algunos ponentes de referencia

El programa reúne un panel muy sólido de expertos internacionales, con figuras conocidas en el ámbito de la identidad digital, eIDAS, servicios de confianza y estándares de firma. A continuación una selección orientativa (la lista completa está disponible en la web oficial de ponentes: https://cscsummit.com/speakers).

  • Viky Manaila – Presidenta del Cloud Signature Consortium y experta en eIDAS/eIDAS 2.0, mercados digitales seguros y servicios de confianza.
  • Borja Carreras – Presidente de GSE y fundador de bemyself ID, con décadas de experiencia en identidad digital, autosoberanía y ciberseguridad en Europa y Latinoamérica.
  • Kim Nguyen – Senior VP de Innovación en Bundesdruckerei, trabajando en identidad digital, IA de confianza, post‑cuántica y soberanía digital.
  • Jean Everson Martina – Profesor asociado de Ciencia de la Computación (UFSC, Brasil), especializado en identidad digital, documentos electrónicos y proyectos de interoperabilidad en América Latina.
  • Sebastian Elfors – CTO/CSO en IDnow, experto en eIDAS 2.0, QTSP, wallets de identidad y estándares internacionales (ETSI, CEN, W3C, FIDO, CSC).
  • Sven Prinsloo – Presidente del Comité Técnico del CSC y CTO de Ascertia, con fuerte experiencia en estándares de firma y API CSC para interoperabilidad.
  • Guillaume Forget – EVP de innovación en Cryptomathic, trabajando en firmas digitales, identidades, gestión de claves, pagos y seguridad móvil.
  • Arno Fiedler – Vicepresidente de ETSI Working Group ESI, con amplia experiencia en infraestructuras de confianza, eIDAS, PSD2, GDPR y CA/B Forum.
  • Daniel Rendon – EVP de Strategic Partnerships & Business Development en SSL.com, contribuyendo al ecosistema de certificados y servicios de identidad.
  • Igor Marcolongo – Head of Business Evolution en Tinexta InfoCert, miembro de la Junta del CSC y experto en eIDAS y servicios de confianza europeos.

Es especialmente interesante el enfoque de muchas sesiones en arquitecturas de identidad, interoperabilidad entre frameworks y adopción práctica de estándares como CSC.

Temas de las sesiones y talleres (enfoque técnico‑regulatorio)

En el Summit se combinarán mesas de alto nivel, sesiones técnicas y talleres prácticos, con un enfoque híbrido entre regulación, estándares y despliegue en el mundo real. Entre los bloques que más podrían interesar a tu audiencia:

  • Regulación e interoperabilidad
    • Armonización de la firma electrónica y la identidad digital en el marco de eIDAS 2.0 y de iniciativas latinoamericanas.
    • Reciprocidad jurídica y reconocimiento de servicios de confianza para el comercio transfronterizo en la UE y América.
  • Tecnología, estándares y arquitecturas
    • Infraestructuras de identidad y PKI alineadas con eIDAS 2.0, API CSC y estándares de interoperabilidad.
    • Criptografía Post‑cuántica, wallets de identidad europea y latinoamericana, y modelos de autosoberanía compatible con marcos regulatorios existentes.
  • Casos de uso y adopción en Latinoamérica
    • Proyectos de gobierno digital, e‑administración y servicios financieros electrónicos en Colombia y otros países de la región.
    • Lecciones aprendidas de despliegues de identidad digital y firmas interoperables en distintos contextos regulatorios.
  • Negocio y ecosistema de servicios de confianza
    • Cómo los frameworks de CSC y la estandarización abierta fortalecen el “business case” de proveedores, autoridades de identidad y fintech.
    • Nuevas iniciativas de CSC LATAM y alianzas público‑privadas para impulsar la confianza digital en la región.

Por qué asistir a CSC Trust without Borders Summit 2026

Para los expertos en identidad digital, servicios de confianza, eIDAS y gobierno digital, el Summit de Bogotá es una oportunidad privilegiada para:

  • Conectar con los actores clave que están definiendo la interoperabilidad de la firma electrónica y la identidad digital en el Atlántico.
  • Contrastar la evolución de marcos europeos (eIDAS 2.0, EUDI Wallet) con la realidad de la adopción en Latinoamérica, y entender cómo se pueden articular ambos mundos.
  • Participar en debates muy concretos sobre estándares CSC, API de firma, adaptación a la criptografía post‑cuántica y arquitecturas de identidad que ya están en pruebas de campo.

Cómo registrarse

Si te interesa seguir de cerca la evolución de los servicios de confianza interoperables entre la UE y América Latina, el CSC Trust without Borders Summit 2026 en Bogotá es una cita imprescindible.

Más información y registro en español:
https://cscsummit.com/es

Hoy se han publicado 4 nuevos actos de ejecución de desarrollo del Reglamento #EIDAS2


La Comisión Europea ha publicado cuatro nuevos reglamentos de ejecución en el Diario Oficial de la Unión Europea del 17 de diciembre. Ya son varias rondas de actos de ejecución, que comenzaron en diciembre de 2024, y se alcanza la publicación de 26 actos de ejecución.


Los reglamentos de ejecución publicados hoy son los siguientes:

📌 Qarchiv: servicios de archivo electrónico cualificados. REGLAMENTO DE EJECUCIÓN (UE) 2025/2532 DE LA COMISIÓN de 16 de diciembre de 2025 por el que se establecen disposiciones de aplicación del Reglamento (UE) n.o 910/2014 del Parlamento Europeo y del Consejo en lo que respecta a las normas y especificaciones de referencia para los servicios cualificados de archivo electrónico
📌 QELedgers: libros de contabilidad electrónicos cualificados. REGLAMENTO DE EJECUCIÓN (UE) 2025/2531 DE LA COMISIÓN de 16 de diciembre de 2025 por el que se establecen disposiciones de aplicación del Reglamento (UE) n.o 910/2014 del Parlamento Europeo y del Consejo en lo que respecta a las normas y especificaciones de referencia para los libros mayores electrónicos cualificados
📌 QWACs: certificados cualificados para la autenticación de sitios web. REGLAMENTO DE EJECUCIÓN (UE) 2025/2527 DE LA COMISIÓN de 16 de diciembre de 2025 por el que se establecen disposiciones de aplicación del Reglamento (UE) n.o 910/2014 del Parlamento Europeo y del Consejo en lo que respecta a las normas de referencia para los certificados cualificados de autenticación de sitios web
📌 QTSPs: normas de cumplimiento y seguridad: proveedores de servicios de confianza cualificados. REGLAMENTO DE EJECUCIÓN (UE) 2025/2530 DE LA COMISIÓN
de 16 de diciembre de 2025 por el que se establecen disposiciones de aplicación del Reglamento (UE) 910/2014 del Parlamento Europeo y del Consejo en lo que respecta a los requisitos para los prestadores cualificados de servicios de confianza que prestan servicios de confianza cualificados.

Esta es la lista de los actos de ejecución anteriores.

Y el mapa que actualiza permanentement Joerg Lenz:

Estándares de ETSI actualizados en 2025 para acompañar a los actos de ejecución de #EIDAS2 o definir funcionalidades de la Cartera IDUE


El Reglamento (UE) 2024/1183, conocido como eIDAS 2.0, fue publicado el 30 de abril de 2024 en el Diario Oficial de la Unión Europea y entró en vigor el 20 de mayo de 2024.

Este marco normativo modifica el Reglamento original eIDAS de 2014 (UE 910/2014) para fortalecer la identidad digital europea, introduciendo elementos clave como las Carteras de Identidad Digital Europea (EUDI Wallets o IDUE en español), que son aplicaciones móviles o servicios en la nube que permiten a los ciudadanos y empresas gestionar de forma segura y privada sus identidades digitales, atributos personales (como diplomas o carnets de conducir) y transacciones transfronterizas. El objetivo es garantizar interoperabilidad, control de sus datos por parte del usuario y aceptación obligatoria por parte de sectores privados clave (banca, telecomunicaciones, etc.) a partir de finales de 2027.

Los Actos de Ejecución (Implementing Acts) son regulaciones complementarias adoptadas por la Comisión Europea para detallar las especificaciones técnicas, certificaciones y procedimientos. Estos actos son cruciales para la implementación práctica de eIDAS 2.0. Hasta noviembre de 2025, se han adoptado varios lotes:

  • Primer lote (publicado el 4 de diciembre 21 de 2024): Cinco actos clave que establecen especificaciones técnicas para las Carteras IDUE, como requisitos para certificados cualificados, incorporación de usuarios y formatos de listas de confianza (Trusted Lists). Esta publicación marca el inicio de cómputo de varios plazos importantes, por su entrada en vigor el 24 de diciembre,
  • Lotes posteriores (2025): Incluyen el segundo lote (publicado en 2 partes: el 7 de mayo y el 30 de julio) el tercer lote (publicado en 2 partes: el 30 de julio y el 5 de septiembre) y el cuarto lote (publicado el 28 de octubre) con 25 actos acumulados hasta ese momento), enfocados en servicios de confianza (firmas electrónicas, sellos, notificaciones) y declaraciones electrónicas de atributos (Electronic Attestations of Attributes o EAA). Estos actos incorporan referencias explícitas a estándares de ETSI para garantizar conformidad.

Los Estados miembros deben ofrecer al menos una Cartera IDUE gratuita a todos los ciudadanos y residentes para finales de 2026 (24 meses tras la entrada en vigor de los actos del primer lote).

Rol de ETSI en la Evolución de Estándares

El Instituto Europeo de Normas de Telecomunicaciones (ETSI), y el CEN (Comité Europeo de Normalización), son los organismos principales encargados de desarrollar y actualizar los estándares técnicos que soportan eIDAS 2.0. Estos estándares aseguran interoperabilidad, seguridad y privacidad de las Carteras IDUE y de los servicios de confianza.

Tras la publicación de eIDAS 2.0, ETSI ha acelerado su trabajo para alinear las normas con los nuevos requisitos, incorporando tecnologías como credenciales verificables (basadas en W3C y OpenID) y resistencia post-cuántica. La evolución de los estándares ETSI no es un «reinicio», sino una extensión y actualización de los existentes (serie TS 119 para eIDAS 1.0), adaptados a las Carteras IDUE y los actos de ejecución.

El proceso incluye:

  • Desarrollo paralelo: Mientras se negociaba en los Trílogos el texto del reglamento eIDAS 2.0 (2021-2024), ETSI elaboró borradores basados en el documento de Arquitectura y Marco de Referencia (ARF, la última versión a noviembre 2025 es la 2.7.3).
  • Incorporación en actos de ejecución: Los actos referencian explícitamente «listas de estándares de referencia» de ETSI, como se establece en el Artículo 5a del Reglamento
  • Talleres y consultas: Eventos como el Taller ETSI/CEN de septiembre 2024 presentaron avances y demostraciones de pilotos, con consultas abiertas para influir en los borradores.

ETSI ha publicado borradores y versiones finales en 2024-2025, enfocados en interfaces, perfiles de seguridad y certificación para la Cartera IDUE y el resto de Servicios de Confianza.

A continuación, se incluyen las principales actualizaciones (o normas nuevas) publicadas por ETSI en 2025:

  1. ETSI TS 119 602 V1.1.1 (2025-11) – Electronic Signatures and Trust Infrastructures (ESI); Lists of trusted entities; Data model. Listas de entidades de confianza; Modelo de datos
  2. ETSI EN 319 401 V3.2.1 (2025-11)– – Electronic Signatures and Trust Infrastructures (ESI); General Policy Requirements for Trust Service Providers. Requisitos generales de Política para Prestadores de Servicios de Confianza. Se está preparando una actualización.
  3. ETSI TS 119 542 V1.1.1 (2025-10) – Electronic Signatures and Trust Infrastructures (ESI); Use of EU Digital Identity Wallets and electronic signatures for identification with Smart Contracts. Uso de Carteras de Identidad Digital de la UE y firmas electrónicas para la identificación con contratos inteligentes.
  4. ETSI TS 119 541 V1.1.1 (2025-10) – Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for Smart Contracts using Electronic Ledgers. Requisitos normativos y de seguridad para los contratos inteligentes que utilizan archivos electrónicos con orden cronológico.
  5. ETSI TS 119 441 V1.3.1 (2025-10) -Electronic Signatures and Trust Infrastructures (ESI); Policy requirements for TSP providing signature validation services. Requisitos sw Política para los PSC que prestan servicios de validación de firmas.
  6. ETSI TR 119 540 V1.1.1 (2025-10) – Electronic Signatures and Trust Infrastructures (ESI); Standardization requirements for Smart Contracts based on Electronic Ledgers. Requisitos de estandarización para los contratos inteligentes basados en archivos electrónicos con orden cronológico.
  7. ETSI TS 119 475 V1.1.1 (2025-10) – Electronic Signatures and Trust Infrastructures (ESI); Relying party attributes supporting EUDI Wallet user’s authorization decisions. Atributos de las partes usuarias (informadas) que respaldan las decisiones de autorización de los usuarios de Cartera IDUE.
  8. ETSI TS 119 511 V1.2.1 (2025-10)– Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for trust service providers providing long-term preservation of digital signatures or general data using digital signature techniques. Requisitos de Política y seguridad para los Prestadores de Servicios de Confianza que ofrecen la conservación a largo plazo de firmas digitales o datos generales mediante técnicas de firma digital.
  9. ETSI TS 119 411-8 V1.1.1 (2025-10) – 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. Requisitos de Política y seguridad para los Prestadores de Servicios de Confianza que emiten certificados; Parte 8: Política de certificados de acceso para las partes usuarias (o informadas) de la Cartera IDUE.
  10. ETSI TR 119 411-4 V1.3.1 (2025-09) – Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 4: Checklist supporting audit of TSP against ETSI EN 319 411-1 or ETSI EN 319 411-2. Requisitos de Política y seguridad para los Prestadores de Servicios de Confianza que emiten certificados; Parte 4: Lista de verificación para la auditoría de los Prestadores de Servicios de Confianza (TSP) con arreglo a las normas ETSI EN 319 411-1 o ETSI EN 319 411-2. Se está preparando una actualización.
  11. ETSI TS 119 412-6 V1.1.1 (2025-09)– Electronic Signatures and Trust Infrastructures (ESI); Certificate Profiles; Part 6: Certificate profile requirements for PID, Wallet, EAA, QEAA, and PSBEAA (Public Sector Based Electronic Attestation of Attributes) providers. Perfiles de certificados; Parte 6: Requisitos de Perfil de Certificado para Prestadores de Servicios de DIP, Cartera, DEA, DECA y DEASP (Declaración electrónica de atributos basada en el sector público).
  12. ETSI TR 119 476-1 V1.3.1 (2025-08) – Electronic Signatures and Trust Infrastructures (ESI); Selective disclosure and zero-knowledge proofs applied to Electronic Attestation of Attributes; Part 1: Feasibility study. Divulgación selectiva y pruebas de conocimiento cero aplicadas a la Declaración Electrónica de Atributos; Parte 1: Estudio de viabilidad.
  13. ETSI TS 119 612 V2.4.1 (2025-08) – Electronic Signatures and Trust Infrastructures (ESI);Trusted Lists. Listas de Confianza
  14. ETSI TR 119 479-2 V1.1.1 (2025-07) – Electronic Signatures and Trust Infrastructures (ESI);Technological Solutions for the EU Digital Identity Framework; Part 2: EAA Extended Validation Services Framework and Application. Soluciones tecnológicas para el marco de identidad digital de la UE; Parte 2: Marco y aplicación de los servicios de validación ampliada de las DEA
  15. ETSI EN 319 421 V1.3.1 (2025-07)– Electronic Signatures and Trust Infrastructures (ESI); Policy and Security Requirements for Trust Service Providers issuing Time-Stamps. Requisitos de política y seguridad para los Prestadores de Servicios de Confianza que emiten sellos de tiempo. Se está preparando una actualización.
  16. ETSI EN 319 142-2 V1.2.1 (2025-07) – Electronic Signatures and Trust Infrastructures (ESI); PAdES digital signatures; Part 2: Additional PAdES signatures profiles. Firmas digitales PAdES; Parte 2: Perfiles de firmas PAdES adicionales.
  17. ETSI EN 319 412-4 V1.4.1 (2025-06) – Electronic Signatures and Trust Infrastructures (ESI); Certificate Profiles; Part 4: Certificate profile for web site certificates. Perfiles de certificados; Parte 4: Perfil de certificado para certificados de sitios web,
  18. ETSI EN 319 412-2 V2.4.1 (2025-06) . Electronic Signatures and Trust Infrastructures (ESI); Certificate Profiles; Part 2: Certificate profile for certificates issued to natural persons. Perfiles de certificados; Parte 2: Perfil de certificados para certificados expedidos a personas físicas.
  19. ETSI EN 319 412-5 V2.5.1 (2025-06) – Electronic Signatures and Trust Infrastructures (ESI); Certificate Profiles; Part 5: QCStatements. Perfiles de certificados; Parte 5: campos QCStatements de los certificados. Se está preparando una actualización.
  20. ETSI EN 319 412-1 V1.6.1 (2025-06) – Electronic Signatures and Trust Infrastructures (ESI); Certificate Profiles; Part 1: Overview and common data structures. Perfiles de certificados; Parte 1: Descripción general y estructuras de datos comunes. Se está preparando una actualización.
  21. ETSI EN 319 411-2 V2.6.1 (2025-06)– 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. Requisitos de Política y seguridad para los Prestadores de Servicios de Confianza que expiden certificados; Parte 2: Requisitos para los Prestadores de Servicios de Confianza que expiden certificados cualificados de la UE. Se está preparando una actualización.
  22. ETSI TS 119 471 V1.1.1 (2025-05)– Electronic Signatures and Trust Infrastructures (ESI); Policy and Security requirements for Providers of Electronic Attestation of Attributes Services. Requisitos de Política y seguridad para los Prestadores de Servicios de Declaración Electrónica de Atributos.
  23. ETSI TS 119 411-5 V2.1.1 (2025-02)– Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 5: Implementation of qualified certificates for website authentication as in amended regulation 910/2014. Requisitos de Política y seguridad para los Prestadores de Servicios de Confianza que emiten certificados; Parte 5: Implementación de certificados cualificados para la autenticación de sitios web según el Reglamento 910/2014 modificado.
  24. ETSI TS 119 461 V2.1.1 (2025-02) – Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for trust service components providing identity proofing of trust service subjects. Requisitos de política y seguridad para los componentes de servicios de confianza que proporcionan verificación de identidad de los sujetos de servicios de confianza.
  25. ETSI EN 319 411-1 V1.5.1 (2025-04)– Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements. Requisitos de Política y seguridad para los Prestadores de Servicios de Confianza que emiten certificados; Parte 1: Requisitos generales. Se está preparando una actualización.

Todavía se siguen desarrollando los estándares de ETSI, y hay varios en estado Draft (Borrador) que se espera que se publiquen pronto.