DEV Community: eidas-pro

OpenEUDI SDK Quickstart: Your First EUDI Wallet Verification in 5 Minutes

eidas-pro — Sat, 30 May 2026 10:00:00 +0000

OpenEUDI is open source (MIT) and live on npm.
GitHub: https://github.com/openeudi · npm: @openeudi/core and @openeudi/openid4vp
Originally published on eidas-pro.com.

Prerequisites

Node.js 20+ installed
TypeScript project (or JavaScript with ESM)
A terminal and your favorite editor

That's it. No API keys, no registration, no WRPAC certificate. DEMO mode works out of the box.

Step 1: Install

npm install @openeudi/core

Or with your preferred package manager:

pnpm add @openeudi/core
yarn add @openeudi/core

Step 2: Create a Verifier

import { VerificationService, DemoMode, InMemorySessionStore } from '@openeudi/core';

// Initialize in DEMO mode — no credentials needed
const service = new VerificationService({
  mode: new DemoMode(),
  store: new InMemorySessionStore(),
});

The mode option controls how the SDK behaves:

Mode	Behavior	Use Case
`new DemoMode()`	Auto-completes after 3 seconds	Showcases, sales demos, landing pages
`new MockMode()`	Simulates wallet responses with configurable data	Integration testing, CI/CD pipelines
`new ProductionMode(config)`	Real EUDI Wallet verification	Live verifications (requires WRPAC, Dec 2026+)

Step 3: Create a Verification Session

const session = await service.createSession({ type: 'AGE' });

// session.qrCodeUrl contains a data URL for the QR code image
// session.sessionId is the unique session identifier
// session.deepLink is for mobile-to-mobile flows

The attributes array specifies what you want to verify. eIDAS Pro is designed around privacy-first boolean attributes — you get a yes/no answer, never raw personal data:

Attribute	Returns	Description
`age_over_18`	Boolean	Is the user 18 or older?
`age_over_21`	Boolean	Is the user 21 or older?
`age_over_16`	Boolean	Is the user 16 or older?
`age_over_14`	Boolean	Is the user 14 or older?

Country compliance (which countries are allowed) is configured in your merchant settings as a whitelist or blacklist — the SDK checks this automatically without requesting personal data from the user.

Note: In DEMO mode, attributes return synthetic data. In PRODUCTION mode, the wallet cryptographically proves the boolean without revealing the underlying birth date.

Step 4: Display the QR Code

The session includes a QR code that the user scans with their EUDI Wallet app.

// In a web context
const img = document.createElement('img');
img.src = session.qrCodeUrl;
document.getElementById('qr-container').appendChild(img);

// In React
function VerificationQR({ session }) {
  return <img src={session.qrCodeUrl} alt="Scan with your EUDI Wallet" />;
}

// In Next.js (using next/image)
import Image from 'next/image';
function VerificationQR({ session }) {
  return <Image src={session.qrCodeUrl} alt="Scan with your EUDI Wallet" width={256} height={256} />;
}

Step 5: Listen for the Result

// Event-based (recommended for web apps)
service.on('verified', (result) => {
  console.log('Verification successful!');
  console.log('Verified:', result.verified);     // true
  console.log('Country allowed:', result.countryAllowed); // true (based on your whitelist)
  console.log('Session ID:', result.sessionId);
  console.log('Timestamp:', result.verifiedAt);
});

service.on('failed', (error) => {
  console.log('Verification failed:', error.reason);
  // 'timeout' | 'rejected' | 'invalid_credential' | 'network_error'
});

service.on('expired', () => {
  console.log('Session expired — generate a new QR code');
});

Or use the promise-based API:

try {
  const result = await session.waitForResult({ timeout: 120000 }); // 2 min timeout
  console.log('Verified:', result.verified);
} catch (error) {
  console.log('Failed or timed out:', error.reason);
}

Complete Example: Express.js API Route

import express from 'express';
import { VerificationService, DemoMode, InMemorySessionStore } from '@openeudi/core';

const app = express();
const service = new VerificationService({
  mode: new DemoMode(),
  store: new InMemorySessionStore(),
});

// Create a new verification session
app.post('/api/verify', async (req, res) => {
  const session = await service.createSession({ type: 'AGE' });

  res.json({
    sessionId: session.sessionId,
    qrCodeUrl: session.qrCodeUrl,
  });
});

// Check session status (or use SSE for real-time)
app.get('/api/verify/:sessionId', async (req, res) => {
  const status = await service.getSessionStatus(req.params.sessionId);
  res.json(status);
});

// SSE endpoint for real-time updates
app.get('/api/verify/:sessionId/events', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');

  service.on('verified', (result) => {
    res.write(`data: ${JSON.stringify({ type: 'verified', result })}\n\n`);
    res.end();
  });

  service.on('failed', (error) => {
    res.write(`data: ${JSON.stringify({ type: 'failed', error })}\n\n`);
    res.end();
  });
});

app.listen(3000, () => console.log('Server running on port 3000'));

What Happens in DEMO Mode?

When you run this code in DEMO mode:

A QR code is generated (visually identical to a real one)
After 3 seconds, the session automatically completes
Synthetic verification data is returned (age_over_18: true, countryAllowed: true)
Your onVerified callback fires with the result

No real wallet is involved. This lets you build and test the entire verification UI and backend flow before EUDI Wallets launch.

Next Steps

Switch to MockMode to test with configurable responses (success, failure, timeout)
Add the WooCommerce plugin to your WordPress store for checkout verification
Read the API reference for advanced configuration (custom QR styles, session options, error handling)
Join the GitHub discussions at https://github.com/openeudi to report issues or request features

When EUDI Wallets launch in December 2026, switch new DemoMode() to new ProductionMode(config) and add your WRPAC credentials — or use eIDAS Pro's managed service to skip the certificate management entirely.

OpenEUDI is MIT-licensed and available on npm today (@openeudi/core, @openeudi/openid4vp). Star the GitHub repo to follow releases.

Introducing OpenEUDI: An Open-Source SDK for EU Digital Identity Verification

eidas-pro — Fri, 29 May 2026 12:14:52 +0000

OpenEUDI is open source (MIT) and live on npm.
GitHub: https://github.com/openeudi · npm: @openeudi/core and @openeudi/openid4vp
Originally published on eidas-pro.com.

Why We're Open-Sourcing the Protocol Layer

The EU Digital Identity Wallet is coming. By December 2026, every EU member state must issue EUDI Wallets to their citizens under Regulation (EU) 2024/1183. Businesses that verify customer identities — from age-restricted e-commerce to financial KYC — will need to speak the OpenID4VP protocol to communicate with these wallets.

But here's the problem: there is no production-ready, open-source verification library for the Relying Party side.

The European Commission published a reference wallet app (the holder/citizen side), but not a reference implementation for businesses that need to verify credentials. Existing SSI toolkits like walt.id (Kotlin/JVM) and SpruceID (Rust) target generic use cases, not the specific EUDI Wallet Architecture Reference Framework.

We've been building eIDAS Pro — a managed identity verification platform — for the past year. During that work, we built a TypeScript implementation of the OpenID4VP verification protocol. We extracted that protocol layer and released it as OpenEUDI: a free, MIT-licensed SDK that any developer can use.

What OpenEUDI Is

OpenEUDI is a TypeScript library that handles the technical complexity of verifying EU Digital Identity Wallet credentials. It implements:

OpenID4VP (Verifiable Presentations) — the protocol that EUDI Wallets use to share verified attributes
SD-JWT VC verification — selective disclosure JSON Web Tokens for remote verification flows
mdoc/mDL verification — CBOR-based mobile document format for proximity verification
EU Trust List integration — certificate chain validation against member state trust services
QR code session management — generate QR codes, track session state, receive results via Server-Sent Events

import { VerificationService, DemoMode, InMemorySessionStore } from '@openeudi/core';

const service = new VerificationService({
  mode: new DemoMode(),
  store: new InMemorySessionStore(),
});

const session = await service.createSession({ type: 'AGE' });

console.log(session.qrCode); // Display to user

service.on('verified', (result) => {
  console.log(result.ageOver18); // true
});

What OpenEUDI Is Not

OpenEUDI is the protocol library, not the full production stack. To run live verifications against real EUDI Wallets (launching December 2026), you also need:

A WRPAC certificate (Wallet Relying Party Access Certificate) from a qualified trust service provider
Relying Party registration with a national authority
Production infrastructure: rate limiting, monitoring, audit logging, SLA guarantees

That's what eIDAS Pro's managed service provides. The SDK handles the protocol; the managed service handles the infrastructure.

Think of it like PostgreSQL (free, open-source database engine) vs. a managed database service (hosted, monitored, backed up). Both have value. The open-source tool gets you started; the managed service gets you to production without operational overhead.

The Open Core Model

We believe the verification protocol should be open infrastructure — like HTTP libraries or TLS implementations. Everyone benefits when the protocol layer is transparent, auditable, and community-maintained.

Our business model is straightforward:

Layer	Model	What It Includes
Protocol	Free, MIT license	OpenEUDI SDK, plugins, documentation
Infrastructure	Paid SaaS	Managed WRPAC, production API, dashboards, SLA, support

This means:

Developers can build and test verification flows for free
Businesses that want managed compliance pay for the infrastructure
The ecosystem benefits from a shared, auditable protocol implementation
Security researchers can inspect the code that handles identity verification

What's Included

Core SDK (`@openeudi/core`)

The protocol library itself: OpenID4VP request/response handling, credential verification, session management, and EU trust list parsing.

The OpenEUDI ecosystem consists of two packages: @openeudi/core handles verification session management, and @openeudi/openid4vp provides credential parsing for SD-JWT VC and mDOC formats with cryptographic signature validation.

E-Commerce Plugins

WooCommerce plugin (GPL v3) — age verification at checkout
Shopify app — Checkout UI Extension for identity verification
JavaScript widget — embeddable verification for any website

Reference Server

A demo verification server with three modes:

DEMO: auto-completes in 3 seconds for showcases
MOCK: simulated wallet responses for testing
TEST: full protocol compliance for integration testing

Documentation

Developer guides, API reference, integration tutorials, and a machine-readable EU compliance mapping (JSON) covering all 27 member states.

Built in Luxembourg

OpenEUDI is developed in Luxembourg, at the heart of Europe's fintech ecosystem. Luxembourg's strategic focus on digital identity, fintech, and regulatory compliance — combined with programmes like Fit 4 Start, LHoFT, and the SNCI — makes it the ideal base for building pan-European identity infrastructure.

Getting Started

OpenEUDI is live on npm. You can:

Install it today and build a verification flow in DEMO mode — no API keys, no WRPAC required:

   npm install @openeudi/core @openeudi/openid4vp

Star the repository on GitHub at https://github.com/openeudi
Try the live demo on the eIDAS Pro homepage to see the verification flow in action
Read the quickstart tutorial to ship your first verification in 5 minutes

What's Next

Shipped: @openeudi/core and @openeudi/openid4vp are published on npm (paired releases, currently v0.8.0)
In progress: WooCommerce and Shopify plugins
Toward the EUDI Wallet launch: production-mode verification aligned with national wallet availability
Ongoing: community contributions, additional framework integrations, language bindings

We're building OpenEUDI in the open. If you're working on EUDI Wallet integration, identity verification, or EU regulatory compliance, we'd love to hear from you.

OpenEUDI is MIT-licensed and free forever. The eIDAS Pro managed service provides production infrastructure, WRPAC certificates, and SLA guarantees for businesses that need managed compliance.

eIDAS Summit 2026 Berlin: 5 Takeaways for Merchants

eidas-pro — Thu, 30 Apr 2026 18:18:09 +0000

Updated 8 May 2026 with post-Summit notes — see the section at the end of this post. The framing below reflects the agenda as published on 27 April 2026.

The Bitkom eIDAS Summit ran 28–29 April 2026 in Berlin. Day 1 was on-site at the Representation of the State of Baden-Württemberg, in German, with a national focus. Day 2 was English and online for a European audience. The keynote line-up was heavier than any previous edition: Federal Digital Minister Dr. Karsten Wildberger for BMDS, Norbert Sagstetter for the European Commission's Digital Identity Unit, Dr. Markus Reichel as rapporteur from the CDU/CSU group, and Christina Raab (Bitkom Vice President, Accenture DACH CEO) opening the industry side.

The reason this Summit is worth a separate post is not the keynote roster. It is the way the agenda has been structured.

Earlier eIDAS Summits were protocol-led — sessions on OpenID4VP, on mDoc, on selective disclosure, on cryptographic suites. This one is sector-led: the published programme tracked country wallet demos, large-scale pilots, the European Business Wallet, accessibility, trust services in the cloud, content credentials, and age verification as the structural lens.

That shift is the signal. Five takeaways every relying party and merchant should leave with — even those who never logged into the live stream.

1. Sector-specific use cases are now the lens

The Day 2 programme tracked sectors, not protocols. Country wallet demos. Large-scale pilots. The European Business Wallet. Accessibility. Trust services in the cloud. Content credentials. Age verification. That structure tells you who Day 2 is for: relying parties making integration decisions in the next 8 months, not standards bodies refining the spec.

For merchants, the implication is simple. The integration scope is no longer "implement OpenID4VP." It is "implement the wallet in your checkout, with your fallback flow, your support training, your localization, your pre-warming sequence." The protocol is settled. The integration is not.

2. The 100-company MoU is your integrator directory

Germany's Federal Ministry for Digital and State Modernisation (BMDS) signed a Memorandum of Understanding with 100+ companies on 28 April. The signatories include the major German banks, telcos, healthcare systems, transport companies, and a long tail of integrators.

If you are a relying party trying to figure out who can deliver a wallet integration that actually ships in 2026, this list is the answer. It is not a procurement guarantee — these are MoU signatories, not a vetted supplier list — but it is a discovery shortcut. If your integrator is not on it, ask why. If they are, ask which other signatories they have already worked with.

3. The European Business Wallet is the B2B sibling

The European Business Wallet got real airtime on Day 2. It is the B2B sibling to the citizen wallet — same protocol stack, different attribute set, different relying-party expectations.

Most merchants who covered the Summit last week ignored the EBW. Don't. Procurement workflows, supplier onboarding, KYB (know-your-business), B2B authentication, regulated cross-border B2B services — all of these become wallet-native in 2027. The B2C wallet rollout gets the headlines; the B2B wallet rollout gets the durable margin.

4. Germany's 2 January 2027 launch sets the cross-border tone

Germany goes live first. First wallet in production, first relying-party register, first regulated verticals binding. Whatever Germany ships becomes the de-facto standard that every other member state's national wallet has to interoperate with.

For merchants outside Germany, the implication is concrete: even if your home market launches in mid-2027 or 2028, your German customers will arrive with a wallet on 2 January 2027. Cross-border verification flows become the binding constraint, not the German market alone.

5. The policy/merchant gap is now visible

The biggest signal from Day 2 is the gap that nobody on stage named directly. The Bitkom 13 April survey put 52% of Germans at "never heard of the EUDI Wallet" and 5% at "can explain it." Day 2 framed the awareness gap as a marketing problem — something for BMDS, the Commission, and Bitkom to address with public campaigns.

It is not. It is a checkout problem. The 5% who can explain the wallet on 2 January 2027 will be over-represented in your funnel from day one — they are the early adopters, the privacy-conscious, the technically-curious. The other 95% will arrive with confusion. They will need plain checkout copy, a fallback flow, FAQ answers, and support training.

Merchants who treat this as a marketing-department noise will hand their first 12 months to competitors. Merchants who treat it as integration scope will spend Q1 2027 watching an unfamiliar button outperform every legacy verification path they have ever shipped.

Post-Summit notes — 8 May 2026

Five things changed between the Summit's close on 29 April and the second week of May. Each one shifts the merchant-side reading of the agenda above.

One — the activation gap reframed the Bitkom story. Bitkom's follow-up survey on 27 April shifted the headline from "52% never heard of it" to "54% would use it but only 18% have an activated eID with a working PIN." The Summit's communications-track sessions, written for the awareness gap, landed in the room against an activation gap that is harder to close. We unpack the implications for merchants in our activation-gap post.

Two — ENISA's hardest quote arrived on 28 April. The public-review draft of the EUCC for EUDI Wallets carried the single most consequential admission from the cybersecurity track: "In early 2026, no EUDI Wallet has been deployed or certified, and the specification remains work in progress." Biometric Update's coverage frames the implications for the end-2027 Article 5f acceptance deadline.

Three — member states broke ranks on the EU age-verification app. The Commission's 29 April recommendation to deploy a white-label EU AV app drew immediate pushback from Germany, Ireland, France, Poland, and Estonia, with Germany routing age verification through the wallet's age attribute instead. The political track formalised on 6 May in Council document 8985/26. Full analysis in our member-state fragmentation post.

Four — the cross-border critique sharpened. Mirko Mollik's "Worthless outside Europe?" (3 May), written from IIW Mountain View, surfaced what the Summit underplayed: outside the EU, the wallet is being routed around rather than through. For B2B and globally-active relying parties, a meaningful 2027 planning input.

Five — civil-society critique consolidated. The epicenter.works "five problems" open letter (3 May) pulled together the substantive privacy critiques into one document. Two of the five — registration-certificate over-asking and weakened pseudonymity — touch the relying-party flow directly and are worth a read regardless of where you sit on the framing.

Net for a Q3-2026 integration roadmap: the activation-gap and member-state-fragmentation stories are the two takeaways that change the build order. The ENISA admission and the cross-border critique are useful priors for risk language in internal stakeholder discussions but do not, by themselves, alter the integration plan.

What to do Monday morning

We packaged the merchant decision into 5 questions. Score yourself.

Are you in scope under Article 5f? Which paragraph applies?
Have you mapped your wallet relying-party registration path?
Have you scoped your attributes to the minimum needed?
Is your wallet+fallback flow designed and tested?
Have you tested against at least two wallet implementations?

5/5 → on track for a clean Q1 2027 launch. 3–4/5 → at risk. 0–2/5 → treat 2027 as a build year, not a launch year.

Full readiness checklist: https://eidas-pro.com/blog/eudi-wallet-readiness-checklist-merchants-5-questions

Why we wrote this

We are eIDAS Pro. We build EUDI Wallet verification infrastructure for merchants — drop-in checkout integrations, fallback flows, sector-specific support training, and the open-source SDK that powers them (@openeudi/core, @openeudi/openid4vp, Apache 2.0).

If you are 8 months from launch and behind on integration scope, we can help. If you are not behind, we want to learn what you got right.

Source: https://eidas-pro.com/blog/eidas-summit-2026-berlin-bitkom-merchant-takeaways

EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened

eidas-pro — Sat, 18 Apr 2026 19:06:10 +0000

On April 15, 2026, the EU launched the age verification "mini-wallet" app. Within 24 hours, security researcher Paul Moore published a video claiming he bypassed it in 2 minutes. The story went viral across Reddit with tens of thousands of upvotes.

The headlines write themselves, but the technical reality is more nuanced.

The Three Flaws

Paul Moore identified three design flaws in the wallet app's local device implementation:

1. PIN decoupled from the credential vault

The PIN protecting the wallet is verified locally, separate from the cryptographic key store that holds the actual credentials. On a rooted device, the PIN can be brute-forced without triggering the key store's protections.

2. Rate limiting stored as plaintext

Lockout counters that prevent repeated PIN attempts are stored as plaintext values in local storage. With root access, these counters can be reset directly.

3. Biometric gate is a boolean flag

The biometric authentication check resolves to a simple boolean value. On a rooted device, this flag can be toggled without actually completing biometric verification.

What Remains Secure

All three bypasses share a critical prerequisite: physical access to a rooted device. None of them enable remote attacks.

More importantly, the OpenID4VP protocol that governs the actual verification transaction between wallet and verifier was not compromised. When a verifier checks someone's age, they validate cryptographic proofs signed by the PID (Person Identification Data) provider. These signatures cannot be forged through any of the three local bypasses.

For developers building age-gated services:

The signed attestations your backend validates are still trustworthy
No changes needed to your verification integration
The privacy model (verifiers receive yes/no, never the actual birthdate) is intact

Implementation vs. Protocol

This is a textbook case of the distinction between protocol soundness and implementation quality. The cryptographic architecture — based on OpenID4VP credential presentation — is well-designed. The local device protections that guard access to the wallet were implemented with shortcuts.

The fixes are straightforward:

Bind PIN verification to the hardware key store
Move rate limiting into the secure enclave
Replace the boolean biometric flag with a challenge-response tied to the key store

None of these require protocol-level changes.

The Structural Concern

The bigger issue is platform lock-in. The wallet app only runs on iOS and Android, with a hard dependency on Google Play Services. There is no libre client, no desktop version, and no way for users of alternative mobile platforms to participate.

For a system mandated by EU regulation, this exclusivity raises legitimate accessibility and sovereignty questions that outlast the fixable implementation bugs.

The Positive Signal

Open-source security auditing worked exactly as designed. The code was auditable, a researcher found flaws on day one, and published them responsibly. This is the model functioning correctly.

Full technical analysis with more detail on the protocol and platform lock-in concerns: EU Age Verification App Hack Explained