EUDI Wallet Relying Party Onboarding Workflow

Start by documenting whether the organisation is the service provider that will request wallet attributes or an intermediary acting for another relying party. eIDAS treats the intermediary as a relying party and prohibits it from storing transaction-content data. The ARF uses Relying Party Instance for the software and hardware that interacts with Wallet Units.

Keep the onboarding record at legal-entity and intended-use level. Regulation 2025/848 requires the register to identify the service type and, for each intended use, list the requested data with user-friendly and technical names, attestation type, machine-readable grouping, and a description of how the data will be used.

Prepare the Article 5b registration package for the Member State where the relying party is established. From 24 December 2026, Regulation 2025/848 requires Member States to maintain national registers and publish national registration policies. Those policies may add supporting documentation and verification procedures, so the Annex I fields are a minimum, not a complete substitute for the national policy.

Use one intended-use entry for each service purpose that requests a different data set or uses the data differently. Registered information must remain accurate and be updated without undue delay. When an intended use ends, the relying party must ask the registrar to cancel that registration.

Translate each registered intended use into a presentation request that a user can understand. Article 5b prohibits requests for data beyond the registered indication and requires the relying party to identify itself. Use selective disclosure where the attestation and protocol support it, and do not refuse a pseudonym when Union or national law does not require identification.

Keep legal duties separate from ARF design guidance. The ARF describes registration comparisons, user warnings, approval flows, and embedded disclosure policies. Use those mechanisms in the technical design, but verify the production profile against the applicable implementing acts, national registration policy, and wallet-supported protocols.

The onboarding gate should not close until the technical team can prove that each Relying Party Instance authenticates to Wallet Units and that the relying party validates requested PID or attestations after user approval. Regulation 2025/848 requires Member States to authorise at least one certificate authority to issue wallet-relying-party access certificates exclusively to registered relying parties. Registration certificates are different: Regulation 2026/1730, which enters into force on 11 August 2026, requires Member States to authorise at least one registration-certificate authority and require automated issuance without undue delay after registration.

Keep evidence that explains both sides of the interaction: what the wallet can verify about the relying party before asking the user, and what the relying party verifies about the received PID or attestation before relying on it.

The final onboarding review should test privacy, security, registration accuracy, and failure handling. eIDAS gives wallet users control over wallet data and limits relying parties to the data indicated at registration. Regulation 2025/848 allows registration suspension or cancellation for inaccurate or misleading information, breach of registration policy, over-requesting attributes, or other relevant breaches of Union or national law.

Close the workflow only when the service can show that it requests no more than registered attributes, identifies itself to the user, validates received evidence, accepts pseudonyms where identification is not legally required, and has a change process for registration updates.