We propose an advanced credential validation schema managed by the European Digital Identity (EUDI) Wallet. This new protocol preserves Users' privacy and unlinkability while allowing direct privacy-preserving communication between the Credential Issuer and Credential Verifier. This protocol utilizes Hierarchical Deterministic Key Derivation, a mechanism in which each derived private key is generated in a manner that allows the computation of the corresponding public key without revealing the private key itself. As a result, only the Credential Issuer is capable of generating the corresponding decryption key. The Credential Verifier cannot access the credential without a direct communication with the Credential Issuer. The communication happens without sharing any info related to the Credential Holder and allows the Credential Issuer to count the number of verifications performed by every Credential Verifier. This mechanism enables the development of a pricing policy for credentials and advanced business models that facilitate the efective large-scale adoption of the EUDI Wallet, which we analyze in this study.
eIDAS 2.0 [
To build an interoperable system, the European Commission, through its Architecture and Reference
Framework (ARF) [
To operationalize the vision of eIDAS 2.0 and the ARF, the digital identity ecosystem revolves around
At the core of this framework, there are two foundational technical properties focused on preserving security and privacy of the EUDI Wallet User [1, Article 5a §4 (a) and §16 (a) and (b)], namely selective disclosure and unlinkability. The first means a User shall be able to share only specific attributes from their credential, instead of revealing it in its entirety, ensuring data minimization and enabling them to prove necessary information without exposing unrelated personal data. The latter means that transactions of the same User cannot be linked or traced; there are three forms of unlinkability: it can be with respect to Credential Verifiers , namely they cannot correlate a Wallet Holder’s interactions across diferent services, preventing them from linking activities to build a profile of the Holder; with respect to Credential Issuer, namely they cannot track or identify where and how a Holder presents their credential to Credential Verifiers, preventing them from monitoring the Holder’s activities or
CEUR
ceur-ws.org interactions; finally, with respect to both Credential Verifiers and Credential Issuer, namely this present case guarantees unlinkability even if Credential Verifiers and Credential Issuer collude.
In this document, we introduce an advanced model designed to address key challenges in credential presentation, with a dual focus on preserving User privacy and establishing a foundation for sustainable business models and pricing policies. Our approach ensures User unlinkability while enabling direct, privacy-preserving communication with the Credential Issuer and the Credential Verifier. Furthermore, the lack of a well-defined business model motivates the introduction of a new policy, the pricing policy, associated with the VC issued by the Credential Issuer. When combined with the proposed approach, this will enable the introduction of a sustainable business model. This mechanism allows for credential verification without disclosing any information about the Wallet Holder, counting the number of verifications performed by each Credential Verifier. By incorporating this capability, the model not only strengthens privacy protections but also provides a structured basis for defining diverse credential monetization strategies, facilitating scalable and sustainable adoption of the EUDI Wallet.
The remainder of this paper is structured as follows: Section 2 presents research related to our work. Section 3 presents credential verification background and our extension to the credential validation framework. Section 4 is dedicated to its benefits and in Section 5 and 6 there are limitations and privacy consideration, respectively. The paper concludes with Section 7.
The EUDI Wallet ecosystem is built upon the interaction between the Wallet and various Credential Verifiers. Notably, it places significant emphasis on the process of credential presentation and subsequent verification. The successful execution of this process is contingent upon the orchestration of numerous components, each of which plays a pivotal role in safeguarding the integrity and dependability of the entire ecosystem.
In this context, various specifications for credential formats, credential issuance and presentation have emerged.
Main actors in this ecosystem are: • Credential Issuer: A role an entity can perform by asserting attributes about one or more subjects, creating credentials and transmitting the digital credential to the Wallet Holder. This process is performed using OID4VCI protocol. • (EUDI) Wallet Holder: The user who has control over their EUDI Wallet. The EUDI Wallet grants user full control over their digital credentials, ensuring privacy, security, and ease of use. It provides seamless experience for managing, acquiring and presenting digital credentials. • Credential Verifier : A role an entity performs by receiving one or more digital credentials. This process is performed using OID4VP protocol.
Protocols for issuing and presenting credentials are crucial to ensure secure and interoperable interactions between Credential Issuers, Wallet Holders, and Credential Verifiers. Key protocols include OpenID for Verifiable Credential Issuance ( OID4VCI) and OpenID for Verifiable Presentations ( OID4VP).
OID4VCI [
OID4VP [
To verify that a Digital Credential is valid and has not been suspended or revoked, the ARF [
However, this method fails to meet the privacy and unlinkability requirements mandated by the
eIDAS 2.0 Regulation [
At present, the ARF endorses the OID4VP protocol for credential presentation. However, even if it defines how a Wallet Holder can present credentials to a Credential Verifier in a standardized way, ensuring interoperability across diferent systems, it only addresses the technical aspects of credential presentation.
As documented in [
To achieve unlinkability, [
This work presents an extension to the digital credential validation framework that not only addresses the concerns outlined but also introduces a flexible and comprehensive solution. Furthermore, this advancement enables the development of diverse business models associated with Verifiable Credentials, encompassing issuance, validation, and unrestricted free usage. At present, only issuance and free usage are achievable without the proposed approach.
Our proposal does not require changes to the existing credential issuance process. It is format-agnostic, maintaining compatibility with all available Digital Credential formats.
The concept involves two steps: 1. Refreshing the credential before every presentation, to guarantee the validity without the need for the Credential Verifier to undertake additional controls, except integrity and authenticity of the credential. 2. Cyphered VC: the credentials are encrypted by the Holder’s Wallet using a mechanism described later in this document, before being shared with a Credential Verifier . The Credential Verifier can only access the credential through direct communication with the Credential Issuer. This communication occurs without revealing any information about the Credential Holder and allows the Credential Issuer to count the number of verifications performed by each Credential Verifier.
The concept involves periodically refreshing VCs by communicating directly with the Credential Issuer.
This could be achieved with 2 diferent approaches:
• Linked credentials, as documented in [
This Credential Refreshing could be done when the Wallet starts up, on demand, or before presenting the VC.
Those approaches would apply only to credentials that require refreshing. For example, it would not be useful for static credentials. The Credential Verifiers can implement their own policies based on the type of service provided. For instance, they could accept a VC refreshed within the last N hours, or for more critical services, only accept credentials refreshed at the last minute.
The main benefits are: • No need for complex validation mechanisms: since the VC is refreshed directly from the
Credential Issuer, third parties are not required to validate it. • Flexibility for both Credential Issuers and Credential Verifiers : diferent policies can be implemented based on service type and level of criticality.
Verifiable Credential is encrypted by the User’s Wallet. The Credential Verifier must then contact the Credential Issuer to retrieve the decryption key in order to verify the credential. This adds an additional layer of security by ensuring that the Credential Verifier cannot access the VC directly without authorization from the Credential Issuer.
As previously mentioned, the protocol does not imply any change to the current credential issuance process. The Credential Issuer creates and signs the VC, embedding relevant identity or attribute information for the User (e.g., identity, access rights, etc.). Then the VC is transmitted to the User’s Wallet over a secure channel using TLS.
The proposed method involves encrypting the Verifiable Credential at the time of presentation, leveraging the properties of elliptic curve cryptography. Specifically, the Hierarchical Deterministic (HD) Key Derivation.
In particular, the method takes advantage of the properties of Hierarchical Deterministic structures, where each derived private key is generated in such a way that the corresponding public key can be computed without knowing the private key itself.
When a Wallet initiates the presentation of a Verifiable Credential (which could be in various formats,
such as SD-JWT VC or mdoc), the credential will be encrypted according to the JWE standard [
In order for the Credential Verifier to decrypt the JWE, the Wallet must also send them additional information along with the JWE. This will be forwarded to the Credential Issuer. Upon receiving the necessary information, the Credential Issuer retrieves the cryptographic material using which the Credential Verifier can obtain the VC.
More in detail, the expected flow of messages is listed below, subdivided into eight steps: 1. Wallet sends a request to refresh the VC, as described in the previous section. 2. Credential Issuer sends an updated VC, notifying the Wallet in case the VC is not valid anymore. 3. The Wallet generates a transaction-specific symmetric encryption key K using which it encrypts the verifiable credential VC . The result of the encryption process is denoted here as K(VC). 4. The Wallet generates the JWE of the Verifiable Credential and sand it to the Credential Verifier as follows: The header of the JWE contains, as a plaintext, all of the necessary information for decrypting the body of the JWE itself; this includes: • X: a concatenation between a timestamp and a random nonce generated by the Wallet; • KID: a Key Identifier, needed to identify the correct Credential Issuer and then ask this
Credential Issuer to decrypt CP(K) (see below); • CP(K), i.e. the key K encrypted using an asymmetric public key CP belonging to the
Credential Issuer and derived from a master public key of the same Credential Issuer. The body of the JWE contains K(VC), that is the Verifiable Credential VC encrypted using the symmetric key K (see step 1). At the end, the Wallet sends the JWE and X to the Credential Verifier. 5. The Credential Verifier receives the JWE and sends CP(K) and X to the Credential Issuer , asking the Credential Issuer to use the derived private key linked to X in order to decrypt CP(K); 6. The Credential Issuer retrieves from X which private key to use in order to decrypt
CP(K); after doing so, it obtains K and sends K to the Credential Verifier. 7. The Credential Verifier uses K to decrypt K(VC) , thus retrieving VC. 8. VC Validation: once decrypted, the Credential Verifier checks the Credential Issuer’s signature on the VC to ensure that it is valid and has not been tampered. The Credential Verifier can now process the VC based on the User’s attribute attestation (e.g., identity verification, access rights, etc.).
To achieve a high level of interoperability, it is essential to establish a common framework for Verifiable
Credential Providers. This framework must go beyond technical specifications, standards, and protocols
to include a shared semantic scheme for Verifiable Credentials. That is why, since version 1.2.0 of the
ARF document, the concept of Attestation Rulebook1 [
To address these challenges, Credential Issuers could utilize the Attestation Rulebooks catalogue to publish their attribute when necessary. This catalogue mitigates the risk of uncontrolled implementation practices that could degrade system quality and increase complexity and maintenance costs.
This catalogue would serve as a comprehensive repository of credential-related information, including Credential Metadata, which provides essential details for identifying, verifying, and contextualizing credentials, as well as information on any associated policies.
Analogous to Credential Issuer Metadata, where the parameter
“credential_configuration_supported” lists the IDs of credentials available for issuance along with their corresponding metadata,
Credential Metadata consists of various parameters as defined in [
While multiple pricing models can be applied, we outline three example approaches: • Issuance based: the User must pay to obtain the new credential. • Verification based : the Credential Verifier must pay the Credential Issuer for a credential verification.
• Free: no payment is required.
These models serve as illustrative examples, highlighting the flexibility in defining pricing strategies within EUDI Wallet ecosystem.
Figure 3 is an example snippet of Credential Metadata, where the metadata for a specific credential includes a newly proposed parameter “pricing_policy”.
The proposed solution could also allow to apply diferent price options: 1. Static price, which refers to a pricing strategy where the cost of the service remains unchanged; in practice, a static price is fixed and does not undergo frequent updates. This can be embedded directly into the attribute metadata, clearly exposing the unit price per verification. This transparency allows the Credential Verifier to quickly assess whether they are willing to accept the price or opt not to use the attribute, simplifying decision-making. 2. Dynamic price, which refers to a pricing strategy where the cost of the service fluctuates based on various factors. This approach allows businesses to maximize revenue by adjusting prices in real-time or at regular intervals. The afected stakeholders must check a specific URL, periodically updated, where prices are listed. This also allows Credential Issuers to better manage the attributes ofering on a daily-basis and/or based on diferent agreements with several Credential Verifiers.
The OID4VP protocol can be extended to enable interaction with the central registry in the following manner:
1. Discovery Phase: before a Credential Verifier requests a Verifiable Presentation (VP), it queries the Attestation Rulebooks catalogue to understand the available attributes, Credential Issuers, and associated costs. The Credential Verifier includes the selected attributes in the request, specifying the willingness to pay associated verification fees.
2. Encrypted VCs exchange: described in Section 3.1.2.
This proposal entails minimal modifications to existing models within the current ecosystem, yet these changes facilitate the introduction of a new business model. The approach is highly adaptable, allowing for seamless integration with emerging needs.
The following key benefits are worthy of note: • User Privacy and Unlinkability: this approach ensures that Credential Issuers are unable to identify which User is presenting their credential to a specific Credential Verifier requesting its verification. This enhances User privacy significantly and minimizes the risk of tracking. • Creation of a Credential-Based Market: the implementation of a rulebook that defines the value associated with each credential establishes a marketplace where Credential Verifiers must compensate Credential Issuers for verifying the authenticity of a credential. This model fosters a market driven by the value and trustworthiness of credentials, where the cost of verification reflects the intrinsic value of the credential itself. • A Credential Verifier cannot continuously request a specific credential because the verification process involves requesting the key necessary to decrypt the received credential. Without this key, the Credential Verifier cannot access the credential’s content, ensuring privacy and preventing unauthorized repeated checks.
A potential limitation of this approach is that it does not work if the Credential Verifier is ofline. This means that the approach is not suitable for NFC scenarios, where the Credential Verifier and Wallet could be ofline. In such cases, the Credential Verifier would need to interrupt the presentation as it would not be able to reach the Credential Issuer to obtain the decryption key.
It is important to note that in any scenario where the Credential Verifier is ofline and cannot contact the Credential Issuer, verifying authenticity through signature check becomes impossible, and therefore, the presentation cannot be completed.
However, if only the Wallet is ofline, the presentation can still proceed, thanks to the refreshed credential that was obtained in a previous moment, provided that is recent enough to be valid for the presentation. 6. Privacy Considerations • The Credential Issuer can retrieve user information or build a user profile after a refresh and a consecutive presentation operation. Although the presentation process is user-anonymous, the refresh process is not. Therefore, after a refreshing VC and a subsequent decryption request for a presentation (initiated by the Credential Verifier), the Credential Issuer could potentially build a user profile. However, there are three conditions to consider: 1. Low refresh request flow : The ideal scenario is to have a low number of refresh requests to the Credential Issuer, so that all refreshed credentials could be efectively tracked by the Credential Issuer. 2. Low decryption request flow : The ideal scenario is to have a low number of decryption requests to the Credential Issuer, so that the refreshed credentials could be properly associated with the decryption requests. 3. Knowledge of the Credential Verifier’s behavior : The Credential Issuer must be aware that the Credential Verifier only accepts credentials that have been recently refreshed. If the Credential Verifier does not have this restriction, the entire process would lose its efectiveness. For example, if the Credential Verifier only accepts credentials updated within the last 5 minutes, the Credential Issuer would be aware that, most likely, one of the credentials refreshed in the past 5 minutes is associated with the Credential Verifier’s decryption request. However, if the Credential Issuer is unaware of this Credential Verifier restriction, false positives could occur. For instance, if a person updates their credential and, within a minute, the Credential Issuer receives a verification request, the Credential Issuer might mistakenly associate the refreshed credential with the new request, assuming it comes from the same person. • With regard to Section 3.1.2 about VC Cyphered Presentation, it shall be highlighted that the Credential Issuer and the Credential Verifier could collude in order to decrypt the JWE: this is due to the possibility to share the entire JWE with the Credential Issuer. • In principle, the Credential Issuer could generate a new private-public key couple for each request of a new credential. This fact would allow a tracking of the Wallet Holder’s activity by the Credential Issuer, resulting in a concern for the privacy.
Therefore, it would be advisable to control the number of public keys available for the Credential Issuer: if the number of public keys increases over time, this could be an indicator of potentially malicious Credential Issuer’s behavior. • The entire mechanism allows for the Holders’ privacy because: – The cryptographic material (e.g. the public key CP in 3.1.2) is not directly generated by the Credential Issuer. It is, instead, derived by the Wallet starting from one of the Credential Issuer’s public keys in such a way that the Credential Issuer is not aware of this generation; moreover, several “child” public keys can be generated starting from the same “parent” public key belonging to the Credential Issuer. – The Credential Issuer never gets the VC in plain, unless the Verifier explicitly shares it with the Credential Issuer, without the Holder’s consent. • In the worst-case scenario where the Credential Issuer has issued only one credential, it would be possible to link the credential to the Wallet Holder.
In conclusion, our eforts are directed towards creating conditions for new business models that ensure compliance with unlinkability requirements, while also fostering a virtuous flywheel efect that can increase the number of use cases. This can be achieved through the involvement of more Credential Issuers of electronic attributes, who will be incentivized by a sustainable business model. Consequently, this will benefit Credential Verifiers and Users who will be more incentivized to utilize the Wallet.
The proposal aims to lay the foundations for this growth mechanism, with what we believe to be the right balance between privacy, sustainability, implementation efort, and incentives for adoption by the various stakeholders.