A compliance brief on registering as an EUDI Wallet relying party, what you must declare, and the technical verification duties that follow before you go live.
Many businesses treat EUDI Wallet integration as a plugin you drop in late in the project. It is not. The moment you decide to request identity attributes from a citizen's wallet, you take on a defined set of legal and technical obligations under eIDAS 2.0. Most need to be in place before you process a single credential.
Under eIDAS 2.0, any public or private body that requests attributes from a wallet is a "relying party." A relying party is not just someone who accepts a digital ID, it is a registered actor in the trust infrastructure of the EUDI system. That registration is what lets a citizen's wallet verify that you are authorised to receive the data you are asking for.
Article 5b(1) of the revised eIDAS regulation is explicit: you must register with the competent national authority (called a Registrar) in your member state of establishment before you may rely on wallet credentials. This is a precondition, not a post-integration formality.
Registration requires: your legal entity information, the type of service you offer, the specific attributes you intend to request, and your stated purpose for collecting those attributes. The purpose declaration is binding, it ties your data processing to a defined intent, feeding directly into your lawful basis for processing under GDPR. Expanding scope later means going back to the Registrar.
Once registered, you receive an access certificate — a cryptographic credential issued by a national Access Certificate Authority that gets embedded in every presentation request you send to a wallet. The wallet reads it, checks your registered attribute scope, and will refuse to surface any attribute you did not declare. You cannot ask for everything and filter later. The architecture prevents over-collection at the protocol level.
Your product and legal teams need to agree on exactly which attributes each use case actually needs before registration:
An age-gated e-commerce site needing only an over-18 confirmation should register exactly that, not full name, date of birth, and address.
A bank doing KYC onboarding may need name, address, and nationality from a PID, plus a document number.
A hotel doing check-in verification might register name and nationality, but not driving privileges.
The wallet enforces the ceiling automatically. Scoping correctly before registration is one of the most valuable things you can do early in a project.
Purpose limitation. You may use received attributes only for the purpose you declared. Secondary uses require a separate legal basis, and your declared purpose is on record with a national authority.
Data minimisation. If you registered for an attribute you do not actually use, that is a data minimisation failure regardless of what the wallet permitted.
User erasure requests. Users can instruct a relying party to erase data they shared via the wallet. The wallet interface supports this directly. You need a process to act on those requests within GDPR timeframes, build the erasure workflow before you go live.
Pseudonym acceptance. Article 5b(9) prohibits refusing a wallet-generated pseudonym when identification is not legally required. If your service does not legally need a user's real name, you must support wallet-linked pseudonymous accounts. This has product model implications worth flagging early.
When a wallet presents credentials to you, you are responsible for:
Wallet attestation validation. The wallet must present a wallet unit attestation proving it is a genuine, certified EUDI wallet. Your implementation must validate this before accepting any credential.
Revocation checks. A credential valid at issuance can be revoked later. Check revocation status at the time of each presentation, do not cache a prior result.
Issuer signature verification. The PID or attestation must be signed by an issuer appearing on the relevant national or EU-level trusted list. Your validation logic must resolve that chain back to a trusted anchor.
Accepting a credential without these checks makes the verification meaningless from a compliance standpoint.
Article 5b(10) is clear: intermediaries acting on behalf of relying parties are themselves treated as relying parties and must register as such. Intermediaries may not store the content of transactions. The technical burden can be outsourced. The registered attribute scope, the declared purpose, and the accountability for how attributes are used cannot.
Authbound handles the technical verification layer, wallet attestation, revocation checks, and trusted list validation, and provides an API that keeps your requests within your registered attribute scope. If you want to talk through integration architecture or how to approach the registration process, reach out at [email protected] or by booking a meeting at authbound.io/book-a-meeting.
Property transactions involve identity checks, income attestations, and contract signing. Here's how the EUDI Wallet reshapes real estate closings.
How ride-share, delivery, and freelance platforms can use the EUDI Wallet's mDL and QEAA to cut onboarding fraud and meet EU Platform Work Directive requirements.
EUDI-lompakko tuo hyväksytyn sähköisen allekirjoituksen (QES) suoraan puhelimeen. Näin suomalaiset pienyritykset säästävät aikaa ja rahaa sopimuskirjoittamisessa.
