Independently tested: CodeB issues and checks digital cards exactly by the European standards

The CodeB credential issuer — the component that puts cards, PIDs and attestations into EUDI wallets — was run through the official OpenID Foundation issuer test plans for OpenID for Verifiable Credential Issuance 1.0 with the High Assurance Interoperability Profile (HAIP) 1.0. Every plan finished without a single failure.

In plain words

A digital wallet on your phone holds things like your ID card, your driving licence, a membership card or a company badge. Someone has to put those cards into the wallet in a safe way: that is the job of an issuer. CodeB runs such an issuer.

When you later use the card — to sign in, to prove your age, to show a membership — the other side has to check it: is it genuine, still valid, really yours? That is the job of a verifier. CodeB runs that too.

For this to work across Europe, every wallet and every issuer must follow the same rulebook — otherwise a card issued by one company would not open in another company’s wallet, just like a plug that does not fit the socket. These rulebooks are open, international standards.

Writing “we follow the standard” on a website is easy. Proving it is not. The organisation that publishes these standards runs an official, automated test lab. It plays the role of a wallet, talks to the issuer and checks hundreds of details: does the issuer hand out cards correctly, does it protect them against theft and copying, and — just as important — does it refuse every request that is wrong, forged or replayed.

CodeB went through all of it: four complete test plans with 63 tests each for the issuer, and two test plans for the verifier — for both card formats used in Europe. The verifier tests also hand CodeB forged, manipulated and revoked cards, which it must reject. Not a single test failed.

What this means for you

• Your cards work in the wallets of the future. Cards issued by CodeB follow the same rules as the official European digital identity wallets (EUDI wallets), so they are not tied to one app or one vendor. As with any official document, the other side also has to trust the one who issued it: the issuer’s certificate must be on the trust list that the wallet or service uses. The tests prove the technical side; the trust lists decide who is accepted.
• Bank-grade protection is verified, not promised. The tests check that a card can only be collected by the right phone, that stolen or copied requests are rejected and that every step is cryptographically bound to the person who started it.
• No lock-in. Because everything follows open standards, you can switch wallet, switch issuer or run CodeB on your own server without rebuilding anything — only the trust setup (which certificates are accepted) has to be in place.
• Independent proof. The test lab is run by the standards organisation, not by us. Every single test and its full log is public through the links further down.

The terms on this page, explained

The technical detail

• EUDI wallets speak OID4VCI and HAIP. HAIP 1.0 is the high-assurance profile the EUDI architecture builds on. An issuer that passes these plans can hand credentials to any wallet that follows the same standards — no bilateral integration project, no vendor plug-in. Acceptance in a given wallet still depends on trust: the wallet must trust the issuer’s certificate (trust list or registration), just as the verifier must trust the issuers whose cards it accepts.
• Security is tested, not claimed. The plans check pushed authorization requests (PAR), PKCE, sender-constrained tokens (DPoP), wallet client attestation, key attestation, proof-of-possession, nonce handling, refresh-token rules from the FAPI 2.0 security profile and dozens of negative cases where a correct issuer must refuse.
• Both credential formats. SD-JWT VC (selective disclosure, JSON) and ISO/IEC 18013-5 mdoc (CBOR, the mobile driving licence family) passed the same plans, in both the wallet-initiated and the issuer-initiated (credential offer) flow.
• Tamper-evident and independent. The test harness is operated by the standards body, not by us. Anyone with the links below can inspect every request, response and assertion.

More than 20 years of doing it right — and it pays off

We are a little proud of this one. Aloaha has been building signature, PKI and secure-identity software since 2003 — more than twenty years in exactly this field. Over all those years we have followed one rule, and CodeB was built on it from the first line of code: implement the published standards exactly, in-house, without vendor lock-in and without proprietary shortcuts. Passing every one of these test plans on brand-new standards without a single failure is the result of that discipline: two decades of experience plus strictly following the standards pays off. The conformance run did find details where the specifications are stricter than everyday wallets — for example refresh-token handling under FAPI 2.0, where the certificate chain sits inside an mdoc status list, and how credential times are rounded for privacy — and each one was fixed to follow the standard rather than worked around. That is the point of testing against the reference: interoperability you can rely on, today and with the wallets that come next.

Results per test plan

What the warnings are

• Two extra metadata fields. The issuer metadata carries two CodeB extensions that wallets may ignore (whether a card is invitation-only, and display information about the issuer). The suite flags any field it does not know; they do not change the protocol.
• TLS 1.3. HAIP recommends TLS 1.3. The development tenant runs on Windows Server 2019, whose TLS stack offers TLS 1.2; newer Windows Server versions add TLS 1.3.
• Reviewed and skipped. Four tests ask for a screenshot of the issuer refusing a bad request, which is reviewed by a person rather than scored automatically. One test is skipped because CodeB deliberately issues one credential per request. In the verifier plans, the reviewed tests show a screenshot of the verifier’s result page after it accepted the test card.

Evidence

Read-only links to the full test plans on the conformance suite, valid for ten years. Each one opens every test with its complete log. We believe transparency builds trust in the EUDI ecosystem. We therefore publish our complete test logs and encourage all providers of wallets, issuers and verifiers to do the same.

Details about the runs

Last updated 2026-11-02. Related pages: OpenID Connect OP conformance · HAIP OID4VP verifier conformance · OID4VP verifier proof of work · Cyber resilience