EU Digital Identity Wallet · Architecture
CodeB covers the whole European Digital Identity Wallet chain: from reading a passport chip to issuing the PID, from the wallet on the phone to the website that asks for it, from a signature to its validation. Click a box to see what it does, or play a flow to see how the parts work together.
ARF 3.0 · OpenID4VCI 1.0 · OpenID4VP 1.0 · HAIP 1.0 · SD-JWT VC · ISO mdoc · ETSI TS 119 475 · ICAO 9303
Pick a flow: the picture highlights the parts involved and the steps below walk through it.
Click a box for details. Arrows show who sends what to whom. On a small screen, swipe the picture sideways.
The same modules as in the picture, as a list.
Trust anchors every side checks against: the EU list of trusted lists for issuers and wallet providers, and the master list of the authorities that sign passports and ID cards (with their revocation lists). Kept up to date automatically. More →
Every credential and every wallet carries a pointer into a status list. When a phone is lost or a credential is withdrawn, the bit flips and every relying party sees it on the next check – without learning who else was checked. More →
Relying parties sign each wallet request with an access certificate and attach a registration certificate that lists exactly the data they registered for. The wallet shows the name and purpose and refuses requests that ask for more. More →
The person holds a passport or ID card to the phone. The chip is read over NFC and checked on the server: chip authentication and the document signer chain up to the issuing country. Basis for onboarding at a high level of assurance. More →
Issues credentials into wallets with OpenID for Verifiable Credential Issuance: SD-JWT VC and ISO mdoc, bound to a key of the wallet, with a status list entry for each credential. More →
Person identification data (PID), mobile driving licence, Photo ID, membership and employee cards, NFC access cards for doors, NFC memory cards and PKI cards (read/write and read-only) that turn the phone into a smart card. Each one only discloses what the person approves. More →
The wallet on the phone: holds the person's documents, asks before anything is shared (who asks, why, exactly which data; PIN or fingerprint), shows documents in person by QR code or NFC tap, checks someone else's ID or age, signs PDFs, opens doors, reads passport chips, works as a smart card at a PC, keeps one-time codes and makes an encrypted backup. Keys live in the phone's secure hardware. More →
Confirms to issuers and relying parties that a wallet is a genuine, up-to-date CodeB Wallet on an intact phone (wallet instance attestation) and that its keys are hardware-protected (key attestation). A lost phone is revoked here. More →
Keeps the PID keys on the server instead of the phone. The phone proves it is the registered wallet and the person proves the wallet PIN; wrong PINs are counted on the server. A new PIN or a new phone keeps the same keys, so the PID stays valid.
A holder wallet that runs in the browser: for people without a suitable phone and for desktop work. Same credentials and protocols as the app. More →
A shared wallet for an organisation: several people manage company credentials, sign on behalf of the company and present the company's data to partners and authorities. More →
Asks wallets for exactly the data a service needs, checks the answer cryptographically, against the trusted lists and the status lists, and hands the verified result to the service. More →
Websites and apps connect with standard OpenID Connect and get the verified wallet data as an ID token. Passkeys and passwords work through the same sign-in. More →
Talks to wallets on behalf of many smaller relying parties. Each still appears in the wallet under its own name and purpose, with its own registration certificate naming the intermediary. More →
Sign a PDF with the wallet or ask others to sign by QR code. The wallet signs remotely with the CodeB signing service over the Cloud Signature Consortium API, or with the person's own signature card; RFC 3161 timestamps and certificate status (OCSP) come from your own installation. More →
Anyone can check a credential or a presentation: signature, issuer, key binding and status. The same checks run inside the verifier. More →
Templates for the data protection impact assessment and the records of processing, a privacy dashboard for the person, data-deletion requests to relying parties, and audit logs on every side. No trackers anywhere. More →
Self-declared conformity, not certified. Credentials issued in test mode are for testing only.
No. Each module works on its own with other standard-compliant wallets, issuers and relying parties. A website that only wants wallet sign-in needs the Relying Party Gateway or the intermediary; an issuer needs only the issuer.
Yes, as far as they follow the same open standards (OpenID4VCI, OpenID4VP, HAIP, SD-JWT VC, ISO mdoc) and trust the same lists.
In the phone's secure hardware by default. For the PID they can also be kept in the remote key storage on the server, protected by the phone and the wallet PIN.
Yes. Every module runs in your own installation in the EU, without a database and without third-party trackers; Aloaha can also host it for you.
As a hosted service run by Aloaha or as your own installation. Tell us what you need.