What is a relying party? From OpenID to EUDI Wallet

A relying party is any service that relies on someone else’s confirmation of a user’s identity instead of verifying it entirely on its own. When a news site lets you in with ‘Sign in with Google’, the news site is the relying party and Google is the identity provider. When a bank asks your EUDI Wallet for proof of address, the bank is a relying party too, and the wallet and the issuer of the credential are on the other side.

This page replaces the old page on the topic from the original openideurope.eu site, and traces the term from OpenID 2.0 to today.

Where does the term come from?

The term came into wide use with OpenID 1.x and 2.0 in the mid-2000s. There were two main roles. The OpenID Provider (OP) held your account and authenticated you. The Relying Party (RP) was the website that wanted to know who you were and accepted the provider’s answer. The flow was: you typed your OpenID, the relying party discovered your provider, redirected you there, and the provider sent back a signed assertion that you controlled that identifier. Our page on OpenID 2.0 walks through the mechanics.

The idea of a party that relies on another is older than OpenID. The eIDAS Regulation (EU) No 910/2014 defines a ‘relying party’ as a natural or legal person that relies upon an electronic identification or a trust service. SAML calls the corresponding role ‘service provider’.

How is the term used today?

In OpenID Connect and OAuth

OpenID Connect kept the vocabulary. In the Core specification, a relying party is an OAuth 2.0 client that needs end-user authentication and claims from an OpenID Provider. In practice, this means your web app or mobile app that is registered with Google, Microsoft or a national identity provider. Registration at the provider gives the relying party a client ID and, for confidential clients, credentials.

In the EUDI Wallet

The revised eIDAS Regulation, Regulation (EU) 2024/1183, uses the term again for a new situation. Here the user holds credentials in their own wallet app, and a wallet-relying party is a service that asks the wallet for data, for example to open an account, verify an age or confirm a qualification. The presentation usually runs over OpenID for Verifiable Presentations.

Key differences from the OpenID days:

• The relying party does not talk to an identity provider during the login; it talks to the wallet, which holds the credential.
• The wallet can show the user who is asking and which attributes are requested, before anything is shared.
• The relying party must be identifiable and registered.

What does registration require?

Article 5b of the amended eIDAS Regulation requires relying parties that intend to rely on wallets to register in the Member State where they are established. Commission Implementing Regulation (EU) 2025/848 of 6 May 2025 sets out how registration works, and the Commission has since amended it to update the referenced standards. In outline:

1. The relying party registers with a national authority or registrar and states who it is and which services it offers.
2. It declares the intended use: for what purpose, and which attributes it will request.
3. It receives credentials, such as certificates, that identify it to wallets during a request.
4. The wallet can check that a request matches what the relying party registered, and may warn the user otherwise.

The principle is that a relying party may not ask for more than it has declared. National registers and tooling are being built in parallel with the wallets, so the practical details differ between countries. Our page on eIDAS 2.0 explains the wider legal context, and the EUDI Wallet overview shows where registration fits in the architecture.

In addition, the Regulation obliges certain private services to accept the wallet. Very large online platforms and services that are legally required to use strong user authentication must, on request, accept wallet-based authentication. The exact scope and the dates follow the Regulation and national implementation.

Examples

• Social login (OpenID Connect). A shop’s web app is the relying party; the identity provider returns an ID token.
• Age check (EUDI Wallet). A video platform registers as a relying party for the attribute ‘over 18’. The wallet shows the request and sends only a yes.
• Account opening (EUDI Wallet). A bank registers to request name, address and date of birth to onboard customers.
• Public service. A municipal portal asks for a residence attestation.

Security and privacy considerations

• Authenticate the verifier. Without proof of who is asking, users can be tricked by fake relying parties. Registration and certificates address this.
• Request the minimum. Data minimisation applies to relying parties; over-asking can breach data protection law and can be reported.
• Validate responses. A relying party must check signatures, the credential’s status and the freshness of the response. Skipping these checks is the classic implementation bug in federation too.
• Do not store more than needed. Receiving a verified attribute does not give a reason to keep it for longer than the purpose requires.
• Link requests to purposes. Clear purpose statements help users decide, and are part of the registration.

How does the term relate to other standards?

Identity provider and relying party remain the basic pair in identity federation. The wallet adds the issuer and holder, and splits the old identity-provider role: the issuer attests, the wallet presents. Knowing the older vocabulary helps when reading specifications that mix OpenID Connect, OAuth and wallet terms.

Status in October 2026

Member States are due to offer wallets by the end of 2026, and relying party registration is part of that rollout. The technical standards that the Implementing Regulation references are updated periodically, so check the current text and your national registrar before you integrate.