Relying parties connect to the EUDI Wallet ecosystem by registering within a national or cross-border trust framework, implementing standardized protocols to request and verify digital credentials, and accepting cryptographically signed attestations from wallet holders. In short, they become trusted recipients of identity data that users share directly from their EUDI Wallet. This article walks through the key questions every organization needs to answer before making that connection.

What does a relying party actually do in the EUDI Wallet ecosystem?

A relying party is any organization or service that requests and verifies identity attributes or credentials from a user’s EUDI Wallet. Rather than collecting and storing identity data themselves, relying parties receive cryptographically signed attestations directly from the wallet, and they trust those attestations because they come from a recognized issuer within the ecosystem.

In practical terms, a relying party might be a bank asking a new customer to share their verified name and date of birth during onboarding, a government portal requesting proof of address, or a healthcare provider verifying a professional qualification. The common thread is that the relying party defines what it needs, the user decides what to share, and the wallet handles the secure transfer.

This model shifts the balance of power in identity verification. Instead of asking users to upload documents or fill in forms, relying parties receive structured, machine-readable data that has already been verified by a trusted issuer. That makes the process faster, more reliable, and far less prone to fraud.

How does a relying party technically connect to the EUDI Wallet?

A relying party connects to the EUDI Wallet by implementing the technical protocols defined in the Architecture and Reference Framework (ARF), primarily using OpenID for Verifiable Presentations (OID4VP) to request credentials and ISO/IEC 18013-5 for mobile document presentation. These open standards ensure that any compliant wallet can interact with any compliant relying party, regardless of which Member State issued the wallet.

The connection flow works roughly like this:

1. The relying party sends a presentation request specifying which attributes or credentials it needs.
2. The user’s wallet displays the request and asks the user to consent to sharing the relevant data.
3. The wallet generates a verifiable presentation, signed by the wallet and the original issuer.
4. The relying party receives and cryptographically verifies the presentation before granting access or completing the transaction.

To make this work in practice, relying parties need to integrate a verification library or service that handles the cryptographic checks, manages trust anchors, and stays up to date with changes to the ARF. Building this capability in-house is possible, but many organizations choose to work with specialized providers that already have compliant verification infrastructure in place.

What is the trust framework relying parties must register under?

Relying parties must register within the trust framework established under eIDAS 2.0, which is governed at national level by each Member State but designed to be interoperable across the EU. Registration involves being listed in a recognized trust registry, which signals to wallets and users that the relying party is legitimate and authorized to request specific types of credentials.

The trust framework serves two purposes. First, it protects users by ensuring they only share data with verified organizations. Second, it gives relying parties access to the cryptographic trust anchors they need to validate credentials issued by wallet providers in other Member States.

Each Member State is responsible for maintaining its own trusted list of registered relying parties and recognized wallet providers. These national lists feed into a broader European trust infrastructure, so a relying party registered in one country can still accept credentials from wallets issued in another. For organizations operating across borders, understanding how these national registries connect is an important part of the preparation process.

Which attributes can a relying party request from the EUDI Wallet?

Relying parties can request any attribute that is defined within a recognized attestation type and that the user’s wallet contains. The most fundamental attestation is the Person Identification Data (PID), which includes attributes such as name, date of birth, nationality, and address. Beyond the PID, wallets can hold a wide range of qualified and non-qualified electronic attestations of attributes (QEAAs and EAAs), covering documents such as driving licences, professional qualifications, diplomas, and health credentials.

However, relying parties cannot request more data than they need for a specific purpose. The principle of data minimisation is built into the eIDAS 2.0 framework, meaning that requests must be scoped to what is genuinely necessary for the service being provided. A platform that only needs to verify a user’s age, for example, should request an age attestation rather than a full set of identity attributes.

This selective disclosure capability is one of the most significant advantages of the EUDI Wallet model. Users can share a single attribute, such as proof that they are over 18, without revealing their full name or date of birth. For relying parties, this means designing credential requests thoughtfully and only asking for what the use case actually requires.

What are the main compliance obligations for relying parties under eIDAS 2.0?

Under eIDAS 2.0, relying parties have several concrete compliance obligations that go beyond simply implementing the right technical protocols. These obligations are designed to protect users and maintain trust across the ecosystem.

• Registration: Relying parties must register with the relevant national authority before requesting credentials from EUDI Wallets.
• Purpose limitation: Each credential request must specify a clear and lawful purpose, and relying parties may only use the data received for that stated purpose.
• Data minimisation: Requests must be limited to the attributes strictly necessary for the intended service.
• Transparency: Users must be clearly informed about who is requesting their data, why, and what will happen to it.
• GDPR alignment: All data received through the wallet remains subject to GDPR obligations, including storage limits, access rights, and security requirements.
• Audit readiness: Relying parties should maintain records of credential requests and verifications to demonstrate compliance if required.

Organizations in regulated sectors such as financial services or healthcare will also need to align their EUDI Wallet integration with sector-specific regulations, such as PSD3 requirements for strong customer authentication or patient data protection rules.

How should organizations start preparing to become a relying party?

Organizations should start by mapping the use cases within their services where EUDI Wallet integration would add the most value, then assess the technical and legal steps required to support those use cases. Preparation involves both a compliance track and a technical track, and the two need to move in parallel.

A practical starting point looks like this:

1. Identify your use cases. Which services require identity verification? Where would accepting wallet credentials reduce friction or improve security?
2. Review the regulatory requirements. Understand what registration is required in your Member State and what obligations apply to your sector.
3. Assess your technical readiness. Do your existing systems support the protocols needed to receive and verify EUDI Wallet credentials?
4. Plan your data minimisation approach. Define exactly which attributes you need for each use case and build your credential requests accordingly.
5. Test with available pilots and reference implementations. The large-scale pilot projects and open-source reference implementations offer opportunities to test your integration before full deployment.

With Member States legally required to provide wallets to citizens and businesses, the ecosystem is moving from the pilot phase to live deployment. Organizations that wait too long risk being unprepared when wallet adoption accelerates among their users and customers. Reviewing your implementation approach now gives you time to address gaps before they become urgent.

How TrustTech helps organizations connect to the EUDI Wallet ecosystem

Becoming a relying party involves navigating a combination of regulatory requirements, technical standards, and organizational change. TrustTech supports organizations through every stage of that process, from initial scoping to live integration.

Working with TrustTech, organizations can expect:

• Use case analysis: Identifying where EUDI Wallet integration delivers the most value in your specific context, whether in onboarding, authentication, or data exchange.
• Regulatory guidance: Mapping your obligations under eIDAS 2.0 and any sector-specific rules that apply to your organization.
• Technical implementation support: Connecting your systems to the right protocols and verification infrastructure, without unnecessary complexity.
• Trust framework navigation: Supporting your registration as a relying party within the relevant national and European trust registries.
• Ongoing compliance readiness: Helping you stay aligned as the ARF evolves and new attestation types become available.

TrustTech works with organizations across government, finance, healthcare, and other regulated sectors, combining deep knowledge of the EUDI Wallet ecosystem with practical implementation experience. Whether you are just starting to explore what relying party status means for your organization or are ready to begin integration, get in touch with TrustTech to discuss your next steps.