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 an EUDI 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.
Keep reading: for the broader regulatory context, see eIDAS 2.0 and EUDI from obligations to competitive advantage.
Need help with a PoC? Get in touch, we’ll help you cut p95 and shorten the signup path without risking compliance.
