Unlinkable Revocation Lists for Qualified Electronic Attestations: A Blockchain-Based Framework

Abstract

The use of Verifiable Credentials under the new eIDAS Regulation introduces privacy concerns, particularly during revocation status checks. This paper proposes a privacy-preserving revocation mechanism tailored to the European Digital Identity Wallet and its Architecture and Reference Framework. Our method publishes a daily randomized revocation list as a cascaded Bloom filter, enhancing unlinkability by randomizing revocation indexes derived from ARF guidelines. The implementation extends open-source components developed by the European Committee. This work demonstrates a practical, privacy-centric approach to revocation in digital identity systems, supporting the advancement of privacy-preserving technologies.

1. Introduction

The rapid expansion of digital services has created a pressing need for reliable mechanisms to attest user attributes, such as professional qualifications or organizational roles, beyond mere identity verification. Since its inception in the late 1980s by ITU-T as part of the X.500 directory framework and later standardization by the IETF (most notably in RFC 5280), the X.509 certificate has served as the central piece of public-key infrastructures (PKI), binding public keys to identities for use in TLS, S/MIME, and electronic signatures [1]. However, X.509 was primarily designed to establish and validate cryptographic identities, not to manage fine-grained, dynamic attributes or to support selective disclosure.

Attempts to extend X.509 for attribute attestation—by embedding additional information in certificate extensions—have revealed several critical shortcomings. First, the all-or-nothing revocation model means that revoking a single attribute (e.g., loss of professional license) requires invalidating the entire certificate, thereby negating all other valid attributes. Second, X.509’s static nature hinders the timely reflection of attribute changes, as certificate issuance and renewal processes are often slow and centralized. Finally, privacy-preserving selective disclosure is not natively supported: qualified certificates must include personally identifiable information, making it impossible to reveal only certain attributes without exposing the holder’s full identity.

To address these gaps, the forthcoming eIDAS 2 framework introduces “qualified electronic attestation of attributes” as a dedicated trust service, complemented by the European Digital Identity Wallet Architecture and Reference Framework (ARF) to ensure interoperability and user-centric control [2,3]. These initiatives leverage new paradigms—such as Verifiable Credentials and Decentralized Identifiers—to enable granular, revocable, and privacy-preserving attribute attestations, thereby overcoming the rigidity of the X.509 model and meeting the diverse needs of modern digital ecosystems [4].

Four projects, also known as Large Scale Pilots, took the helm to build on the technical specifications of the EU Digital Identity Wallet, each targeting the development and testing of specific use cases. A broad range of domains are covered: e-Government services, banking and SIM card registration, payment operations, educational, health, and social security sectors [5,6,7,8].

Currently, starting to work in the EUDI Wallet and new European Trust Services can be overwhelming due to two factors: many standards and specifications and a lack of framework maturity. The main aim of this paper is to propose and help users easily integrate into the EUDI Wallet framework, while also using a privacy-centric protocol.

The validation of electronic attestation of attributes can pose significant challenges in terms of user privacy because of the combination of disjunctive needs: auditability and privacy at the same time. Another practical obstacle in integrating with EUDI Wallet infrastructure is the complexity of the standards. Therefore, this paper aims to help in two directions: provide a privacy-aware method for attestation validation and provide an open-source enhanced implementation for the main components in the ARF.

The rest of the paper is organized as follows. Section 2 presents a comprehensive context of the current QEAA environment. It touches on the state-of-the-art in terms of legislation, standards, open-source implementations, and pilot projects. Section 3 delves into the problematic area of user privacy with regards to the whole QEEA environment. The proposed protocol for attestation validation is presented in Section 4, and the implemented solution is described in Section 5. Finally, Section 6 is reserved for conclusions, limitations, and future work.

2. Current Technological Context

In this section, we examine the current context of the integration and use of the EUDI Digital Identity Wallet from the perspective of existing legislation, standards, and specifications, such as eIDAS 2.0 [2], the Architecture and Reference Framework (ARF) [9], and the Verifiable Credentials Data Model 2.0. We also analyze the protocols used in the issuance process of Verifiable Credentials (VCs) [10], such as OpenID for Verifiable Credentials (OpenID4VC), as well as those enabling selective disclosure of claims, such as OpenID for Verifiable Presentations (OpenID4VP). In the final part of this chapter, we will also discuss and analyze the four pilot projects selected by the European Commission. Through the Digital Europe Programme, the Commission aims to accelerate digital transformation across various sectors by integrating the EUDI wallet into a broad range of domains, such as e-government services, payment systems, education, healthcare, and social security.

2.1. Legislation

2.1.1. eIDAS 2.0

According to eIDAS 2.0 (European Digital Identity Regulation), Electronic Attribute Attestations (EEAs) are a key part of the framework introduced to complement electronic identities (eIDs) by providing verifiable attributes (e.g., age, nationality, professional qualifications) without necessarily revealing the user’s full identity. They are central to enabling the European Digital Identity Wallet (EUDI Wallet), thus ensuring trusted and more privacy-preserving digital interactions across the EU Member States. Several requirements on EEAs can be inferred from the regulation [2]:

• Issuance—The attestations can be produced by qualified or non-qualified trust services providers, the former being treated as legally valid proofs with the highest level of assurance;
• Security—Must prevent tampering and forgery through strong authentication and integrity mechanisms. Minimal data disclosure is implied, such that user attributes are revealed without unnecessary information (e.g., providing age without disclosing full birthdate);
• Verification and Validation—The attributes must be verifiable by relying parties using publicly available certificates or trust lists (e.g., the EU Trusted List). In this way, there should be implemented mechanisms for revocation and status checking (e.g., OCSP or CRL);
• User Control and Consent—Users must have explicit power over which attributes are shared and with whom. Also, attribute providers must ensure revocability, such that users can withdraw them when needed;
• Interoperability—Attestations issued in one EU member state must be accepted in all others, following the mutual recognition principle. Achieving this requirement means implementing standardized technical protocols and data formats, inherently promoting international collaboration;
• Use in the EUDI Wallet—EAAs can be stored and presented through the European Digital Identity Wallet.

The eIDAS reform has evolved significantly through a two-year negotiation process culminating in November 2023. Initially, the proposal included concerning elements, like a unique and persistent identifier for all users, which raised alarms about mass surveillance and tracking. These risks were mainly mitigated as the final text removed the universal identifier and introduced privacy safeguards such as pseudonimity, selective disclosure (sharing only specific attributes), and unlinkability (preventing tracking across transactions) to avoid profiling. However, concerns remain about government surveillance, as wallet providers could still monitor user activity, and weak enforcement in lax jurisdictions like Ireland, where big-tech companies may exploit loopholes. While the regulation introduced progressive features like a privacy cockpit and zero-knowledge proofs, its technical framework (Architecture Reference Framework) was drafted secretly with influence from big industry groups. The Member States also resisted full transparency, keeping the back-end software closed-source and opposing uniform privacy certifications [11].

Despite these shortcomings, eIDAS 2.0 marks a step forward in digital identity, balancing convenience with privacy, although its success hinges on rigorous enforcement and addressing the lingering risks of abuse.

2.1.2. Related Work on IoMT and Lightweight Authentication

While our focus is on Qualified Electronic Attestations under eIDAS 2.0, several authentication techniques from adjacent domains—such as the Internet of Medical Things (IoMT)—provide valuable insights into privacy-preserving and resource-efficient identity verification. Recent research has proposed hybrid authentication frameworks that combine blockchain-based trust anchors with lightweight on-device verification, suitable for constrained environments. For example, Khan et al. [12] present a scalable model using a Hyperledger-based consortium blockchain integrated with edge computing to achieve secure and low-latency authentication in medical networks. Similarly, Alazab et al. [13] propose a three-factor key agreement protocol for vehicular ad hoc networks (VANETs) that emphasizes collusion resistance and forward secrecy.

These approaches emphasize multi-factor authentication, secure key exchange, and the decentralization of trust—a combination that aligns with our privacy goals in revocation checking and wallet presentation, particularly in mobile or edge deployments.

2.2. Standards

The eIDAS 2.0 regulation establishes a legal foundation for the European Digital Identity ecosystem by mandating that all Member States provide citizens with interoperable digital identity wallets. To ensure these wallets are technically compatible and legally recognized across borders, eIDAS 2.0 is directly supported by a set of mandatory technical specifications, compiled in the Architecture Reference Framework (ARF). This framework defines the key standards that wallet implementations shall follow, including the W3C Verifiable Credentials Data Model (VCDM) for structuring digital credentials and OpenID-based protocols (OpenID4VC, OpenID4VP) for their secure issuance and presentation. These standards enable uniform data exchange, cryptographic verification, and privacy-preserving interactions between users and service providers.

This tight coupling between legislation and technical standards ensures regulatory compliance, interoperability, and trust. Legal requirements such as data minimization, user consent, and cross-border validity are supported through the technical protocols specified in the ARF. For example, credentials encoded in the VCDM format and shared via OpenID4VP flows can be verified anywhere in the EU using standardized mechanisms, while retaining legal effect under eIDAS. As such, eIDAS 2.0 explicitly mandates the use of common technical practices, thereby aligning legal governance with technological implementations for a cohesive and secure digital identity infrastructure across Europe.

2.2.1. ARF

The ARF (Architecture and Reference Framework) is the component of the EUDI Wallet Toolbox that provides the theoretical and architectural perspective when developing or implementing a compatible electronic wallet. The ARF details the standards, identifies the actors, defines their relationship to one another, and enumerates the high-level requirements for each functionality in order for that wallet implementation to be notified and to gain accreditation. The ARF is not a normative document: its requirements are merely technical, not legislative, but the regulations follow the findings and the developments of the ARF. Another aspect worth mentioning is the role of the ARF in the Toolbox, referring here also to the Reference Implementation and the Large-Scale Pilots (LSPs), the two other most significant components of the ecosystem, as neither of these is isolated or independent: the EUDIW Reference Implementation follows the developments and guidelines of the ARF and the LSPs are there to test the EUDI Wallet and expand its use cases in accordance with the ARF, but also to provide feedback to the group developing the ARF as the interaction between actors unfolds [14]. Since its appearance (February 2023—version 1.0.0), as the relations between its actors matured, the ARF developed (at the time of the writing of this article the latest released version of the ARF is 1.7.1 [3]) more service blueprints, more use cases, and more well defined actors, keeping the same core categories of functionalities [15]:

• Secure identification and authentication;
• Exchanging qualified and non-qualified user attributes;
• Electronic signatures;
• Generate and use pseudonyms.

From the functionalities mentioned above, it is not hard to see that, while being a complex and heterogeneous ecosystem, the wallet is user-centric: operations and relations between the actors are there only to facilitate the safe and private exchange of user-consented data, in order for the user to gain authorized access to the desired services. This statement becomes more apparent as a summary of the actors involved and their roles is provided [16]:

• Users of Wallet Units: The natural person in control of the Wallet Unit, the one who installs, activates, configures, and manages the wallet unit to take advantage of its functionalities. The user decides the extent of their relation both to the wallet and to other actors or relying parties and is free to renounce every and all relations with any of them at any time;
• Wallet Providers: A Member State or a mandated/recognized organization to make a certified wallet solution available to the user. The wallet provider is solely responsible for the wallet solution and the wallet unit, while the user remains in control of the attributes stored and managed by the wallet unit;
• Personal Identification Data (PID) Providers: These are in charge of handling all aspects of PID provision to the wallet, from identification and verification of the user, issuing the PID, and providing data for relying parties to be capable of verifying the PID;
• Trusted List Provider: An appointed and notified entity that creates, publishes, and maintains one or more trust lists for the providers in the EUDIW ecosystem;
• Providers of Various Types of Electronic Attestation of Attributes ([Q]EAA and Pub-EAA): Issue attestations under the requirements at their respective level of security and trust;
• Qualified Electronic Signature Remote Creation (QESRC) Providers: Allow the user to be capable of signing documents using a qualified signature and seal;
• Authentic Sources: Sources recognized and/or required by law as source repositories for primary/required attributes about natural or legal persons;
• Relying Parties and Intermediaries: They are either natural or legal persons that rely upon (or require) a means of electronic identification or trust service;
• Conformity Assessment Bodies (CAB): An appointed auditor, who evaluates, audits, and provides certification (the ‘qualified’ status) to QTSPs;
• Attribute Schema Providers for QEAA, Pub-EAA, and EAA: They provide data schema for their types of attestations;
• National Accreditation Bodies: Appointed by the Member State and in charge of accrediting the CABs (the auditor[s] of the auditor[s]);
• Access Certificate Authorities: In charge of providing access certificates to various actors to prove their identity in the ecosystem.

The ARF has evolved significantly since its initial publication, and the ecosystem has expanded to include all the actors needed to implement the core functionalities. Even so, there is much that is still missing or needs to be properly addressed. The ARF acknowledges this in a list of topics (only the most important mentioned here): the Wallet Unit Attestation, wallet-to-wallet interactions, and a mechanism for the reporting of unlawful/suspicious activity. Apart from these topics, which are clearly identified by the developers of the ARF [9], one might definitely add the following:

• Scalable and (possibly) decentralized trust model, since the dedicated Trust List model might not scale well in the long run (this is the only trust framework recognized by eIDAS 2);
• Support for a wider range of wallets, apart from mobile applications targeted for Android and iOS;
• A unitary and coherent strategy to implement: Suspension, Revocation, Delegation, Representation, and Migration;
• Addressing security concerns, vulnerabilities, and how the user can make informed decisions about the identity and trustworthiness of the Relying Parties he comes into contact with;
• The Governance Structure is still unclear in some areas, while the roles and extension of each actor’s authority are not clearly defined.

All of these “concerns” merit a separate debate on their own, and they must certainly find their place in future versions of the ARF.

2.2.2. OpenID for VC

OpenID4VC is a protocol created by the OpenID Connect Working Group for the issuance of Verifiable Credentials (VCs) in a standardized and decentralized manner. The protocol, leveraging the OpenID Connect infrastructure, provides entities the means to acquire cryptographically proven claims about their identity and attributes. Furthermore, the user-centered design enhances not only privacy but also grants the end-user more control over their identity and owned attributes. Being OAuth2.0 and OpenID Connect focused is an important boost for protocol adoption. Still, this also comes with the drawback of being too complex at times or not flexible enough for non-web use cases.

2.2.3. OpenID for VP

Apart from being a secure technique of delivering owned attributes by the holders to verifiers, OpenID4VP is a protocol that allows the former category to selectively disclose what claims are presented to the latter. Likewise, if a verifier wants to determine if the end-user is over 18 years old or not, the latter discloses only the required information (i.e., age ≥ 18) without revealing the birthdate. Furthermore, the verifier can validate the authenticity of the credentials presented without the need to contact the issuer, proving, once again, the focus on privacy-preserving and user-centered design. Instead of its benefits, privacy features such as unlikability and selective disclosure are optional or incomplete.

2.2.4. mDoc/mDL

Standardized under ISO/IEC 18013-5 [17], the mobile Driver’s License (mDL) is a credential that exists under the broader mobile Document (mDoc) format and defines a digital counterpart for the physical driving license. In spite of being tailored for driving licences, the mDoc/mDL can be used to represent any kind of credentials. Despite its benefits, the mDoc/mDL standard is rigid when needed to work with multiple issuers (universities, employers, etc.) since it assumes a centralized issuance entity.

2.2.5. Verifiable Credentials Data Model 2.0

The Verifiable Credentials Data Model (VCDM) 2.0 [10], published by W3C, is an update of the original VDCM specification. It was designed to improve interoperability, scalability, and privacy in decentralized identity systems. A notable improvement on the first specification is the decoupling of the data model from different syntaxes, therefore supporting a broader range of formats, such as JSON, JSON-LD, JADES, CBOR, etc.

Another key improvement is the introduction of formal credential format profiles. These allow specifying how credentials are expressed, signed, and verified, while still being compliant with the base data model.

VDCM specification details a set of entities and credential formats, as follows:

• Issuer—The entity that creates and cryptographically signs a verifiable credential. It is responsible for asserting claims about a subject and is typically identified using a Decentralized Identifier (DID);
• Holder—The entity that receives, stores, and presents verifiable credentials. The holder controls a digital wallet and may be a person, organization, or device. It also manages which credentials to disclose and to whom;
• Subject—The entity that the credential is about. This is the target of the claims contained in the credential. The subject is often the same as the holder but can differ (e.g., a parent holding a credential for a child);
• Verifier—The entity that receives and evaluates verifiable presentations. It checks the authenticity, integrity, and trustworthiness of the credential or presentation, typically using cryptographic proofs and issuer trust frameworks;
• Verifiable Credential (VC)—A tamper-evident, digitally signed assertion issued by an issuer about a subject. It contains claims, metadata, and a proof to ensure authenticity and integrity;
• Verifiable Presentation (VP)—A container used by the holder to present one or more verifiable credentials to a verifier. It may include cryptographic proofs and support of privacy-preserving features like selective disclosure.

2.3. Available Open-Source Components

2.3.1. EUDI Wallet

There are a few versions of wallet implementations that aim for ARF and eIDAS 2.0 compliance, such as the following:

• Spherity [18]: EUDI Wallet for Finance, Energy, Supply Chain, and Industry;
• Indicio Proven [19]: Has integrated support for the EUDI Wallet in its platform;
• Lissi [20]: Has integrated the EUDI Wallet into its connector;
• iGrant.io [21]: Empowers users to securely issue, store, share, and verify verifiable credentials via EUDI wallets;
• Verimi [22]: Enables users to securely store verified personal documents—like ID cards, driver’s licenses, health cards, passports—in a mobile ID wallet.

Apart from these wallets, which try to stay closer to the ARF and eIDAS 2.0, there are also some implementations that use different technologies than their Trust Platform, some using blockchain and the EBSI platform [23].

The EUDI Reference Wallet is a project aiming to showcase a digital and portable platform for authentication and electronic signatures following common standards across the European Union on both Android and iOS devices. Its implementation is modular by design and based on components intended to be easily reused in other projects.

The Android version wraps the EUDI Wallet Core, which is a library that offers, through a simple API, some of the requirements an application must meet to offer the EUDI Wallet’s desired functionalities. As of now, the library provides the following:

• Document issuance, using OpenID4VCI;
• Proximity document presentation, through QR and NFC device engagement;
• Remote document presentation, using OpenID4VP.

The Wallet is aiming to reach its interoperability goal, as it must be easily adapted to several implementations of the ecosystem described in the ARF. Consequently, it facilitates its configuration, offering the possibility to change the issuing API used and the trusted certificates. Furthermore, the documentation attempts to foster community contributions to the wallet, offering the required steps to easily create a development environment, such as how to adapt the wallet to use self-signed certificates or local services.

Regarding security, the wallet will use, should the issuer provide them, the most secure options of the protocol. Most of them are inherited from Open ID Connect, such as the following:

• Pushed Authorization Request (PAR);
• Demonstrating Proof-of-Possession (DPoP);
• Proof Key for Code Exchange (PKCE).

2.3.2. Issuer

The Issuer is the entity responsible for securely providing (Q)EAAs to users. At a conceptual level, the issuer must authenticate the wallet user and obtain their consent to access the required information to generate the requested credential, sign the created attestation, and deliver it to the wallet.

The EUDI Wallet repository offers, besides the wallet itself, two open-source implementations for the issuer: one built in Python 3.9, based on OpenID4VCI (draft 13), and one Kotlin microservice supporting OpenID4VCI (draft 15).

The Kotlin microservice offers generic support only for mDL (in mDoc format) and PID (both in mDoc and SD-JWT formats). Besides that, it acts mostly as a credential/resource server, as it cannot work independently and needs a separate service that represents the OAuth2.0 authorization server that is part of the OpenID4VCI. Consequently, the project comes with a manifest file for deploying the containerized Kotlin microservice, alongside a Keycloak container, which represents the authorization server, and a proxy that eases access to both via HTTPS. The Keycloak container comes pre-configured with the required roles, scopes, object mappers, and clients that are part of the OAuth2.0 protocol and are necessary for the OpenID4VCI flow.

The Python-based issuer is fairly similar to the aforementioned microservice. It also needs an OAuth2.0 server to work. In addition, it can be configured to work with an eIDAS node, and, only for testing purposes, a form-based issuance alternative is available. In contrast to the Kotlin microservice, this variant of the issuer offers, besides PID and mDL (both available in mDoc and SD-JWT format), (Q)EAA age-over-18 pseudonym and (Q)EAA loyalty card (both in mDoc only). Furthermore, both documentation and implementation are more comprehensive and offer the possibility to add custom credentials that can be issued.

However, neither of them is production-ready and can cause problems for existing Trust Service Providers that want to assume the issuer role. More precisely, both implementations are not easily adaptable to an existing infrastructure of one such Trust Service Provider as the key management is not polished. The plain and simple technique consisting of randomly generating a signing key for issued attestations at runtime or importing them from a PKCS#12 keystore is definitely not the approach a Trust Service Provider would take into account. Consequently, the publicly available solutions for the issuer role cannot be used as they require significant adjustments to the TSP’s infrastructure.

2.3.3. Verifier

The current proposed implementation on the Verifier component [24] is based on the Attestation Status List (ASL) and Attestation Revocation List (ARL) for managing and verifying the revocation status of Verifiable Credentials (VCs).

Through a REST API interface, the Verifier component exposes the following operations:

• Generating an Attestation Status List (ASL) or Attestation Revocation List (ARL), which contains information about the status of each individual credential.
• Obtaining the status of a specific credential by submitting its corresponding index along with the verification option. Based on the request parameters, the system queries either the status list or the revocation list.
• Setting or updating of attribute’s status, by modifying the corresponding value from theASL/ARL, depending on the request type and index value.

One drawback of the Verifier proposed solution, in its current form, is the lack of seamless integration on the Issuer side. Therefore, without integration into the Issuer’s internal issuance and management workflows, the revocation mechanism operates relatively independently. To improve the Verifier’s component interoperability, future versions should aim for full integration of the revocation mechanism within the Issuer components. This would allow revocation mechanisms to be automated and kept in sync with attribute issuance and management in real time. In addition, it would be helpful to test a complete end-to-end flow, covering the issuance, verification, and revocation of an attribute.

2.4. Large Scale Pilots

The European Commission, through the Digital Europe Programme, aims to accelerate digital transformation across various sectors. As part of this effort, a funding call was issued in 2022 to support the development and testing of the EU Digital Identity Wallet. In response, four Large Scale Pilot projects were officially launched in April 2023. These pilots represent the first phase of broader implementation, with additional projects anticipated in the near future.

2.4.1. POTENTIAL

One of the four pilot projects, named POTENTIAL, is an initiative of a consortium comprised of 19 European States and Ukraine, co-led by France and Germany, launched in July 2023, with a duration of 2 years, to implement a prototype of the EUDI Wallet. The main goal is to empower individuals to identify themselves and share personal attributes digitally across borders while maintaining full control over their data. Its focus is on six high-impact use cases that are expected to demonstrate real-world functionality: access to government services, opening bank accounts, SIM card registration, usage of mobile driving license, qualified electronic signatures, and medical prescriptions management [25].

Targeted use cases are strategically chosen to cover essential daily services and to ensure interoperability across common sectors of the EU Member States. The project is also contributing to the development of the technical architecture, legal frameworks, and governance models that will underpin the EUDI Wallet infrastructure.

Through collaboration and large-scale testing, POTENTIAL seeks to create a robust foundation for a trusted European digital identity ecosystem. The initiative promotes not only cross-border trust and efficiency but also aligns with broader EU goals of digital sovereignty, privacy by design, and user-centric digital public services.

2.4.2. EU Digital Wallet Consortium (EWC)

A second collaborative endeavor is envisioned to leverage the proposed eIDAS v2 framework by focusing on Digital Travel Credentials across the countries of the EU. The EWC was selected in December 2022 to participate in large-scale pilots aimed at ensuring interoperability and the adoption of the European Digital Identity Wallet. The consortium comprises representatives from all 27 EU Member States, as well as from other countries, with its period being from 2023 to 2025. Notable companies and organizations involved include Piraeus Bank (Greece), Rabobank (Netherlands), Visa Europe Limited (UK), Amadeus SAS (France), Siemens AG (Germany), Yubico (Sweden), and the Dutch Chamber of Commerce. In addition to digital travel credentials, the EWC is developing two foundational components to support its primary use case: payments and Organizational Digital Identity (ODI). Integrating payment functionalities into the EU Digital Identity Wallet aims to facilitate secure e-commerce transactions, while ODI provides assurance regarding the authenticity of organizations, thereby preventing fraud [26].

As of December 2024, the EU Digital Identity Wallet Consortium has made significant strides in advancing the European Digital Identity Wallet initiative. The consortium convened its fourth General Assembly in Madrid, with over 120 participants, including representatives from the European Commission and the Minister of Digitalization for the Madrid region. The assembly focused on showcasing the latest developments within the consortium and outlining forthcoming steps for 2025 [27].

2.4.3. NOBID Consortium

A third initiative, the NOBID Consortium, focuses on integrating the EU Digital Identity Wallet into electronic payment authorization processes for products and services used by citizens. Launched in September 2022, the consortium brings together six countries, Denmark, Germany, Iceland, Italy, Latvia, and Norway, along with key industry players such as Intesi Group, Thales, Signicat, and InfoCert. Planned to be implemented from 2023 through 2025, the project aims to enable the seamless use of the EUDI Wallet in the digital payments processes, advancing both cross-border usability and secure identity verification in the financial domain. The project aims to build upon the current payment infrastructure to facilitate the issuance and acceptance of payments, enabling instant transactions and account-to-account transfers.

The services developed within the project are designed to support the main use case, enabling cross-border payments using the EUDI Wallet. This represents an important step forward, with one of the potential future extensions being integration with the Digital Euro. The solutions proposed by the consortium aim to improve customer authentication beyond what is currently offered by traditional payment systems. In this model, each payment request is initiated by the intended recipient, whether a merchant or an individual, and multiple authentication methods will be supported, including QR codes, push notifications, and deep linking.

For the project’s evaluation, some of the metrics that will be considered include the following:

• The total number of wallet users participating in the project;
• The number of countries issuing wallets that are involved in the project;
• The count of wallet transactions completed in a pre-production environment;
• The number of issuers of Electronic Attestations (EAs), Qualified Electronic Attestations (QEAs), and credentials that have integrated interfaces with the wallet within their pre-production systems [3].

2.4.4. Digital Credentials for Europe (DC4EU)

The fourth pilot project, Digital Credentials for Europe (DC4EU), aims to provide tangible support to both the public and private sectors, with a particular focus on education and social security. It achieves this by deploying cutting-edge, interoperable digital service infrastructures that span across EU Member States. DC4EU brings together 22 EU Member States, as well as Norway, Ukraine, and Switzerland. The initiative involves 99 key institutions from 25 countries, with strong support from both the public and private sectors.

The project follows a well-defined timeline, beginning on 1 April 2023, with the initial phase, and concluding on 15 April 2025, with the final events marking its closure. Key milestones include the launch of the first large-scale pilot scenario on 1 June 2024, the rollout of all user journeys on 29 February 2025, and the completion of the DC4EU large-scale pilots by 1 April 2025.

One of the project’s objectives is to provide users with complete control over their personal data and the information they want to share with various institutions and organizations, ensuring a high level of security and cross-border recognition. DC4EU will focus on identifying and implementing these elements in the education field, especially regarding the issuance of academic credentials and recognized qualifications. In addition, this will drive innovation in educational identification standards, supporting the transition from traditional identification methods to a secure and trusted digital identity system. In the social security sector, the project addresses both legal and operational aspects by facilitating the coordination of social security systems. It plays a key role in the implementation of portable documents such as the A1 certificate and the European Health Insurance Card (EHIC), ensuring seamless cross-border healthcare access across EU Member States [8].

2.5. Overview of European Providers

The revised eIDAS 2.0 regulation and the introduction of the European Digital Identity (EUDI) Wallet aim to transform digital identity across the EU. Several European companies are building wallet, credential, and infrastructure solutions that comply with the evolving standards [2]. This section highlights the most prominent solution providers based on technical maturity and domain relevance.

Namirial: A Qualified Trust Service Provider (QTSP) offering a live wallet-centric platform designed to integrate trust services into the EUDI ecosystem. It enables issuance and verification of credentials, qualified e-signatures, and secure onboarding across sectors. Namirial’s system is already applied in pilot deployments under the POTENTIAL project, ensuring compliance with eIDAS and the Common Toolbox [28].

Signicat: An established digital identity provider offering wallet integration, verifiable credential issuance, and user authentication services. Signicat is part of the WE BUILD pilot and has a long-standing footprint in identity verification for finance and e-government. Its focus is on enabling both consumer and organizational identities in the EUDI framework, with mature APIs and onboarding solutions [29].

InfoCert: Developer of the DIZME wallet, which bridges Aelf-Sovereign Identity (SSI) architecture with eIDAS-compliant trust services. The platform supports legally binding credential exchange and was built to work with enterprise and educational sector use cases. InfoCert participates in EU-level identity pilots and offers decentralized identity solutions compatible with national eID programs [30].

itsme: A production-level mobile identity app widely adopted in Belgium, offering authentication, identification, and qualified electronic signatures. itsme complies with eIDAS and is now being scaled across EU use cases via the WE BUILD consortium. It is valued for its user-friendly interface and deep integration into both banking and public service infrastructures [31].

Lissi: Specializes in wallet technology and API services focused on cross-border interoperability. It offers an EUDI Wallet beta implementation and works with partners like Italy’s Maggioli to ensure public service compatibility. Lissi supports European credential standards and aims to connect existing digital ID schemes with the new EUDI architecture [20].

Izertis: Contributor to EBSI and provider of the open-source IdentiFY wallet. The wallet is designed to store and manage digital credentials in compliance with EU trust frameworks. It is being used in WE BUILD pilots to test company registration, public service access, and personal credential portability in decentralized systems [32].

Thales: Offers a comprehensive mobile identity wallet solution, already deployed in several national ID programs. Thales’s platform supports in-person and online credential presentation, biometrics, and secure storage of sensitive attributes like travel and healthcare documents. It is aligned with EUDI Wallet specifications and supports eIDAS-compliant services at scale [33].

wal.id: Provides a full suite of open-source tools and SDKs to enable verifiable credential issuance, wallet implementation, and infrastructure integration. The company’s offerings are widely adopted in government and educational settings through the EBSI ecosystem. walt.id is often chosen by developers and agencies aiming for modular and interoperable digital ID systems [34].

Table 1 presents a brief overview of the main companies providing trust services related to EUDI Wallet framework.

Table 1. Overview of European EUDI Wallet-related solutions.

Company	Country	Maturity	Main Service	Sector Focus
Namirial	Italy	Live	Wallet platform, QTSP	Gov, Finance
Signicat	Norway	Live	Credential issuing, auth	Finance, Business
InfoCert	Italy	Pilot	SSI wallet + trust svc	Enterprise, Edu
itsme	Belgium	Live	Mobile ID app	Gov, Finance
Lissi	Germany	Beta	Wallet + APIs	Gov (local)
Izertis	Spain	Pilot	SSI wallet (IdentiFY)	Gov, Business
Thales	France	Live	Mobile eID wallet	Gov, Travel
walt.id	Austria	SDKs	Infra tools, open-source	Edu, Health, Gov

The European market for EUDI Wallet-related services is diverse and advancing rapidly. Technically mature providers like Signicat, itsme, and Namirial already support real-world applications, while others contribute innovative components through ongoing pilots. Each brings unique strengths aligned with sectoral needs and the shared goal of a secure, interoperable digital identity ecosystem across Europe.

2.6. QEAA Maturity

One of the major challenges encountered in the integration of the EUDI Wallet within proposed projects and applications is the limited maturity of Qualified Electronic Attestations of Attributes (QEAA). The absence of clearly defined and fully adopted standards for this type of attestation complicates the implementation processes. Currently, the standardization and legal frameworks for QEAA are not yet fully defined or adopted, requiring further refinement and alignment at the European level.

Qualified Electronic Attestations of Attributes (QEAA) were introduced as part of the eIDAS 2.0 Regulation [2] to address various digital identity use-cases. These attestations serve as a key component of the European Digital Identity Framework, designed to complement electronic identities (eIDs) by enabling the provision of verifiable personal attributes without requiring the disclosure of the user’s full identity. Another theoretical framework that provides the necessary perspective for the development and implementation is the ARF (Architecture and Reference Framework) [9] component from the EUDI Wallet Toolbox. This is not a regulatory document and outlines technical requirements rather than the legislative ones. However, the regulations are shaped by the insights and advancements derived from the ARF.

The EUDI Wallet will be issued by EU Member States, which also have the responsibility to define which information can be stored and how it will be used in accordance with national laws. Therefore, in the initial years of use, without a unified EU-wide security standard, but only national security certification schemes, different levels of security may arise between Member States and the way they interact with this digital wallet. However, regardless of national laws, each state must ensure that interactions with the digital wallet comply with GDPR [35].

By 2026, all 27 EU Member States will be required to provide their citizens and residents with an EUDI Wallet, although this does not mandate that citizens must use only this wallet for accessing all services or processes offered by organizations or companies. Therefore, it will be up to each individual to decide whether or not to use the digital wallet for accessing specific services. Currently, work is ongoing to develop and continuously harmonize these standards and regulations to ensure the interoperability and security of the EUDI Wallet across the European Union [11].

3. Privacy Concerns

The most impact on user privacy in the ARF context manifests itself in the revocation step. In short, the main problem is the usage of a static revocation index.

3.1. Standard Revocation Mechanism

Another key mechanism in the context of integrating the EUDI Wallet into various workflows is the status verification process for a given PID (Personal Identification Data) or an attestation. A PID refers to the core identity information that uniquely identifies a person. It is issued by a PID Provider, typically an official authority such as a government agency. This data is usually protected and not fully shared with a Relying Party. Instead, it is selectively disclosed through attestations. An attestation is a digitally signed statement that confirms a specific attribute of a person, based on the PID or Attestation Provider. These attestations are purpose-specific and selective, meaning that the user has full control over which attributes are shared, depending on the context.

The Relying Party (RP) component is integrated with the EUDI Wallet, which grants it access to the necessary user attributes for validating and completing a specific process or transaction. When an RP needs to verify the validity of a given attestation (e.g., to ensure it has not been revoked), it must consult a status list or a revocation list. This typically involves contacting a server operated by the corresponding PID or Attestation Provider. The attestation must include revocation-related metadata, such as a URL pointing to the location of the status or revocation list, along with an identifier or index that allows the RP to locate the specific entry related to the attestation.

The status verification process takes place locally on the RP side, based on one of the following two lists:

• Attestation Status List (ASL): This is a bit string in which each bit (or group of bits) corresponds to a specific attestation. The value at the designated index indicates the current status of the attestation (active, suspended, or revoked);
• Attestation Revocation List (ARL): This is a list of PID identifiers or attestation identifiers that have been revoked by the PID Provider or Attestation Provider. Once downloaded locally by the RP, the list is searched to check whether or not the identifier included in the attestation appears there. If the identifier is found, the attestation is considered revoked [9].

In both mechanisms, the verification of an attestation status relies on the local download of a verification list provided by the RP. One key advantage of using a status list over a revocation list is improved efficiency in processing and verification. A revocation list may contain a large number of entries, which requires a complete search to check whether or not the attestation’s identifier has been revoked. On the other hand, a status list allows for direct, index-based access, enabling faster lookups and more efficient processing.

This verification process is designed to ensure key security properties such as confidentiality, integrity, authenticity, and the non-repudiation of data. Data confidentiality is maintained through the fact that the RP downloads the status or revocation list locally, without sending any information about the attestation/PID being verified to the Attestation or PID Provider. If this verification were to take place on the provider’s side, it could introduce significant privacy risks, such as user tracking or profiling. By leveraging these privacy-preserving status and revocation lists, the server remains unaware of which credential is being verified and cannot associate the request with any specific user. This ensures that individuals maintain their anonymity and digital privacy throughout the verification process.

Properties such as data integrity, authenticity, and non-repudiation are ensured through the implementation of a digital signature mechanism applied to the status or revocation lists. These lists are digitally signed by the PID Provider or Attestation Provider using their associated private keys, and the signature is verified by the Relying Party using the corresponding public key. The signature can be embedded either in the file header or within a separate section of the list. This mechanism guarantees that the list originates from a trusted provider and has not been tampered with by an attacker during transmission.

Regarding the update frequency of these lists and their digital signatures, each time a list is modified, a new version is created that incorporates the changes and is digitally re-signed. Some providers may publish incremental lists (e.g., only differences compared to the previous version), which are also signed to maintain trustworthiness.

3.2. Open-Source Implementation Details

The EUDI Wallet provides a robust solution for managing digital identities, prioritizing security and privacy. It enables seamless integration into various processes, giving users the ability to selectively share specific attributes. With its privacy mechanisms, users maintain full control over their personal data, ensuring enhanced protection in digital interactions. Each individual will have a set of attributes and documents stored in their wallet, such as a digital ID, driver’s license, or bus/train ticket, which will remain private and visible only to the individual. Moreover, the process of sharing these documents with various organizations or institutions to access specific services will be carried out privately. Even the issuers of those documents will not be notified when or with whom the documents are shared. In essence, the transactions in which these documents are used will remain confidential.

A potential barrier to the widespread adoption of the EUDI Wallet could be individuals’ reluctance to have a digital identity that contains most of their personal information and documents issued by various public institutions, as well as universities. Possible concerns among users regarding the use of the EUDI Wallet might include the following:

• The risk of their information being collected by different organizations or institutions without their consent;
• The potential for the wallet to be breached by attackers, given its exposure in the digital environment;
• The fear of losing anonymity in digital interactions.

The tracking of operations and transactions will be limited through the legal framework established by the European Digital Identity Framework. All data associated with an individual’s account will be stored locally in the wallet, certified for cybersecurity, and the source code will be open-source, providing a high level of transparency. There will also be mechanisms for data deletion upon request, as well as the ability to suspend wallets in case of a potential compromise. Two key mechanisms that underpin the integration of the EU Wallet in digital identification workflows are data minimization and zero-knowledge proof. Data minimization is the process through which any service provider should collect only the minimal amount of information necessary to provide its functionalities to the user. This also forms the basis of the selective disclosure of attributes functionality, which allows users to share only specific information with a service provider, without disclosing any additional data. Zero-knowledge proof is a mechanism through which an attribute of a person can be verified without disclosing any additional information. For example, it is possible to verify if a person is 18 years old or older without revealing their exact date of birth or their full age.

The EU Digital Wallet ensures unobservability by keeping your actions completely private and invisible online. Unlike anonymity, which only hides your identity but allows your actions to be visible, unobservability means that no data is collected regarding how you use your wallet, ensuring complete privacy of your online activities. Providers of credentials and digital documents (issuers of Qualified Electronic Attestations of Attributes) will undergo audits every two years to verify that appropriate security measures are in place to mitigate all potential risks. Furthermore, to protect data confidentiality, advanced encryption systems and multi-factor authentication are integrated.

In the current form of the ARF, the user’s privacy is assured from the Issuer’s perspective. The responsibility of the Issuer is to publish the RL in a public repository. Since the actual validation is done on the Verifier’s premises, Issuers cannot learn what VCs were verified. However, since the revocation index is stored in the VC and then in the VP, the Verifier would receive the same static index for the same VC of a user. This leads to breaking unlinkability, therefore, breaking privacy.

3.3. CRL Issuer

Adopting a CRL-like solution similar to the ones PKI uses represents a privacy violation, since the CRL publishes a static serial number of the revoked certificate. Each time a verifier needs to check if a VC received via a VP is revoked or not, it would need to check for the same static value. Therefore, Verifiers can do user profiling using the static identifier. In this work, we propose a version of the Revocation List aiming to ensure privacy for the user by presenting a randomized index each day.

3.4. OSCP Responder

In the context of Verifiable Credentials and the ARF [3], implementing a solution similar to an OCSP Responder is definitely not accepted. In this protocol, the Verifier would need to call a service maintained by the Issuer, sending the revocation ID or serial number of the VC, and then receive the status. In this workflow, the Issuer would be able to violate user privacy since they know the ID of the VC and also who tries to verify it. For example, an Issuer could track and see that the user x visited hospital y and pharmacy z in the last week.

3.5. Literature Overview on Privacy-Aware Verifiable Credentials

Regarding the verification mechanism for Verifiable Credentials (VCs), a commonly used method is to leverage a Bitstring Status List. This method offers limited privacy protection, as it can expose patterns of issuer behavior, potentially disclosing sensitive information. The CRSet solution [36] introduces a revocation model that uses Bloom filters generated periodically, which are compact data structures that use probability to efficiently store revoked credential IDs. These filters correspond to fixed time intervals and are published on the Ethereum network. This design allows verifiers to independently and locally verify the revocation status of a credential without requiring communication with the issuer or disclosing which credential is being checked. Because it does not require interaction with the issuer during the verification process, the proposed solution’s design helps to keep metadata private, making it much harder to track how credentials are being checked.

However, CRSet is not without limitations. One possible concern with the proposed solution is its dependence on a fixed index for organizing Bloom filters and processing revocations. Using the same index over extended periods of time could allow third parties or attackers to monitor and analyze patterns in credential revocation processes. This could lead to the identification of repetitive patterns or the linking of certain Verifiable Credentials (VCs). Such indirect connections may compromise user anonymity and cause minor metadata leaks. As the number of revoked credentials grows, the Bloom filters associated with the same index may become overloaded. Introducing periodic updates to index mappings or using adaptive mechanisms can lead to improvements regarding privacy. Another challenge is the unpredictable fluctuation of ETH-based operational costs, which can create a major financial obstacle to the wider adoption of this solution, given the current state of the network.

The W3C’s proposed Verifiable Credentials Data Model [10] stands as a suitable design for issuing and presenting user attributes. On the other hand, when confronting the revocation process, privacy-preserving and tamper-evident issues arise untreated. In the work of Xu et al. [37], before introducing their confidentiality-protected and tamper-evident efficient solution, several systems that implement similar mechanisms are analyzed, with their limitations being highlighted. OpenAttestation and Veramo rely on smart contracts and static identifiers (e.g., certificate ID and credential hashes), which leak secrecy by enabling correlation between presentations. Because of its join–revoke linkability and usage of a CKS accumulator, Sovrin makes it possible for adversaries to monitor the dates of credential issuance and revocation. IRMA employs a CL-RSA-B accumulator for privacy but depends on a centralized server, making it susceptible to Single-Point-of-Failure (SPOF) vulnerabilities like tampering or downtime. Gravity and Verifiable-Credential-Java leverage Revocation List 2020, a bitstring-based approach that compromises unlinkability by exposing revocation indexes.

All the solutions briefly described above are summarized in Table 1 of the paper, as mentioned above. By avoiding static identifiers, their system eliminates correlation risks, guarantees revocation integrity through blockchain immutability, and offers efficiency through constant-time proof generation and verification. Three core components help to fulfill the requirements for a tamper-evident and privacy-preserving revocation mechanism:

• An efficient bilinear pairing-based accumulator uses dynamic revocation management to provide zero-knowledge proofs of membership without revealing credential identifiers;
• During credential presentations, BBS+ signatures ensure privacy and unforgeability while permitting selective disclosure of claims [38];
• A role-based blockchain (the public permissioned HyperLedger Indy network) serves as an immutable ledger for revocation updates, ensuring only authorized issuers can alter revocation statuses while preventing manipulation from adversaries.

While the previously mentioned solution advances privacy and tamper-evidence in Verifiable Credentials, its non-standard cryptographic methods (i.e., its proposed accumulator and BBS+ signature, which are not currently explicitly supported in EUDI specifications) and dependency on a role-based blockchain deviate from ARF’s interoperability. Moreover, its implementation should be upgraded to comply with the latest version of Verifiable Credentials Data Model v2.0. For now, the proposal is better suited for niche, high-privacy applications rather than broad EUDI Wallet adoption.

Another proposed approach [39] is based on the use of a Merkle tree-based accumulator to manage the revocation of credentials in decentralized identity systems. The proposed approach aims to maintain a balance between efficiency and user privacy, enabling the generation of validity proofs without compromising anonymity. The mechanism organizes credentials into multiple subsets, defined by a specific parameter, and associates each credential with a secret known only to the issuer and the holder. Each subset is periodically updated with a public nonce, and the valid credentials are represented and published alongside the Merkle tree root in a publicly accessible repository. Holders can locally generate inclusion proofs, which verifiers can authenticate using only public data. Ethereum smart contracts are used to keep revocation data trustworthy and accessible, with minimal blockchain storage required. The solution is compatible with both traditional Identity Management Systems (IDMSs) and blockchain-based architectures such as Self-Sovereign Identity (SSI).

4. Proposed Protocol

Revocation Lists were proposed so that the Issuer could be decoupled from the revocation checking process. The Issuer only needs to publish a Revocation List, and then the validation process is performed offline by the Verifier. This approach provides an elegant solution for enforcing user privacy from the Issuer’s perspective. Still, when one needs to ensure the same level of privacy, but against the Verifier, this approach does not work. Our main concern is that, by using the same revocation ID every time, for a specific verifiable credential, the Verifier could easily perform user profiling. Hence, our approach is centered around providing unlinkability.

4.1. Security Properties

• Selective disclosure—The Wallet needs to construct the Verifiable Presentation using the Verifiable Credential received from the Issuer. In this step, selective disclosure is desired so that users do not divulge unnecessary information to the Verifier/Relying Party. This is achieved by using BBS+ signatures. This process impacts multiple stages: issuance, validation, and preparing the verifiable presentation. However, this approach is not new and is already used in different established solutions.
• Unlinkability—Privacy and unlinkability is already achieved by the ARF, using the RL2020 published by the Issuer. However, the main goal of our protocol is to achieve unlinkability from the Verifier’s standpoint. This is a much harder problem since the Wallet needs to prove something to the Verifier while maintaining privacy at the same time.
• Integrity—Integrity has to be assured for different elements in the protocol, for example, the Verifiable Credential, the Verifiable Presentation, and the Revocation List. In our case, the VC and VP are signed using a BBS+ signature scheme. The Randomized Revocation List is protected via two measures: a digital signature by the Issuer and distributed storage on blockchain.
• Privacy against static revocation index—In short, the main idea of our proposal is to provide, in the VP, a randomized index that would change daily. The Verifier would use the randomized index and check in the randomized Revocation List if the credential was revoked or not. In the following sections, we present in detail how the proposed protocol works.

4.2. Protocol Phases

In the current section, we detail the proposed protocol, which contains Setup Algorithm 1, VC issuance Algorithm 2, revocation list randomization Algorithm 3, VP preparation Algorithm 4, verifiable presentation generation, and finally verifiable presentation validation Algorithm 5.

4.2.1. Setup

Similar to [36], our Revocation List is in fact a cascade of Bloom filters. However, we use the RL slightly differently, as explained in Section 4.2.5. Therefore, the overall dimension of the RL is variable, but is a multiple of dimension $2^{20}$. Creation of a similar cascaded Bloom filter is described in [40].

For revocation information, the issuer keeps track of all revoked credentials using an internal database of choice. Also, the issuer chooses the elliptic curve, groups, and bilinear map, and finally generates the key pair. The secret key is further used for signing verifiable credentials in the issuing process.

Algorithm 1: Setup Phase (Issuer)

Input: Security parameter $\lambda$

Output: Issuer key pair and initialized RL structure

Issuer generates $(pk,sk)\leftarrow \mathrm{KeyGen}\left(\lambda \right);$

Issuer initializes a local revocation list $RL;$

Issuer publishes $pk$;

4.2.2. VC Issuance (Issuer)

Whenever an Issuer issues a new VC ($V{C}_x$), it uses the BBS+ scheme and produces a signature ($\sigma$) over the actual attributes (e.g., ‘name’ = ‘joe’, ‘age’ = ‘25’, etc.) together with a revocation index ($i_0$).

Algorithm 2: VC Issuance

Input: Attributes $attr$, secret key $sk$

Output: Signed VC with hidden values

Issuer selects random value $r_0\in \mathbb{Z};$

Issuer constructs $M=(attr,r_0);$

$\sigma \leftarrow \mathrm{BBS}+.\mathrm{Sign}(sk,M);$

Issuer sends $(VC=\{\sigma ,attr\},r_0)$ to Wallet;

Issuer stores $r_0$, associate to $VC$;

4.2.3. Revocation List Randomization

Instead of publishing the actual RL, the Issuer publishes a randomized version of the RL each day (RRL—Randomized Revocation List). For this, each index is randomized using the function $r_{lt}=Trun{c}_{bfsize}\left(Hash(Hash(r_0,t),level)\right)$.    

Algorithm 3: Randomized Revocation List Generation (Issuer)

4.2.4. VP Preparation

In this step, two main operations are involved: selecting the disclosed attributes by hiding the ones that are not of interest and computing the randomized revocation index. In this exact scenario, if a malicious Wallet could search in the RL for a non-revoked index and send it to the Verifier. This is the reason the Wallet creates a proof (ZKP) that $r_t$ is indeed obtained by $Hash\left(r\right|\left|t\right)$.    

Algorithm 4: VP Preparation (Wallet)

Input: VC $\{\sigma ,attr\}$, r, epoch t

Output: Verifiable Presentation with proof

$Claims\leftarrow$ Selected attributes to disclose by Wallet;

Compute $r_t\leftarrow Hash\left(r\right|\left|t\right));$

Compute ZKP for $r_t$ correctness:

${\pi }_r=$ZKPoK[$r,\sigma :\mathrm{BBS}+.\mathrm{Sig}(\dots )\wedge r_t=\mathrm{Hash}\left(r\right|\left|t\right)$]

Compute ZKP for $Claims$ correctness:

${\pi }_{vc}=$ZKPoK[$\sigma ,\mathtt{hidden}\mathtt{attributes}:\mathrm{BBS}+.\mathrm{Sig}(\mathtt{Claims}\cup \mathtt{hidden}\mathtt{attributes})$]

Package and send VP $\leftarrow \{Claims,{\pi }_{vc},r_t,{\pi }_r\};$

4.2.5. VP Validation (Verifier)

After receiving the VP, the Verifier carries out multiple checks on it. In Algorithm 5, only the relevant validations performed were introduced, such as proof of verification and, most importantly, the revocation verification. Of course, besides these few checks, the Verifier needs to verify if the RL is correctly signed by the issuer, if the Issuer is a trustworthy TSP, etc.    

Algorithm 5: VP Validation (Verifier)

4.3. Limitations

While the proposed protocol successfully enhances user privacy through daily randomized revocation indices and unlinkability guarantees, several limitations and practical considerations must be acknowledged:

• Randomization Interval—The main limitation of the proposed protocol is the randomization interval. Usually, in a practical implementation, the RRL would be generated once or twice a day;
• Verifier–Issuer Collusion—Since the $r_0$ parameter is known to the Issuer and the Wallet, the Issuer could collude with the Verifier to obtain a constant revocation index. This would break unlinkability property. However, this concern falls outside the EUDI Wallet’s threat model because the architecture deliberately decouples these entities, and such collusion would require qualified trust services to engage in criminal conspiracy that violates their regulatory obligations, risks their operational licenses, and triggers severe legal penalties;
• Revocation List Synchronization—Since the revocation index is constantly changing, credentials are validated against a specific version of the RL. This comes with a Revocation List synchronization burden;
• Expanding Bloom Filter—With the number of revoked credentials, the number of collisions also grows. This would cause an expansion of the cascaded Bloom filter;
• Cryptographic compatibility of BBS+ signatures—BBS+ and BBS# signatures are not explicitly defined in the ARF specification [3], but they are compatible with its design principles. The ARF does not limit algorithm choices, it just enforces proper security properties. The ARF supports the use of selective disclosure mechanisms (e.g., via Data Integrity proofs), which allows for the integration of BBS+ signatures. However, to the best of our knowledge, most ARF-compliant Wallet providers have not yet implemented BBS+ support.
• Cryptographic compatibility of RRL—Regarding revocation, our use of dynamic revocation indices aligns with the guidance in Annex 2 of the ARF [41], which discusses rotating and non-deterministic identifiers. Nevertheless, our specific approach—representing dynamic indices via a cascaded Bloom filter—introduces a non-standard structure. This would require an extension to the existing revocation formats defined in ARF to ensure interoperability across Wallet implementations.
• EUDI Wallet Interoperability—Even though our implementation adheres to the standardized interfaces and protocols defined in ARF, we take into consideration, as a further research direction, verifying the compatibility with third-party Wallet implementations, like those enumerated in Section 2.3.1.

4.3.1. Cascade False-Positive Rate and Storage Efficiency

In practical terms, revocation rates are bounded by an upper limit of 0.5% [42]. Our reference in terms of cascaded Bloom filters, CRLite [40] is considered efficient until a 2% revocation rate. CRSet [36] uses the same approach and is oriented towards verifiable credentials, instead of classical PKI certificates.

To address potential Bloom filter collisions at realistic revocation rates, we add an analytic evaluation of the cascade’s false-positive probability and depth. From standard Bloom filter theory, the false-positive rate p for a single Bloom filter with n inserted items, m bits, and k hash functions is $p\approx {(1-e^{-kn/m})}^k$. Using this result, we bound the overall cascade false-positive probability and derive the expected number of layers L needed. In a Bloom filter cascade, each subsequent layer stores the false positives of the previous layer, ensuring that, at the final layer, there are no false positives.

The probability that a non-revoked credential passes all L layers is about $p^L$; setting L such that $p^L·N\ll 1$ (where N is the total number of credentials) makes the chance of any false positive extremely small. For example, at a 5% revocation rate (i.e., 5% of credentials are listed in the Bloom filter), a first-layer filter tuned to $p\approx 1\%$ would flag about 1% of valid certificates as false positives. A second-layer filter on this  1% subset would reduce the overall false-positive rate to  ${10}^{-4}$, and a third layer to  ${10}^{-6}$—effectively eliminating errors in practice. Prior work supports the practicality of this approach: the CRLite system [40] achieves zero false positives while remaining compact.

CRLite can represent the revocation status of 30 million certificates (with  8% revoked) in about 10 MB of data. More recent Mozilla real-life data shows a cascade encoding  175 million certificate statuses in just 6.8 MB, updated four times daily [43].

These results demonstrate that, even at high revocation fractions, the cascade remains efficient: collisions have only a minor effect on performance, and the false-positive rate stays bounded by design. We used these assumptions in our Randomized Revocation List (RRL) design, since they proved their performance in real-life implementations, even with a high rate of revoked elements (5–8%).

4.3.2. ZKP Efficiency

Our protocol generates two non-interactive Zero-Knowledge Proofs (ZKPs) per Verifiable Presentation: one for selective disclosure (using BBS+ signatures), and one for revocation index correctness. Though we did not have the chance of profiling the proof generation yet, existing benchmarks suggest this is viable in constrained environments.

A recent Zenroom benchmark on a 6-core Intel i7 (3.4 GHz) records BBS proof generation at  8–9 ms and verification at  19 ms, with proofs of  272 bytes in size [44]. This suggests that BBS-based ZKPs are inherently fast. With typical performance scaling, we expect mobile hardware to generate proofs in tens of milliseconds. The revocation index proof, by contrast, involves only a hash and a range proof (constant size), and thus is expected to execute even faster.

More research for benchmarking these ZKPs in a wallet prototype on Android and ARM-based platforms would be valuable. Although not definitive, from existing data we believe proof generation is unlikely to be a bottleneck for wallets deployed on modern mobile devices.

4.4. Comparative Analysis

Our revocation mechanism builds on existing structures such as CRSet [36] and CRLite [40], which encode revocation sets using efficient public representations (Merkle trees and Bloom filters, respectively). However, unlike these systems, we introduce daily randomized revocation indices to break linkability and mitigate metadata leakage.

CRSet uses fixed indices tied to credential identifiers. While efficient, this leaks metadata over time and enables tracking across verifications. In contrast, our design derives each index from a secret and the current time epoch: $r_t=\mathrm{Hash}(r_0\parallel t)$. This ensures that revocation identifiers change daily and cannot be linked across sessions, even by colluding verifiers. For efficient verification, we adopt a cascaded Bloom filter structure similar to CRLite, but encode daily indices rather than static ones.

Finally, our approach is agnostic to the underlying storage ledger. While CRSet incurs gas costs due to Ethereum smart contract updates, our design can be integrated into any append-only ledger, including permissioned or decentralized systems, without reliance on a specific blockchain. This hybrid of randomized indices and Bloom-based encoding improves unlinkability and scalability, making the approach suitable for EUDI Wallets and other privacy-sensitive identity ecosystems.

5. Implemented Solution

The current section describes the implemented solution. We detail the overall architecture, how the components interact with each other, limitations, and experimental results.

5.1. Overall Architecture

Our implementation is compliant with the ARF proposed architecture. As noticed in Figure 1, the main additions are the blockchain component, which stores the (Randomized) Revocation List, and the hardware token that manages the private key of the Issuer.

Figure 1. ARF compliant architecture.

The Authentic Source is used for storing the initial information. For example, this component could be a university holding information about students’ degrees. The Authentic Sources interacts with the Issuer using a variation of OAuth 2.0, namely OpenID4VCI. We opted for Keycloak since it is one of the most supported open-source identity management solutions; it is scalable in terms of functionalities and is already spread worldwide.

The Verifier is a Java application, deployed via Docker containers. One important characteristic is that the Verifying Service is highly configurable via toggle flags. Any Relying Party would be able to use this service and tailor it to their needs.

The Wallet used is actually the reference EUDI Wallet. Note that this project is updated at a high pace, and in certain situations breaking changes may occur. The reason for using the reference implementation is obvious: interoperability with various Issuers and Verifiers.

The Issuer acts as an orchestrator between most of the components. Forking the reference implementation of the Issuer role, we implemented some additions: hardware token integration for secure private key management, custom Revocation List generation, and publication of the Revocation List on the blockchain network.

The public repository is the place where the Revocation List is securely distributed. Its main purpose is to decouple the Issuer from the validation process. Another benefit is the immutability, even though the RRL published is already signed by the Issuer. This design enhances transparency and trust without introducing centralized dependencies. For a more efficient implementation, we use IPFS for the actual storage of the Revocation List.

5.2. Components Interaction

Figure 2 presents the overall flow that takes place whenever a user interacts with a Relying Party. The prepared VP needs to be validated by the Verifying Service. Among the performed validations, we could list the following: attribute schema compliance, signature integrity, issuer trustworthiness, etc.

Figure 2. VP validation flow.

5.3. Blockchain-Based Publication of the RRL

Inspired by CRSet [36], our implementation adopts a decentralized publishing model that ensures integrity and verifiability of the revocation list (RRL). Specifically, we construct a Bloom filter cascade every 24 h using a Python-based publisher module. The resulting data structure is stored off-chain on the InterPlanetary File System (IPFS), while its reference is anchored on-chain using a smart contract deployed on the Ethereum Holesky Testnet.

The on-chain component consists of a smart contract that exposes two core methods:

• publishCRL(string CID, uint256 validityHours): Called by the issuer to publish a new RRL. It records the IPFS Content Identifier (CID) and sets a validity period, typically 24 h.
• getCRL(address issuer): Queried by verifiers to retrieve the latest valid CID for a given issuer address, along with metadata such as expiration time and version.

This hybrid design obtains the immutability and auditability of blockchain for referencing, while avoiding high on-chain storage costs by keeping the Bloom filter data in IPFS. Each credential includes the issuer’s blockchain address and the smart contract address, enabling verifiers to retrieve the latest RRL without reliance on centralized endpoints.

Using the smart contract provides critical functionality beyond simple content addressing. Since IPFS CIDs are content-derived and change with every update, embedding them directly in credentials would cause them to expire when the RRL is updated. The smart contract solves this by acting as a stable pointer to the most recent RRL version, preserving credential validity across update cycles.

In terms of resource usage, calling publishCRL consumes approximately 57,695 gas units. This cost is independent of the RRL size, as only the CID is recorded on-chain. In contrast, getCRL is a view method and can be invoked via RPC without generating a transaction, which not only avoids gas fees but also leaves no trace on-chain—preserving verifier privacy. This architecture aligns with the goals of unlinkable, efficient, and scalable revocation by combining decentralized publication with minimal verifier observability.

5.4. Results

The main result of this proposal is the actual protocol designed for unlinkability. However, storing the Revocation List on the blockchain might introduce a set of challenges regarding system performance. For this reason, we designed a simple experiment to better understand the performance penalties when using our RRL approach with the blockchain and IPFS.

We considered a revocation list able to hold 10 million users, and from 1% up to 15% of total credentials are randomly revoked. We performed at least 100 validations for each scenario, and have included the averages in Table 2.

Table 2. Time for VP validation.

	In IPFS as Cascade (ms)	On Issuer as JWT (ms)	Revocation Ratio
Cached	31.02	10.03	15%
Not cached	621.5	138.96
Cached	32.18	9.43	10%
Not cached	615.57	142.03
Cached	31.3	9.3	5%
Not cached	614.62	137.86
Cached	31.42	6.9	1%
Not cached	618.8	131.71

The blockchain + IPFS alternative has been compared with an implementation following the guidelines indicated by ASL and ARL specifications highlighted by ARF: a revocation list containing 10 million bits, stored on a web server. This experimental setup was chosen to emphasize the performance penalties raised from using our approach instead of the classical one.

The results point out the lack of a strong correlation between the revocation ratio and the time required for a validation, the time differences being in the order of milliseconds. Furthermore, the Web3-based approach makes the validation slower. The slowdown comes mainly from the deserialization process the information obtained from the IPFS needs to go through to become usable.

The measured validation times for the cascaded Bloom filter approach show minimal variation across different revocation ratios, particularly in the non-cached scenarios. This stability can be attributed to the nature of the cascaded structure: most credential validations are resolved at the first or second layer of the filter, with only a small fraction requiring access to deeper layers. Since the deeper layers are accessed infrequently, their impact on the average validation time remains negligible, even as the revocation list grows. Thus, the consistent average performance reflects the design efficiency of the cascade, which controls false positives early and limits costly lookups in deeper layers.

Even though not cached validation duration is up to 20 times slower than cached validation, this is not a concern since the ARF explicitly states that Verifiers shall cache in the Revocation Lists and not download them for each validation.

6. Conclusions

In this paper, we presented a privacy-preserving revocation framework, with a novel mechanism for Verifiable Credentials in the context of the European Digital Identity Wallet and its Architecture and Reference Framework. We generate a daily randomized revocation list and publish it as a cascaded Bloom filter. Our main objective was to obtain user unlinkability from the Verifier’s perspective, and our protocol is able to achieve this. However, we have the limitation that randomization is done whenever a new Revocation List is published, not at each presentation. We assume this to be a reasonable compromise.

Our experimental evaluation demonstrated the practical viability of the proposed approach through comprehensive performance measurements. The experiments considered a large-scale scenario with 10 million credentials and varying revocation rates ranging from 1% to 15%. The results revealed that the blockchain-based approach, while introducing some overhead compared to traditional centralized solutions, maintains acceptable performance characteristics. For cached revocation lists, the average verification time was approximately 30 ms across all revocation ratios, demonstrating excellent scalability. Even in worst-case scenarios where the revocation list was not cached, verification times remained under one second (averaging 600+ ms), which is suitable for real-world deployments. Notably, the verification time showed minimal correlation with the revocation ratio, with differences of only tens of milliseconds between 1% and 15% revocation rates, proving the robustness of the cascaded Bloom filter design.

The integration of blockchain technology through Ethereum and IPFS provided significant benefits beyond performance considerations. The immutable nature of blockchain storage ensures that published revocation lists cannot be tampered with after publication, while the use of IPFS for actual data storage keeps operational costs manageable. The gas fees for publishing new revocation lists remained constant at approximately 57,695 gas units, as only the Content Identifier (CID) is stored on-chain rather than the full revocation data. This design choice makes the system economically sustainable, even for large-scale deployments with frequent updates.

Although we use a cascaded Bloom filter, by retaining the RL2020 structure mandated by ARF, our proposal delivers verifier-side unlinkability and tamper-evident publication without changing wallet–issuer or wallet–verifier APIs, allowing existing components to interoperate unmodified. This compatibility is crucial for adoption, as it enables Trust Service Providers to integrate the privacy-enhanced revocation mechanism without substantial modifications to their existing infrastructure.

We involved an Ethereum blockchain component for immutability of the randomized revocation list and proved that it does not incur significant delays in the validation process. The distributed ledger provides global auditability without leaking revocation metadata, as verifiers can independently retrieve and verify revocation lists without revealing which specific credentials they are checking. This architecture successfully addresses the privacy concerns present in traditional revocation mechanisms while maintaining the security properties required by the EUDI framework.

Implementation effort of our proposal by Trust Service Providers is low: a fork of the open-source issuer and verifier reference stacks already supports RRL generation.

Looking ahead, we believe that wallet implementers, standardization bodies, and researchers should be involved with priority to find reliable, simple, and secure methods for managing digital identities. The main target is to obtain a privacy-centric yet auditable framework. By obtaining simple, yet secure solutions, the likelihood of standardization grows significantly. Additional work could measure proof-generation performance on mid-range smartphones, explore additional blockchain networks to further reduce the costs, and extend the protocol with attribute-level suspension and delegation features anticipated in upcoming ARF revisions. Moreover, we intend to conduct an extensive interoperability test session to identify specific gaps in compatibility with third-party Wallet providers.

In summary, the proposed framework shows that high-grade privacy and performance are compatible. By combining lightweight cryptography, cascade data structures, and decentralized storage, it delivers a revocation mechanism that is auditable, efficient, and unlinkable—an essential step toward the large-scale, privacy-protecting deployment of Qualified Electronic Attestations in Europe.