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 intermediaries acting on behalf of relying parties as relying parties, and the ARF describes a Relying Party Instance as the software and hardware used to interact with Wallet Units.

Keep the onboarding record at service level. A single organisation may have more than one intended use, and the ARF explains that separate intended uses may require separate presentation requests and registration information.

Before requesting wallet data, prepare the Article 5b registration package for the Member State where the relying party is established. The grounded minimum record is not a generic vendor questionnaire: it is the data needed to authenticate to wallets, contact the relying party, and explain the intended wallet use and requested data.

Use one intended-use entry for each materially different service purpose. The ARF states that a Wallet Unit can compare the requested attributes with the attributes registered for the relying party and warn the user if the request exceeds the registered set or if registration information cannot be retrieved.

Translate each intended use into a wallet presentation request that a user can understand. The service should request only the attributes recorded for that intended use, use selective disclosure where available, and avoid identity disclosure when a pseudonym or narrower proof is sufficient under the applicable service rules.

The request design should also account for embedded disclosure policies. The ARF describes disclosure policies that may tell the Wallet Unit whether an authenticated relying party is allowed to receive an attestation, and the Wallet Unit presents the outcome to the user.

The onboarding gate should not close until the technical team can prove the Relying Party Instance authenticates to Wallet Units and validates wallet evidence after the user approves the presentation. The ARF presentation flow includes access certificates, trust anchors, request signatures, certificate-chain validation, revocation checking, issuer signature validation, attestation revocation checks, and device-binding checks where relevant.

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 be a privacy and security gate, not a marketing launch checklist. eIDAS requires wallet users to have control over wallet data and Article 5b limits relying parties to the registered data indication; the ARF identifies over-collection, impersonation, message interception, message tampering, and linkability as risks to address in the wallet ecosystem.

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.