Developers · OpenID Connect · OpenID4VP · ARF 3.0
EUDI wallet integration: EU Digital Identity Wallet sign-in for your website
Your application keeps its normal OpenID Connect sign-in. The CodeB EUDI Gateway on phone.codeb.io speaks OpenID4VP, SD-JWT VC and ISO mdoc to the wallet, checks the presentation and hands you a signed id_token. You add one parameter and one check.
- Any OpenID Connect library
- One parameter, one check
- Tested samples for seven stacks
How it works
- Your app redirects to CodeB with client_id, PKCE (S256), state, nonce and
acr_values=urn:codeb:acr:eudi-wallet. - CodeB opens the wallet sign-in: on a phone the wallet opens directly; on a computer the person scans a QR code with the phone that holds the wallet.
- The wallet presents, CodeB verifies over OpenID4VP: issuer signature and trust chain, holder binding and revocation status.
- CodeB returns an authorization code to your redirect URI.
- Your server exchanges the code, validates the id_token and checks the
acrclaim. The person is signed in.
The two rules
1. Ask for the wallet: add acr_values=urn:codeb:acr:eudi-wallet to the authorization request.
2. Check before you grant access: the acr claim of the validated id_token must be urn:codeb:acr:eudi-wallet or urn:codeb:acr:eudi-wallet-linked. A password sign-in has another value and must be refused.
What you need
A registered client: CodeB registers your redirect URIs and sends you a client ID and secret (info@aloaha.com). Your name, purpose and privacy policy go into the registration certificate the wallet shows.
The discovery document: https://phone.aloaha.com/.well-known/openid-configuration for your real integration – authorization, token, UserInfo and JWKS endpoints, supported scopes, claims and acr values. For tests and demos: phone.codeb.io.
A server-side component that keeps the client secret (authorization code flow with PKCE).
Tested samples and references
Complete sample apps for ASP.NET Core 8, Visual Basic .NET, Node.js, Python, PHP, Java and Go, each tested against a provider that mirrors the CodeB endpoints: integration cookbook. A shorter start: developer quickstart. Visual Basic .NET: sample.
API reference: EU wallet API and the OpenAPI description.
No back end yet? The sign-in widget puts a “Sign in with EU Wallet” button on a page with one script tag.
More than sign-in
Age only: ask for “over 18” and nothing else – age verification.
National eID card: the same integration with acr_values=urn:codeb:acr:eidcard – sign-in with the card’s authentication key, read over NFC by CodeB Wallet.
Test any wallet: the interoperability self-test shows which requirements a wallet meets. Try the flows yourself on the playground.
Designed to follow ARF 3.0, OpenID4VP 1.0 and HAIP 1.0; not certified.
Tested against the standards
What does this mean? The CodeB issuer is the service that puts cards into your wallet – your digital ID, membership and sign-in cards. The verifier is the service that checks those cards when you sign in with them. So that issuers, wallets and services across Europe understand each other, they all have to follow the same rulebook – like a plug and a socket: if one side is built differently, nothing fits.
The official test lab checks exactly that. It plays the part of a wallet and runs more than 250 tests against our live service – whether every step follows the rulebook, and whether forged, tampered or replayed requests are refused. In November 2026 our issuer passed all four test plans for issuing cards, and our verifier passed both test plans for checking them, with no failed test.
We are proud of this. It shows what more than 20 years of development in PDF, smart cards and digital identity – and always building strictly to the standards – are worth: when the rulebook is followed from the first line, the tests confirm it.
For you this means: your cards speak the same language as every wallet and service that follows the European rulebook, instead of being locked to one app, and their protection has been tested, not just promised. Which cards a wallet or service accepts is still decided by certificates and trust lists.
Technically: OpenID4VCI 1.0 and OpenID4VP 1.0 with the HAIP 1.0 profile – the standards on which the EUDI wallets are built. The test plans are the same independent test suites that are used for the official certification of these protocols. These are tests of our servers on phone.codeb.io, not a certification of CodeB Wallet itself. Each result can be viewed read-only via its link.
| Test plan | Format | Result |
|---|---|---|
| Issuer: OpenID4VCI 1.0 + HAIP 1.0, wallet-initiated | SD-JWT VC | Passed · 63 tests, no failure · view results |
| Issuer: OpenID4VCI 1.0 + HAIP 1.0, wallet-initiated | mdoc | Passed · 63 tests, no failure · view results |
| Issuer: OpenID4VCI 1.0 + HAIP 1.0, issuer-initiated (credential offer) | SD-JWT VC | Passed · 63 tests, no failure · view results |
| Issuer: OpenID4VCI 1.0 + HAIP 1.0, issuer-initiated (credential offer) | mdoc | Passed · 63 tests, no failure · view results |
| Verifier: OpenID4VP 1.0 + HAIP 1.0, direct_post.jwt | SD-JWT VC | Passed · 14 tests, no failure · view results |
| Verifier: OpenID4VP 1.0 + HAIP 1.0, direct_post.jwt | mdoc | Passed · 7 tests, no failure · view results |
Developer questions
Do we have to implement OpenID4VP, SD-JWT VC or ISO mdoc ourselves?
No. The gateway speaks the wallet protocols and checks signatures, trust chains, holder binding and revocation. Your application sees a standard OpenID Connect sign-in.
Which OpenID Connect library can we use?
Any library that supports the authorization code flow with PKCE and reads the discovery document. Tested samples exist for ASP.NET Core, Visual Basic .NET, Node.js, Python, PHP, Java and Go.
How do we know the person really used the wallet?
Check the acr claim of the validated id_token: urn:codeb:acr:eudi-wallet or urn:codeb:acr:eudi-wallet-linked. Refuse every other value for pages that need the wallet.
Which personal data do we receive?
Only what you ask for, what your client is allowed and what the person approves in the wallet – for example name or date of birth.