Relying party registration requires a verifier to register in the member state where it is established, declaring who it is and which attributes it intends to request. Wallets check that registration and must warn the holder when a verifier asks for more than it registered for. Whether the wallet then blocks the request is left to each wallet provider’s risk policy.
The regulation makes over-collection structurally visible instead of leaving it to policy. A registered relying party gets a certificate stating its identity, purpose and attribute scope, and presents that alongside its request.
The wallet shows the holder who is asking and what they registered to ask for. A verifier reaching past its registration is visible at the moment of consent, which enforces rather better than a privacy policy nobody reads.
Article 5b(3) puts teeth in it: a relying party may not request data beyond what its registration lists. The place is not a choice either, since Article 5b(1) says you register in the member state where you are established. The registrar assigns an identifier that is unique across the EU.
One timing detail matters for planning. The duty on wallets to verify and validate registration certificates only starts 24 months after the regulation amending the protocols implementing act enters into force, so consent-screen enforcement arrives later than the registration duty itself.
Defined in
Regulation (EU) 2024/1183 Art. 5b(1) to 5b(3); ARF v3.0.0 sections 3.11.2, 3.19 and 6.6.3.3
Registration decides what you can legitimately ask for. Settling your attribute set before you register, and keeping it small, avoids both a re-registration cycle and consent-screen friction.
Authbound handles the protocols, formats, trust lists and revocation checks behind these terms. See what people build with them.
