eIDAS Article 5b EUDI Wallet relying party registration

Article 5b makes registration the entry point for wallet relying parties. The relying party must register in its Member State of establishment before relying on EUDI Wallets for a public or private service delivered through digital interaction.

The minimum registration package is specific. It must include information needed for authentication to EUDI Wallets, including the Member State of establishment, the relying party name, any official registration number and the official-record identification data, contact details, the intended use of the wallet, and an indication of the data the relying party will request from users.

The ARF treats intended use as a practical boundary for attribute requests. During registration, a relying party records which attributes it intends to request from wallet units for each service or intended use. If one organisation has materially different wallet uses, the ARF explains that a single relying party may register multiple times and may receive more than one registration certificate.

A single intended use can cover multiple attributes from multiple attestations, but the request should remain coherent for that use. If a relying party has multiple intended uses in one user journey, the ARF says it needs multiple presentation requests, each tied to the relevant intended use.

The ARF describes two preconditions before relying party authentication starts: the relying party registers and obtains an access certificate for each relying party instance, and the wallet unit obtains the trust anchor of the access certificate authority from the relevant list of trusted entities. In each presentation, the relying party instance includes its access certificate and trust chain, signs request data, and the wallet unit verifies the signature, certificate chain, and revocation status before asking the user for approval.

Registration certificates are a separate concept. If the registrar issues them, a registration certificate can list the attributes registered for a particular intended use. The wallet can use that certificate, or contact the registrar if no certificate is available, to compare the requested attributes against what the relying party registered.

The ARF is explicit that user approval in the wallet means the user's decision to present attributes; it should not be treated as the relying party's lawful basis for processing personal data. The relying party still needs its own GDPR analysis for the requested attributes.

Before attributes are presented, the wallet informs the user about the relying party identity, any intermediary, the requested attributes, the relying party's intended use and privacy policy, and the outcome of checks against registered attributes or embedded disclosure policies where those checks are performed.

The EU-level sources do not give one universal public form, fee schedule, portal, evidence pack, or approval service-level agreement for every Member State relying party registration. Article 5b says the relying party registers in its Member State of establishment and that Member States make registration information public online in electronically signed or sealed machine-processable form.

For implementation, treat Member State procedure as a separate source gap until the relevant national registrar, registration portal, access certificate authority, or supervisory body has been identified from country-specific material.

A useful relying party file should let legal, product, engineering, privacy, and security reviewers see the same facts: who is registering, what service will use the wallet, which attributes are requested, how the wallet will authenticate the relying party, and what the user will see before approving presentation.

Keep the file scoped to the establishment Member State and update it whenever the registered information changes.