Skip to main content

How Wallet-Relying Party Registration Works

Key components explained​

Let's explore each of the three main components relate to each other.

National register​

The national register is a public directory of all organizations authorized to interact with EUDI Wallets within a Member State's jurisdiction. It's an official list that answers the question: "Is this organization legitimate and what are they allowed to do?"

The register stores essential information about each wallet-relying party:

  • Legal name and identifiers (like business registration number)
  • Service description
  • Entitlements (their role: service provider, attestation provider, etc.)
  • Intended use declarations (what data they need and why)
  • Privacy policies
  • Contact information
What are entitlements?

Entitlements define the organization's authorized role(s) in the EUDI Wallet ecosystem. These are standardized categories set by EU regulation that determine what kind of interactions an organization can have with wallets.

Common entitlements include:

  • Service_Provider - Organizations that verify user data (like a bank checking your identity)
  • QEAA_Provider - Qualified providers issuing verified credentials
  • Non_Q_EAA_Provider - Non-qualified credential issuers
  • PID_Provider - Organizations issuing person identification data (like government-issued ID)
  • PUB_EAA_Provider - Public sector bodies issuing credentials from authentic sources

Organizations may have multiple entitlements if they perform multiple roles. For example, a university might be both a service provider (verifying enrollment) and an attestation provider (issuing diplomas).

This information is made publicly available through two interfaces:

The public website allows anyone to browse and search the registry - useful for users, businesses, or auditors who want to verify an organization's registration status.

The public API enables automated queries by:

  • Wallets (to verify relying parties during interactions)
  • Certificate authorities (when issuing access and registration certificates)
  • Other systems that need to check registration status programmatically

Registrars​

The registrar is the entity responsible for managing the national register - they're the gatekeepers who verify organizations and maintain the registry's accuracy.

Each Member State must designate at least one registrar, though they may choose to designate multiple registrars for different purposes or sectors. The registrar's responsibilities include:

Accepting and processing applications: Organizations submit detailed applications including their legal identity, business model, intended use of wallet data, and privacy policies.

Verifying applicants: This involves:

  • Authenticating the organization's identity
  • Checking business registration against official sources
  • Validating entitlements against trusted lists (for qualified providers)
  • Ensuring the intended use makes sense for their business
  • Confirming no duplicate registration exists

Maintaining the register: Adding verified organizations to the registry, updating information when organizations change, and removing organizations that no longer meet requirements.

Coordinating with certificate providers: Ensuring that only successfully registered organizations receive the certificates they need to operate.

Certificate providers​

Once an organization is successfully registered, they need certificates to actually interact with wallets. Member States authorize certificate providers to issue these certificates. There are two types:

Access Certificate (mandatory): Every registered wallet-relying party must have an access certificate. This is a credential that authenticates them when connecting to wallets - like a digital ID card that proves "Yes, I'm the organization I claim to be, and I'm registered."

The access certificate contains basic identification information: the organization's name, identifier, URL, and contact details.

Registration Certificate (optional): Member States may choose to issue registration certificates that contain detailed information about what data the relying party is authorized to request. This includes their entitlements, intended use declarations, the specific credentials and attributes they're authorized to collect, and their privacy policy.

Registration certificates enable local verification - the wallet can check everything it needs to know about the organization without querying the registry. This enhances privacy but requires more complex infrastructure.

note

Member States have flexibility in how they organize certificate issuance. See Certificate issuance models for an explanation.

How it works in practice​

Now that we understand the components, let's walk through how they work together in real-world scenarios.

The registration process​

To become a registered wallet-relying party, organizations must go through a formal registration process with their Member State's registrar:

note

This diagram shows the integrated model where the registrar and certificate provider are the same entity. Member States have flexibility in how they organize this process - see the Certificate issuance models section below for other approaches.

Step 1: Submit application

The organization provides comprehensive information about their identity, business, and intended use of wallet data. This includes legal documentation, business registration details, service descriptions, and privacy policies.

Step 2: Verification

The registrar conducts thorough verification:

  • Authenticates the organization's legal identity against official business registries
  • Validates that their intended use aligns with their business model
  • For qualified providers, checks their status against relevant trusted lists
  • Ensures no duplicate or conflicting registrations exist
  • Reviews privacy policies for compliance with data protection requirements

Step 3: Registry listing

Once verified, the registrar adds the organization to the national register with all their registration details. This information immediately becomes publicly available through the registry's website and API.

Step 4: Certificate issuance

The organization receives their access certificate (mandatory) and may receive a registration certificate (optional, depending on Member State policy). These certificates are cryptographically signed and can be used immediately to interact with wallets.

Certificate issuance models​

Member States have flexibility in organizing the relationship between registrars and certificate providers. The ETSI standards define four common models:

Model 1: Integrated model (shown in diagram above)

The registrar and certificate provider are the same entity. Registration and certificate issuance are tightly coupled and managed under a single authority.

Model 2: Registrar-initiated issuance

The registrar completes the registration and then instructs a designated certificate provider to issue certificates. The wallet-relying party does not interact directly with the certificate provider.

Process:

  1. Registrar completes verification and adds WRP to registry

  2. Registrar instructs certificate provider to issue certificates

  3. Certificate provider issues certificates based on registry data

  4. Certificates are delivered to the WRP

Note: Access certificate and registration certificate providers may be separate entities, and Member States may authorize multiple providers.

Model 3: RP-initiated issuance post-registration

The registrar performs registration only. Later, the relying party contacts a certificate provider to request certificates. The provider verifies that the relying party is listed in the registry before issuing certificates.

Process:

  1. Registrar completes verification and adds WRP to registry

  2. WRP contacts a certificate provider (their choice)

  3. Certificate provider queries registry to verify registration status

  4. Certificate provider issues certificates if verification passes

Model 4: Provider-assisted registration

The certificate provider acts as a proxy to the registrar, handling both the submission of registration data and certificate issuance once registration is confirmed.

Process:

  1. WRP contacts certificate provider

  2. Certificate provider submits registration data to registrar on behalf of WRP

  3. Registrar verifies and adds WRP to registry

  4. Certificate provider receives confirmation

  5. Certificate provider issues certificates to WRP

Note: Access certificate and registration certificate providers may be separate entities, and Member States may authorize multiple providers.

How wallets verify relying parties​

When a wallet user encounters a relying party, the wallet automatically verifies the relying party's registration status. This happens in one of two ways, depending on whether the Member State issues registration certificates:

Option 1: With registration certificate (local verification)​

The process:

  1. Relying party sends their data request along with both their access certificate and registration certificate

  2. Wallet verifies the certificate signatures, reads the registration details, and compares what's being requested against what they're registered for

  3. Wallet displays the results to the user:

  • ✅ If the request matches: Shows organization details and requested data
  • ⚠️ If the request exceeds registration: Warns "This organization is requesting more data than they registered for"
  • User decides whether to approve or decline
note

Privacy advantage: Everything happens locally on the device – no need to query the registry, so no one else knows about this interaction.

Option 2: Without registration certificate (registry query)​

The process:

  1. Relying party sends their data request along with their access certificate

  2. Wallet extracts the identifier from the access certificate and queries the Member State registry API

  3. Registry returns the organization's registration details

  4. Wallet compares the request against registry information and displays the results to the user:

  • ✅ If the request matches: Shows organization details and requested data
  • ⚠️ If the request exceeds registration: Warns "This organization is requesting more data than they registered for"
  • User decides whether to approve or decline
note

Privacy trade-off: Simpler infrastructure for Member States (no need to issue registration certificates), but requires real-time registry query. The registry learns about this interaction, though it doesn't see what data was shared.

Cross-border operations​

Each Member State operates its own registry, but they all work together seamlessly across Europe:

This enables cross-border services with no barriers because all registries use the same technical specifications. Any wallet can query any registry - meaning a German user's wallet can automatically verify a French bank, a Spanish university, or an Italian retailer.

For example, when a German user shops at a French online retailer and the retailer requests age verification, the user's wallet automatically queries the French registry, verifies the retailer's registration, and shows the user that this is a legitimate, authorized organization - all happening seamlessly in seconds.

Relying parties only need to register once in their home Member State, and that registration works across the entire EU. They don't need separate registrations in each country where they operate.

This creates a federated trust infrastructure where each Member State maintains sovereignty while ensuring interoperability across Europe.

Regulatory context​

EU Regulations:

  • eIDAS 2.0 (Regulation (EU) No 910/2014, as amended by Regulation (EU) 2024/1183) establishes the European Digital Wallet framework and requires Member States to maintain registers of wallet-relying parties.
  • Commission Implementing Regulation (EU) 2025/848 (official text) lays down the detailed rules for how these registers must work, including what information must be collected, how it must be made available, and the technical specifications all registers must follow.

ETSI Standards:

  • ETSI TS 119 475: Electronic Signatures and Trust Infrastructures (ESI); Relying party attributes supporting EUDI Wallet user's authorization decisions
  • ETSI TS 119 411-8: Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 8: Access Certificate Policy for EUDI Wallet Relying Parties

Timeline​

The regulations apply from December 24, 2026:

  • Member States must have operational national registers with infrastructure, policies, and designated authorities in place
  • Organizations must be registered before they can interact with EUDI Wallets
  • Wallet providers must implement verification mechanisms to check relying parties against registries

Who must comply​

  • All EU Member States must establish at least one national register for wallet-relying parties in their territory
  • All organizations providing digital services via EUDI Wallets must register (public and private sector, attestation providers, trust service providers)
  • Registration is mandatory - no organization can interact with EUDI Wallets without it