Relying parties authenticate users with EUDI Wallet by sending a presentation request to the user’s wallet, receiving a cryptographically signed response containing verified identity attributes, and validating that response against the EU trust framework. The entire process is standardized across Member States, which means a single integration approach works for users across the EU. The sections below break down each part of the flow, from the first request to the final verification check.
What happens during a wallet-based authentication flow?
During a wallet-based authentication flow under eIDAS 2.0, the relying party sends a presentation request to the user’s EUDI Wallet, the user reviews and approves what data is shared, and the wallet returns a cryptographically signed response that the relying party verifies. The user stays in control throughout, and no data is shared without explicit approval.
In practice, the flow typically looks like this:
- The relying party generates a presentation request specifying which identity attributes it needs, such as name, date of birth, or nationality.
- The request is delivered to the user’s wallet, either via a QR code, a deep link, or a redirect, depending on the channel.
- The user sees exactly what is being requested and actively chooses to approve or decline the sharing of each attribute.
- The wallet returns a signed presentation containing only the approved attributes.
- The relying party validates the cryptographic signatures and checks the issuer’s credentials against the trust framework before granting access.
This flow is designed to be fast, privacy-respecting, and highly reliable. Because the wallet holds pre-verified credentials issued by trusted authorities such as governments or qualified trust service providers, the relying party does not need to re-verify the underlying data itself. The identity proofing has already been completed upstream.
What credentials does a relying party request from the wallet?
A relying party requests specific identity attributes from the wallet, not the entire identity document. The most common starting point is the Person Identification Data (PID), which includes core attributes such as full name, date of birth, place of birth, and nationality. Depending on the use case, relying parties can also request Electronic Attestations of Attributes (EAAs).
EAAs extend the wallet beyond basic identity. They can include a wide range of verified attestations, such as professional qualifications, driving licences, health insurance details, or educational certificates. Relying parties in regulated sectors often need a combination of PID and one or more EAAs to meet their compliance requirements. The eIDAS 2.0 framework distinguishes between Qualified Electronic Attestations of Attributes (QEAAs), issued by qualified trust service providers, Public Body-issued EAAs (PuB-EAAs), issued by or on behalf of public bodies, and non-qualified EAAs issued by other providers.
A key principle built into the eIDAS 2.0 framework is data minimization. Relying parties are expected to request only the attributes they genuinely need for a specific transaction. For example, an age verification check requires only confirmation that the user is above a certain threshold, not their exact date of birth. Selective disclosure makes this possible without requiring zero-knowledge proofs. This approach protects user privacy and reduces the risk of over-collection of personal data.
Under CIR (EU) 2025/848, adopted on 6 May 2025, a relying party must register with the national authority of its Member State of establishment before it can request wallet data. Registration is per intended use: the relying party declares which attributes and attestations it will request, and the wallet checks incoming requests against that registered scope.
How does a relying party verify the authenticity of wallet credentials?
A relying party verifies the authenticity of wallet credentials through three distinct checks, not a single cryptographic operation.
The first check is signature verification. Each credential in the EUDI Wallet is digitally signed by its issuer at the point of issuance. When the wallet presents a credential to a relying party, that credential carries a signature that proves it has not been altered and that it came from a specific, registered issuer. The relying party’s verification software checks this signature against the public keys of the issuing authority, published on the relevant national trusted list. National trusted lists are brought together in the EU List of Trusted Lists (LOTL). This check can be performed offline.
The second check is revocation status. Issuers must make revocation status information available, and relying parties query this information as part of the verification process. This ensures that credentials that have expired or been withdrawn are not accepted. This check requires a connection to the issuer’s status service.
The third check is the wallet unit attestation. The relying party verifies that the presenting wallet instance is running on a certified wallet solution. This check establishes that the wallet unit meets the security requirements of the eIDAS 2.0 framework. It also requires an online connection.
The technical standards underpinning this process are set out in the Architecture and Reference Framework (ARF), developed by the eIDAS Expert Group. The ARF provides the technical elaboration of the requirements contained in the implementing acts adopted by the European Commission, which are legally binding. These standards specify the credential formats, including mdoc and SD-JWT VC, signature algorithms, and communication protocols that all EUDI Wallet implementations must follow, supporting interoperability across borders and systems.
What is the role of the trust framework in relying party authentication?
The trust framework is the backbone of relying party authentication under eIDAS 2.0. It defines which wallet providers, credential issuers, and relying parties are recognized as trustworthy actors within the ecosystem. Without a functioning trust framework, relying parties would have no reliable way to distinguish genuine wallet credentials from fraudulent ones.
Governance of the trust framework is a shared responsibility. The European Commission manages the legal framework and adopts implementing acts containing the binding requirements. Member States provide or mandate wallet solutions, certify and notify them, and supervise actors within their own jurisdiction. The European Digital Identity Cooperation Group supports cross-border alignment and cooperation. National competent authorities and registrars handle registration and oversight at the national level, while wallet providers, PID issuers, qualified trust service providers, and relying parties each carry defined obligations within the ecosystem.
At its core, the trust framework consists of:
- National trusted lists: Official registries maintained by Member States that list certified wallet providers, qualified trust service providers, and recognized credential issuers. These are brought together in the EU List of Trusted Lists (LOTL). Where relevant, Lists of Trusted Entities (LoTE) may also apply.
- Certification requirements: Wallet solutions must be certified against defined security and interoperability standards before they can be listed. Certification and notification are carried out at the national level.
- Relying party registration: Under CIR (EU) 2025/848, organizations wishing to accept EUDI Wallet credentials must register as relying parties with the relevant national authority of their Member State of establishment before requesting wallet data. Registration includes declaring the intended use and the attributes or attestations to be requested.
- Cross-border recognition: Because the framework is harmonized across the EU, a relying party in one Member State can trust credentials issued by authorities in another, provided the relevant wallet has been certified and notified. National or sector-specific requirements that apply to individual use cases continue to apply alongside the eIDAS 2.0 framework.
This framework transforms wallet authentication from a bilateral trust problem into a federated, scalable system. Relying parties do not need individual agreements with every credential issuer. They trust the framework, and the framework vouches for the issuers. This is what makes cross-border digital identity practical at scale.
What are the technical requirements for becoming a relying party?
To become a relying party under eIDAS 2.0, an organization must register with the relevant national authority under CIR (EU) 2025/848, implement the technical interfaces set out in the Architecture and Reference Framework, and ensure its systems can send valid presentation requests and process signed credential responses. Registration is a formal requirement, and the specific process is determined by the applicable national registration framework.
On the technical side, relying parties need to implement support for the protocols and interfaces specified in the ARF. This includes the OpenID for Verifiable Presentations (OID4VP) protocol, which governs how presentation requests are sent and how wallet responses are received and processed. For proximity use cases, ISO/IEC 18013-5 applies, while ISO/IEC TS 18013-7 covers online presentation. The relying party’s backend must be capable of performing all three verification checks: validating the cryptographic signatures on incoming credentials, querying issuer revocation status, and verifying the wallet unit attestation.
Relying parties also need to manage their own signing keys, which are used to sign the presentation requests they send to wallets. Users and wallets can verify these keys against the relying party’s registered entry, which confirms that the request is coming from a legitimate, registered service.
A relying party is not tied to a specific wallet provider. It must be able to accept every relevant certified and notified wallet, regardless of which Member State issued it or which provider built it.
For organizations in financial services or government services, additional sector-specific requirements may apply on top of the baseline eIDAS 2.0 technical obligations. Sector-specific legislation continues to apply alongside the eIDAS 2.0 framework. The core integration pattern is consistent, which means the investment in building wallet-compatible infrastructure has broad reuse value across different services and use cases.
How does eIDAS 2.0 wallet authentication differ from existing login methods?
eIDAS 2.0 wallet authentication differs from existing login methods primarily in where trust originates. With passwords or social logins, the relying party must verify the user’s identity itself or trust a third-party platform. With EUDI Wallet authentication, the user presents credentials that were already verified and issued by a trusted authority, shifting the trust anchor upstream.
Compared to username and password combinations, wallet authentication eliminates the risks of credential stuffing, phishing, and password reuse. There is no shared secret that can be stolen from a database, because the authentication is based on cryptographic proof.
Compared to existing eID-based logins, such as national electronic identity schemes, the EUDI Wallet adds portability and selective disclosure. A user can share only the specific attributes needed for a transaction. It is worth noting that existing national eID systems are distinct from EUDI Wallets. A national eID scheme already in operation is not automatically an EUDI Wallet. Wallet status depends on certification and notification under the eIDAS 2.0 framework. Selective disclosure is a meaningful privacy improvement, especially for services that only need to confirm a single attribute.
Compared to federated logins through commercial identity providers, wallet authentication gives users direct control over their data. There is no intermediary platform that logs the authentication event or builds a profile based on where the user logs in. The interaction is between the user, their wallet, and the relying party. Each time a user authenticates, they approve a fresh presentation from the wallet.
For organizations that currently rely on knowledge-based authentication or document uploads for identity verification, the transition to wallet-based identity solutions also reduces operational costs. Pre-verified credentials mean less manual review, fewer friction points in onboarding, and a more consistent user experience across services.
How the ID Connector connects relying parties to EUDI Wallet authentication
Implementing relying party authentication for eIDAS 2.0 wallets involves registration requirements, technical integrations, trust framework compliance, and sector-specific rules. The ID Connector is an integration that lets relying parties accept every certified European wallet, whatever Member State issued it, for identification, login and qualified signing. EUDI Wallet acceptance comes first; the same interface also carries other IDs, such as national eIDs, bank IDs and identity documents, inside and outside the EU.
In the context of wallet-based authentication, the ID Connector handles:
- Wallet acceptance across every certified and notified EUDI Wallet, regardless of provider or Member State
- Verification against national trusted lists and the EU List of Trusted Lists, covering issuer signature validation
- Revocation status checks against issuer status services, so withdrawn or expired credentials are not accepted
- Wallet unit attestation validation, confirming that the presenting wallet instance runs on a certified wallet solution
- Registered attribute scope enforcement, ensuring that presentation requests stay within the scope declared during relying party registration
- Qualified signing via a connected qualified trust service provider, for use cases that require a qualified electronic signature
The ID Connector is relevant for organizations in financial services, healthcare, pharma, and government, where wallet-based authentication intersects with sector-specific obligations under eIDAS 2.0. To understand what becoming a relying party involves for your organization and how the ID Connector fits into your existing systems, get in touch with TrustTech.