Product · EU Digital Identity Wallet · Relying party

CodeB Relying Party Gateway: the EU Wallet on your website

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.

In one sentence: The CodeB Relying Party Gateway is a relying party service for the EU Digital Identity Wallet: your website redirects to it with 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.

In short

What
A relying party service: it receives and verifies presentations from the EU Digital Identity Wallet on behalf of your website.
For whom
Banks, payment services, telecoms, insurers, health, mobility, public services, platforms – any service that must recognise people securely or check their age.
Integration
Standard OpenID Connect (authorization code + PKCE). One extra parameter, one extra check. Samples for Node.js, Python, PHP, ASP.NET Core, Java and Go.
What you get
A signed id_token with acr (how the person signed in) and the attributes you ask for and the person approves.
Trust
Signed requests with an access certificate, a registration certificate with online status, EU trusted lists, revocation checks, encrypted responses.
Privacy
Selective disclosure, no third-party trackers, deletion requests through a dedicated endpoint.

How it works

Four steps, two of them once.

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.

Add one parameter

Your existing OpenID Connect sign-in sends the user to the gateway with acr_values=urn:codeb:acr:eudi-wallet.

The person presents

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.

The gateway verifies

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.

What the gateway does for you

Wallet protocols

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.

Credential formats

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.

Trust and revocation

Issuer signatures and trust chains against the EU trusted lists, revocation status via Token Status Lists, nonce, audience and lifetime of every presentation.

Your identity in the wallet

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.

A standard sign-in for your app

Authorization code + PKCE, id_token with acr and amr, UserInfo, logout – like any OpenID Connect provider. Any library works.

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 the CodeB Wallet app.

What relying parties use it for

Passwordless sign-in

Customers sign in with their wallet – phishing-resistant, no password resets, no SMS codes.

Account opening

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.

Age checks

Ask for “over 18” only, without name or date of birth – with the EU proof-of-age attestation.

Strong authentication

A factor you do not have to run yourself: keys in the phone’s secure hardware, unlocked with biometrics or a PIN.

Security, privacy, conformity

Designed for ARF 3.0

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.

Data subject rights

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 trackers

No third-party analytics, no ad networks. The sign-in runs between the wallet, the gateway and your application.

Access certificates

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.

Frequently asked questions

What is a relying party?

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.

Do we have to accept the EU Digital Identity Wallet?

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.

How long does the integration take?

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.

Do we have to implement OpenID4VP, SD-JWT VC or ISO mdoc ourselves?

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.

Which personal data do we receive?

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.

Who is shown to the person in the wallet?

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.

Which wallets and documents work?

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.

Is it certified?

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.

Can we use our own access certificate?

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.

The EU Wallet on your website?

Write to us: we register your service, set up your client and help with the first sign-in.