Which specs does CodeB implement for European Digital Identity Wallet integration?

OpenID for Verifiable Presentations (OID4VP) FINAL, OpenID for Verifiable Credential Issuance (OID4VCI) Draft 15, SD-JWT VC (draft-ietf-oauth-sd-jwt-vc), ISO/IEC 18013-5 mso_mdoc, and the High Assurance Interoperability Profile (HAIP). Upstream reference: docs.eudi.dev.

Do you ship official EU Commission endorsement?

No. CodeB is not endorsed by the European Commission. These integration guides implement public EUDI-ecosystem specifications and reference the upstream docs at docs.eudi.dev.

Does the verifier flow enforce Wallet Attestation?

Optional per tenant. Set Oidc:WalletAttestationRequired=true on the tenant to require HAIP section 5.11 wallet attestation on every presentation.

Ecosystem integrations

Build for the European Digital Identity Wallet with CodeB.

Whether you are a Relying Party asking for a presentation, a public authority issuing credentials, a wallet vendor publishing your Wallet Attestation trust anchors, or an operator running a national trust list — the endpoints, snippets, and drop-in scripts below hook straight into the European Digital Identity Wallet ecosystem. The upstream reference is docs.eudi.dev; nothing on this page is endorsed by the European Commission.

Honest scope. CodeB ships OID4VP FINAL, OID4VCI Draft 15, SD-JWT VC, mso_mdoc, and HAIP section 5.11 Wallet Attestation today.

Pick your role

Verifier / Relying Party

Ask for a presentation from a holder's wallet. Poll for completion, read claims.

Setup JS snippet React hook

Issuer

Mint SD-JWT VC or mso_mdoc credentials for holders via OID4VCI credential offers.

Setup SD-JWT offer mdoc offer

Wallet provider

Publish Wallet Attestation JWKS / PEM so verifiers can enforce HAIP §5.11.

Setup JWKS sample

Trust-anchor operator

Supply LOTL, SD-JWT-VC issuer, or mDoc issuer certificates to the verifier trust store.

Setup Full HAIP guide

Verifier setup

Every verifier flow uses the same three moves against the CodeB tenant: vp-start to open a presentation session, render the returned deep link (QR or native invocation), then poll vp-status until the wallet completes it.

1. Open a session

POST /oidc.ashx?action=vp-start&query=<NAME> Response 200 application/json: { "id": "vps_...", "request_uri": "https://<CODEB_TENANT_HOST>/oidc.ashx?action=vp-request&id=vps_...", "deep_link": "openid4vp://?client_id=<VERIFIER_ID>&request_uri=..." }

2. Render the deep link

Convert deep_link to a QR code for desktop flows, or invoke it directly on mobile. The deep link uses the openid4vp:// scheme (or haip:// when the tenant is configured for HAIP).

3. Poll for completion

POST /oidc.ashx?action=vp-status&id=<id> Response 200 application/json: { "status": "waiting" | "completed" | "expired" | "error", "claims": { "sub":"...", "given_name":"...", "eudi_verified": true, ... } }

4. Copy-paste JS

The vanilla-JS snippet handles the render + poll cycle. It exports one function:

CodeBVerifier.startSignIn({ query: "pid-minimal", mount: document.getElementById("qr"), onDone: function (claims) { /* your handler */ } });

A React hook variant lives at verifier-react-hook.jsx. Framework-scoped wrappers for Vue and Angular ship on the verifier integration cookbook.

Issuer setup

The issuer flow follows OID4VCI Draft 15. You declare which credential types your tenant supports, mint a credential offer per holder, and hand the wallet a openid-credential-offer:// deep link.

1. Declare supported VCTs

Drop VCT metadata JSON files under App_Data/<tenant>/vci/, or use the vci-admin UI. Each VCT declares its credential format (vc+sd-jwt or mso_mdoc), claims, and cryptographic constraints.

2. Mint a credential offer

POST /vci.ashx?action=credential-offer Body: { "credential_configuration_ids": ["codeb-org-employee-sd-jwt-vc"], "holder_hint": { "email": "alice@example.com" } } Response 200: { "credential_offer_uri": "https://.../vci.ashx?action=offer&id=of_...", "deep_link": "openid-credential-offer://?credential_offer=..." }

3. Ready-to-copy credential offer JSON

Two sample offers ship in /downloads/eu-wallet/:

issuer-credential-offer-sample.json - SD-JWT VC with pre-authorized-code grant (single-use bearer, no PIN).
issuer-credential-offer-mdoc-sample.json - mso_mdoc PID with authorization_code flow.

Wallet-provider setup

Wallet providers publish the public keys that sign HAIP section 5.11 Wallet Attestation JWTs, so RPs can enforce that a presentation actually came from a specific wallet product.

1. Publish your JWKS

Static file at https://<YOUR_WALLET_DOMAIN>/.well-known/wallet-provider.jwks.json. A shape sample lives at wallet-provider-jwks.json.

2. Deposit at the tenant

The tenant operator drops the JWKS (or the equivalent X.509 PEM) under:

App_Data/<tenant>/trust/wallet-providers/<wallet-provider-id>.jwks.json

3. Enforce Wallet Attestation

Set Oidc:WalletAttestationRequired=true on the tenant to reject presentations that lack a valid HAIP §5.11 attestation JWT. The testscripts/wallet-attestation-smoke.py probe exercises the full path.

Trust-anchor setup

Verifier tenants need three distinct trust stores: the EU List of Trusted Lists (LOTL) for eIDAS certificate chains, an SD-JWT VC issuer set, and an mDoc issuer set. Each stores its inputs under App_Data/<tenant>/trust/ as PEM / JSON / DER.

The end-to-end operator walk-through, including nightly reconciler + wacs cert refresh, lives on the dedicated HAIP operator setup page. This section is intentionally short: the operator page is the source of truth.

Deep-link builder (test harness)

Build a quick openid4vp:// or openid-credential-offer:// URL for wallet interop testing. Nothing here is sent to a server — this is a pure client-side helper. The same logic lives in openid4vp-deep-link-builder.js.

Scheme client_id request_uri state (opt) nonce (opt)

(URL will appear here)

Reference: docs.eudi.dev for upstream EU Digital Identity Wallet reference implementations and protocol profiles.

Developer cookbooks: OIDC sign-in - JWT validation - M2M API keys - Webhooks