What data may a relying party request from the EUDI Wallet?

A relying party may only request from the EUDI Wallet the data it registered for the intended use. That is the rule in Art. 5b(3) of the eIDAS Regulation. No authority approves requests in advance, but the wallet checks every request against the registration and shows the user who wants what and why. This guide covers which data exists, which rules apply and how to scope your requests.

What data the wallet holds

The wallet contains the person identification data (PID) – the digital ID data – and any number of attestations of attributes, such as a driving licence, student card or professional qualification. The PID of a natural person is defined in Implementing Regulation 2024/2977 as amended by 2026/1731:

Each attribute can be shared on its own (selective disclosure). The PID tables contain no “over 18” field; age proofs come as separate attestations or additional attributes from the issuer, and implementations differ between member states.

The rules

1. Register what you need. For each intended use you state which data you will request, with a user-friendly and a technical name, plus a description of the intended use (Art. 5b(2)(c) eIDAS, Annex I points 9 and 10 of Implementing Regulation 2025/848). See relying party registration.
2. Request only what you registered. You may not ask users for anything beyond that (Art. 5b(3) eIDAS).
3. No pre-authorisation. Since the amendment by 2026/1730, registrars collect data and intended uses for transparency only and must not pre-authorise them (Art. 6(3a) Implementing Regulation 2025/848). Whether a request is lawful is your responsibility.
4. The wallet checks. The registration certificate expresses each registered intended use and a harmonised access policy. If a relying party requests data not listed there, the wallet informs the user (Art. 8(2)(c) and (d)). You must also provide a link to the privacy policy for each intended use (point (g)).
5. Breaches have consequences. The registrar may suspend or cancel the registration of a relying party that requests more attributes than registered (Art. 9(2)(c)). Its certificates are then revoked; without a valid access certificate no request works.
6. Accept pseudonyms. Where the law does not require identification, relying parties must not refuse pseudonyms (Art. 5b(9) eIDAS).

On the user side, the wallet provides control: the dashboard lists who received which data, users can request erasure under Art. 17 GDPR, and they can report suspicious requests directly to the data protection authority (Art. 5a(4)(d) eIDAS).

Registered does not mean allowed

The eIDAS rules only set the frame. Whether you may actually request an attribute follows from the GDPR: you need a legal basis (Art. 6) and data minimisation applies – only as much data as the purpose requires (Art. 5(1)(c)). Registering broadly “just in case” does not change that, and it is visible to everyone, because the registers are public.

Some examples of scoping requests:

These examples are orientation, not legal advice. What a process really needs depends on sector law and your process.

Common mistakes

• Registering too broadly: an intended use “customer service” with the full PID looks disproportionate. Several narrow intended uses with few attributes each work better.
• New request without updating the registration: if a process or its data needs change, update the registration first (Art. 5b(6) eIDAS), then the request – otherwise the wallet warns users.
• Relying on optional attributes: address, email or phone number are optional and not every member state issues them. Processes need a path without them.
• Requesting the portrait without need: the portrait comes with a warning, explicit confirmation and a retention ban. See the portrait in the EUDI Wallet.

How request, approval and verification work technically: How the EUDI Wallet works.