Skip to content

Wallet-Relying Party Authentication

Overview

This document describes how Relying Parties (RPs) authenticate themselves to EUDI Wallets and how Wallets validate that RPs only request data within their declared intended use. The authentication requirements are derived from Article 5b of the eIDAS 2 regulation and the Implementing Acts.

Core Principles

The authentication architecture is based on the following principles:

Direct Authentication

RPs include certificates and attestations directly in their requests to the EUDI Wallet. This approach:

  • Supports both online and offline interactions
  • Reduces Wallet communication with Registrars
  • Prevents potential tracking of Wallet interactions by Registrars

Separation of Concerns

Two distinct certificates serve different purposes:

Certificate Purpose Standard
Access Certificate Authenticates the RP's identity ETSI TS 119 411-8
Registration Certificate Declares the RP's intended data use ETSI TS 119 475

This separation allows RPs to include only the attestations relevant to each specific request.

Machine-Processable Intended Use

  • Wallets can automatically match the intended use against presentation requests
  • RPs can update their intended uses, but requests must never exceed registered scope
  • Over-asking (requesting more than registered) is detected and flagged to users

Trust Architecture

Trusted ListWallet-Relying Party RegistrarWalletAccess CertificateRegistration CertificateVerifiable PresentationWallet-Relying Partyonboardedpublishedissuesissuesissued forissued forpresented tocreatesused for authenticationused for intended use

RP Registration Process

To interact with an EUDI Wallet, an RP must:

  1. Register at a national Registrar — Provide identity information and undergo validation
  2. Obtain an Access Certificate — For authentication with Wallets
  3. Register intended use — Declare which attributes will be requested and for what purpose
  4. Obtain Registration Certificate(s) — Documenting the declared intended use

Access Certificate

The Access Certificate identifies the RP and enables authentication with Wallets. Key aspects:

  • Identity binding: Contains the RP's verified legal identity
  • Official identifiers: May include EORI, LEI, VAT number, national business register number, or other official identifiers
  • Key management: RPs can request multiple certificates for key rotation
  • Revocation: Can be revoked immediately to reduce breach risk
  • Retention: Must remain available via the Registrar for 10 years

For technical specifications, see ETSI TS 119 411-8.

Registration Certificate

The Registration Certificate documents what data the RP intends to request. Key aspects:

  • Intended use declaration: Specifies which attributes may be requested
  • Purpose description: Human-readable explanation shown to users (multi-language support)
  • Service description: Description of the RP's service
  • Contact information: How users can reach the RP
  • Privacy policy: Link to the RP's data protection information
  • Status management: Revocation capability for invalid certificates

For technical specifications, see ETSI TS 119 475.

Wallet Validation Process

When receiving a presentation request, the Wallet performs the following validations:

1. RP Authentication

  • Validate the Access Certificate chain of trust
  • Verify the certificate is not revoked (via CRL or Status List)
  • Confirm the RP is registered in a recognized Registrar

2. Intended Use Validation (Over-Asking Check)

  • Verify the Registration Certificate is valid and not revoked
  • Compare requested attributes against the declared intended use
  • Flag over-asking if the request exceeds the registered scope
  • The request must be equal to or a subset of the registered intended use

3. User Information

  • Display RP identity and purpose to the user
  • Show any warnings (e.g., over-asking detected)
  • Obtain user consent before releasing data

Interoperability

EU-Wide Standardization (ETSI Standards)

The following are standardized across the EU:

Aspect Standard
Access Certificate format ETSI TS 119 411-8
Registration Certificate format ETSI TS 119 475
General attestation requirements ETSI TS 119 472-1
Presentation requirements ETSI TS 119 472-2
Issuance requirements ETSI TS 119 472-3

Member State Specific

The following can be defined individually by each Member State:

  • RP Registrar onboarding procedures
  • Registrar API and interaction mechanisms
  • Additional national requirements

Verifier-as-a-Service

When an RP uses a hosted verification service:

  • The presented certificates must belong to the RP, not the service provider
  • The RP must disclose the service provider (e.g., in their privacy policy)
  • The service provider may use their own Access Certificate with delegation

Intermediaries

RPs may interact with Wallets through intermediaries. In this case:

  • The intermediary uses its own Access Certificate
  • The Registration Certificate identifies both the RP and the intermediary
  • The Wallet displays both entities to the user
  • Revocation of either party's certificate invalidates the relationship

Registrar Requirements

While specific APIs are not mandated, Registrars should provide:

  • Free read access to registration information
  • Public lookup of RPs by name or identifier
  • Certificate history including issuance, expiration, and revocation dates
  • Security measures such as rate limiting

Protocol Integration

For detailed technical guidance on how Access Certificates and Registration Certificates are used in the OpenID for Verifiable Credentials (OID4VC) protocol family, see OID4VC Protocol Integration.

This includes:

  • Sequence diagrams for issuance (OID4VCI) and presentation (OID4VP) flows
  • Certificate attachment mechanisms
  • Proximity (offline) scenarios