In post #2 of our eIDAS/EUDI series we move from “what and why” to “how”. If you own onboarding, KYC, e-signatures or any other relying parties with access to digital services, EUDI Wallet acceptance becomes a concrete delivery item bound to eIDAS 2.0 and the implementing acts.
Need broader context first? Start with our intro article: eIDAS 2.0 and the EUDI Wallet – the essentials
What the implementing acts actually change?
They specify:
- the minimum wallet capabilities and attribute verification process;
- exchange standards (OpenID4VP/CI, VC/DID);
- audit requirements and cross-border interoperability;
- roles and trust registries.
In practice, service providers (fintech, telco, education, healthcare, QTSP) must adopt the EUDI Wallet acceptance model and adjust identity flows.
Two integration models: Direct RP vs Broker
Direct RP (relying party)
- You implement the protocols (OpenID4VP/CI) and your own attribute validation backend.
- More control, more responsibility for conformance and maintenance.
Broker / gateway
- An intermediary layer that unifies multiple national wallets behind one API.
- Faster time-to-market, with vendor dependency.
How to choose?
- Strong in-house IAM and signature flows? - Direct.
- Need to launch quickly across countries? - Broker.
The standards you’ll meet on day one
- OpenID for Verifiable Presentations (OpenID4VP) - how to request and receive attribute presentations from the wallet;
- OpenID for Credential Issuance (OpenID4CI) - how to issue credentials (if that’s your role);
- Verifiable Credentials (W3C VC) and DID - the data and identifier layer;
- Qualified signatures and seals (e.g., XAdES) - required for documents and qualified registries.
Reference architecture (relying party)
Layer 1 - Front (signup/KYC/signature):
- “Sign up with EUDI” / “Verify with EUDI” buttons;
- clear consent UX.
Layer 2 - RP Backend:
- OpenID4VP/CI clients, presentation validation, session handling,
- data minimization: store the result or a proof hash, not a full document.
Layer 3 - Audit and compliance:
- event logs, reproducible consent trail,
- optional on-chain anchoring of hashes (keep personal data off-chain).
Layer 4 - Integrations:
- QTSP (QES/QSeal);
- CRM/CDP;
- antifraud.
A 4-week PoC that actually ships
Week 1 - Discovery and wireframes: map identity touchpoints, choose Direct vs Broker, consent UX mockups.
Week 2 - Technical integration: OpenID4VP requests, attribute validation, minimal disclosure logic.
Week 3 - Audit and metrics: logs, alerts, dashboard (p50/p95 verify time, acceptance, errors).
Week 4 - Tests and demo: edge cases, compliance package, go/no-go for rollout.
The metrics that matter
- Verification time (p50/p95) - typical cases vs long tails;
- Completion rate - does EUDI reduce friction versus legacy KYC?;
- Stability and errors - where the chain breaks and how often.
Common pitfalls to avoid
- Treating EUDI like a document upload - it’s not. Aim for fact confirmation, not document copies;
- Skipping retention and minimization - keep personal data off-chain, anchor hashes, and consent;
- Neglecting consent UX - poor consent screens can kill adoption.
Short implementation checklist
- Pick a model: Direct RP or Broker.
- Design consent UX and error handling.
- Implement OpenID4VP and VC validation.
- Define retention, audit and anchoring strategy.
- Set metrics and SLOs.
- Ship PoC, then scale.
Need help with a PoC? Get in touch, we’ll help you cut p95 and shorten the signup path without risking compliance.
en
pl