RP integration example: eudi-verify (built on @openeudi/core)

[mkascel]

Hey, I've built eudi-verify on @openeudi/core — widget + API for relying parties. Demo: https://demo.eudi-verify.eu/

Would you be OK linking it from your README as an integration example? Also happy to pitch in on OpenEUDI maintenance if that's ever useful.

[BetelGuese]

Thanks @mkascel — eudi-verify looks great, and it's nice to see @openeudi/core used as a pluggable engine.

README link: happy to add it under a Community integrations section. I'll note it as a third-party project (rather than an audited/official one) so expectations are clear. Could you add a line in the eudi-verify README noting it builds on @openeudi/core, so the reference is reciprocal?

Maintenance offer: genuinely appreciated. The best starting point is contributing PRs — there are a couple open right now and some good areas to help with (algorithm coverage, test hardening). If that goes well I'm very open to bringing on co-maintainers down the line.

On security, generally: we take it seriously across the org — Private Vulnerability Reporting is now enabled on all OpenEUDI repos, so please use each repo's "Report a vulnerability" button for anything security-sensitive. As a general note for any verifier built on this stack: if you depend on @openeudi/openid4vp directly, keep an eye on its security advisories and stay on the latest release. Standard hygiene, but worth stating for a verification library.

Thanks again for building on OpenEUDI!

[mkascel]

Hey @BetelGuese - quick clarification/update from my side: when I opened this issue, I described eudi-verify as being built on @openeudi/core, but that wording got slightly ahead of the actual implementation.

eudi-verify's verifier backend is designed around a pluggable VerifierEngine, and @openeudi/core is the engine I intend to integrate for real wallet/OpenID4VP flows. The current demo still uses a simulated engine.

I'm at the point where I'm ready to implement the @openeudi/core adapter, which will wrap your IVerificationMode strategies (DemoMode/MockMode) behind my engine interface, while keeping my own session/token layer so the engine stays swappable. I'll update this issue once that integration is working, and I'd be glad to add the reciprocal "built on @openeudi/core" line to my README as suggested!

One design question while I build the adapter: in 0.8.0, VerificationResult exposes age-over-18 + country. Is broadening to other PID attributes (e.g. given_name/family_name/birth_date) or configurable age thresholds (over-21) on the roadmap, or is the age+country scope an intentional data-minimization choice? Either answer is useful, I'd rather shape my claim mapping to match your direction than fork around it.

Once I integrate this and become more familiar with the packages I'll have a look at your Issues and see where I can help out.

Thanks again!

[mkascel]

First pass at the integration has landed in main and reciprocal README line is in: link. openeudi/core is also my intended primary engine for production once the OpenID4VP path lands. No action needed, just closing the loop for whenever you add an integrations entry.

[mkascel]

Hey @BetelGuese, closing the loop on the production integration: eudi-verify/eudi-verify#37

eudi-verify now runs two engines behind the same VerifierEngine interface: OpenEudiEngine (demo, @openeudi/core DemoMode, unchanged) and a new Openid4vpEngine on @openeudi/openid4vp for real production verification. Both are live on https://demo.eudi-verify.eu/ and documented in the README and SUPPORTED.md

Got it working end-to-end against an EU Age Verification reference wallet on iOS: mso_mdoc age-over-18 attestation, plain direct_post (no JWE), client_id=redirect_uri:<callback>. QR to wallet to my /callback to age_over_18: true to HMAC token. Also added negative tests mutating clientId/responseUri/nonce in the SessionTranscript binding to make sure those get rejected.

One thing worth flagging: with plain direct_post there's no apu, so the library can't auto-build the mdoc transcript. What worked for me was the OpenID4VP 1.0 Final unencrypted handover (jwkThumbprint = null). I can send a small docs/example PR upstream if that'd help other RPs hit the same wall.

Also, @openeudi/openid4vp pulls in @peculiar/x509, which needs reflect-metadata at runtime (tsyringe), but it's only a transitive/dev dep. I ended up pinning it directly and importing it before the engine to keep ESM load order sane. Might be worth calling out in the docs.

Trust checks are currently skipTrustCheck in the lab (double-gated, trustLevel: none); I've got an injectable TrustStore/StaticTrustStore for when LOTL-style trust is ready, but that's still on the roadmap, not live.

No pressure on the README link, whenever it makes sense for you. Thanks again for the library, the integration went pretty smoothly!

[BetelGuese]

Hey @mkascel — this is fantastic to see, thank you for closing the loop so thoroughly. Running both engines behind one VerifierEngine interface, negative tests on the SessionTranscript binding, end-to-end against a real EU Age Verification wallet — that's genuinely great work, and the reciprocal README line is much appreciated. 🙏

On your questions:

PID attributes / age thresholds: Great question, and I'm glad you asked before mapping claims. The age-over + country scope is an intentional data-minimization choice rather than an unfinished one — keeping the disclosed surface as small as possible is really the whole point of the library, and it lines up with the direction eIDAS 2.0 and the EU Age Verification profile are pushing (attestation of an attribute, not raw identifiers). So:

• Configurable age thresholds (over-21, over-16, …) are very much in the spirit of the project and something we're open to extending toward — same minimal shape, just a different threshold.
• Identity attributes (given_name/family_name/birth_date) we'd rather keep deliberately out of the default result. If a full-PID presentation use case comes up it'd be a separate, explicitly opted-into path rather than a widening of the age result — I'd hate for the minimal default to erode by accident.

Shape your claim mapping around the minimal result and you'll be aligned with where we're headed.

direct_post docs/example PR: Yes please — that'd be really valuable. The unencrypted-handover wall (no apu, jwkThumbprint = null) is exactly the kind of thing other RPs will hit, and having it documented from a real integration is the best possible source. Very happy to review it.

reflect-metadata: Thanks for flagging this — that one's on us rather than something you should have to work around. It's an @openeudi/openid4vp concern (the tsyringe → decorator-metadata chain via @peculiar/x509), and the right fix is on our side: load the polyfill at the package entry point and make it a direct dependency so the load order just works. I'll track that against openid4vp so future consumers don't have to pin and import it manually.

Really appreciate you building on OpenEUDI so carefully — and no rush at all on anything here.

[BetelGuese]

Quick follow-up on the reflect-metadata point, @mkascel — this is now fixed upstream in @openeudi/openid4vp@0.9.2 (just published to npm).

The package now imports the reflect-metadata polyfill at its own entry point and declares it as a runtime dependency, so the @peculiar/x509 → tsyringe decorator-metadata chain is satisfied before anything evaluates. The side-effect import is emitted in both the ESM and CJS builds, so it loads regardless of how you wire things up.

Net effect for you: on 0.9.2 you can drop the manual reflect-metadata pin and the pre-engine import — it just works out of the box. (Keeping them won't hurt either; the polyfill is idempotent.)

Thanks again for flagging it — that was a real footgun for anyone not already running a DI framework, and your report is exactly what got it fixed. 🙏

[mkascel]

Thanks for shipping @openeudi/openid4vp@0.9.2! I've updated eudi-verify to depend on @openeudi/openid4vp@0.9.2 and dropped the package-root polyfill import; I still preload once before importing the library because the ESM bundle evaluates @peculiar/x509 before reflect-metadata in dist/index.js. Minor follow-up if useful.

Public interop notes are up: https://github.com/eudi-verify/eudi-verify/blob/main/docs/INTEROP.md

For leaving skipTrustCheck: is StaticTrustStore + acceptance/national CAs the near-term path, or LOTL-first?