Register your service
We register your redirect URI(s) and send you a client ID and secret. Your relying party details – name, purpose, privacy policy, contact – go into the registration certificate that wallets show.
Product · EU Digital Identity Wallet · Relying party
Your customers sign in, open an account or prove their age with their EU Digital Identity Wallet – and your application sees nothing but a standard OpenID Connect sign-in. The gateway does the wallet protocols, the cryptography, the trust lists and the revocation checks.
acr_values=urn:codeb:acr:eudi-wallet, it asks the wallet over OpenID4VP, verifies the presentation, and returns a signed OpenID Connect id_token with the approved attributes to your application.OpenID Connect · OpenID4VP 1.0 + DCQL · HAIP 1.0 · SD-JWT VC · ISO mdoc · ETSI TS 119 475 · ARF 3.0
Closed beta, in testing. Not certified.
acr (how the person signed in) and the attributes you ask for and the person approves.Four steps, two of them once.
We register your redirect URI(s) and send you a client ID and secret. Your relying party details – name, purpose, privacy policy, contact – go into the registration certificate that wallets show.
Your existing OpenID Connect sign-in sends the user to the gateway with acr_values=urn:codeb:acr:eudi-wallet.
On a phone the wallet opens directly; on a computer the person scans a QR code. The wallet shows who asks and why; the person approves.
Issuer signature and trust chain, holder binding, revocation status, nonce and audience – then your app gets a signed id_token with acr and the approved attributes.
OpenID for Verifiable Presentations 1.0 with DCQL queries, same-device (the wallet opens directly) and cross-device (QR code), responses encrypted with direct_post.jwt.
SD-JWT VC and ISO mdoc – the EU PID in both formats, the EU proof-of-age attestation and other attestations, with holder binding and selective disclosure.
Issuer signatures and trust chains against the EU trusted lists, revocation status via Token Status Lists, nonce, audience and lifetime of every presentation.
Signed requests (x509_hash as required by HAIP 1.0) and a registration certificate per ETSI TS 119 475 with your name, purpose, privacy policy and status list – the wallet shows the person who is asking.
Authorization code + PKCE, id_token with acr and amr, UserInfo, logout – like any OpenID Connect provider. Any library works.
The same integration with acr_values=urn:codeb:acr:eidcard: sign-in with the card’s authentication key, read over NFC by the CodeB Wallet app.
Customers sign in with their wallet – phishing-resistant, no password resets, no SMS codes.
Name, date of birth and other PID attributes arrive verified from the wallet instead of a form; the passport or ID card chip can be checked as well.
Ask for “over 18” only, without name or date of birth – with the EU proof-of-age attestation.
A factor you do not have to run yourself: keys in the phone’s secure hardware, unlocked with biometrics or a PIN.
Follows the EU Architecture and Reference Framework 3.0, OpenID4VP 1.0 and HAIP 1.0; tested with conformance test plans and a public interoperability self-test. Not certified.
Deletion requests (ARF Technical Specification 7) through a public endpoint, reports to the data protection authority (Specification 8), and contact details in the registration certificate.
No third-party analytics, no ad networks. The sign-in runs between the wallet, the gateway and your application.
With an access certificate from an official registrar or – for test and private ecosystems – from the CodeB access-certificate CA with its own relying-party register.
In the European Digital Identity framework, a relying party is any service that asks a person to present data from their EU Digital Identity Wallet – to sign in, to open an account, to prove an age or a qualification. The CodeB Relying Party Gateway does that work for your website or app.
Under the revised eIDAS Regulation (EU) 2024/1183, private services that are required by law to use strong user authentication – for example in banking, payments, telecoms, transport, energy, health and education – and very large online platforms must accept the wallet when the user chooses it. The obligation applies within 36 months of the wallet implementing acts entering into force, i.e. around the end of 2027. Check the details for your sector with your legal adviser; this is not legal advice.
If your site already uses OpenID Connect, typically an afternoon: register your redirect URI with us, add one parameter (acr_values=urn:codeb:acr:eudi-wallet) and check one claim (acr) in the id_token. The developer quickstart has complete samples.
No. The gateway speaks the wallet protocols (OpenID for Verifiable Presentations 1.0 with DCQL, SD-JWT VC and ISO mdoc) and checks signatures, trust chains, holder binding and revocation. Your application only sees a standard OpenID Connect sign-in.
Only what you ask for and what the site operator allows for your client: for example given name, family name, date of birth or e-mail, taken from the presented credential. Data minimisation is built in – the wallet discloses only the requested attributes (selective disclosure), and the person sees and approves the request.
Every request is signed with an access certificate and carries a registration certificate (ETSI TS 119 475) that names the relying party, its purpose, its privacy policy and how to request deletion. Wallets show this to the person before anything is shared, and can check its status online.
Wallets that implement OpenID for Verifiable Presentations 1.0 and the HAIP 1.0 profile, such as the CodeB Wallet and the EU reference wallet. Documents: the EU Person Identification Data (PID) as SD-JWT VC or ISO mdoc, plus attestations such as the EU proof-of-age attestation. National eID cards can be used for sign-in through the CodeB Wallet app.
No. The gateway is designed to follow the EU Architecture and Reference Framework (ARF) 3.0, OpenID4VP 1.0 and HAIP 1.0, and is tested against conformance test plans; it is not certified, and it does not claim an eIDAS level of assurance.
Yes. Requests can be signed with an access certificate from an official registrar, or – for test and private ecosystems – with one from the CodeB access-certificate CA and its own register of relying parties.
Code for Node.js, Python, PHP and ASP.NET Core.
Complete apps for six stacks, tested against the gateway.
OpenID4VP endpoints, registration certificate, deletion requests.
The EU proof-of-age attestation: over 18, nothing else.
Write to us: we register your service, set up your client and help with the first sign-in.