Baseline identity-provider role. Every wallet-facing flow layers on top of a clean OP. Covers discovery, JWKS, /authorize, /token, /userinfo, PKCE, refresh rotation, code-reuse invalidation, prompt=none / max_age / id_token_hint, and OIDC Core 6.1 Request Object handling.
Full test results, evidence bundle, private OIDF plan link →OpenID Foundation conformance roadmap
Public evidence trail for CodeB Sovereign Communications’ OpenID Foundation self-certification programme. Each milestone links to the artefacts produced. Dates are targets, not promises — the roadmap moves when standards do.
Milestones
Both the OID4VP core protocol and the HAIP profile land in one alpha plan (Wa46KCPHMZ5EV, sd_jwt_vc + direct_post.jwt + x509_hash + request_uri_signed). Covers signed JAR, DCQL, JWE-encrypted responses (ECDH-ES + A128GCM), SD-JWT VC + KB-JWT holder binding, session-nonce + audience binding, freshness bounds, and the negative-path integrity tests (tampered issuer sig, tampered KB-JWT sig, tampered sd_hash).
The complementary spec — instead of accepting credentials from a wallet, this one issues them. Turns a CodeB tenant into an operational credential issuer for staff badges, tenant onboarding tokens, age attestations, or any domain-specific SD-JWT VC. The issuer substrate is already live at vci.ashx and produces SD-JWT VCs with holder binding today; the OIDF Issuer conformance profile is expected to open later in 2026, and we self-test as soon as it does.
Not on the near-term path. FAPI is the profile banks and PSD2 open-banking clients require; picking it up means signed request objects everywhere, mandatory PAR, mTLS or private_key_jwt client auth, and richer replay defences. We’ll do it if a deal justifies the engineering; otherwise it stays parked.
Why this order
HAIP is a profile that layers strict constraints on top of OID4VP. Basic OP had to land before either verifier profile because both re-use OIDC discovery, JWKS handling, and token-endpoint semantics — that plan closed clean on 2026-07-18. The combined OID4VP + HAIP Verifier alpha plan followed the very next day (2026-07-19) with the same zero-fail / zero-warn result. OpenID4VCI is next as soon as the OIDF Issuer conformance profile opens; the issuer substrate is already live and producing SD-JWT VCs with holder binding.
How to verify progress independently
Every finished milestone links to:
- a signed, read-only OIDF plan URL that shows every test run and every log entry;
- a JWS-signed evidence ZIP bundle downloadable from this site;
- a step-by-step recipe for reproducing the run against your own CodeB tenant (or any spec-compliant OIDC provider).
Nothing here needs to be taken on trust. If a claim on this page ever loses its evidence link, that’s a bug — write to the CodeB team and we’ll fix it.
The bigger picture
Under eIDAS 2.0 (Regulation (EU) 2024/1183, Article 5f), every regulated EU private-sector business is legally required to accept the EU Digital Identity Wallet as a customer login from December 2027 onward. HAIP is the interop profile that makes that acceptance work with real wallets. The roadmap above is what “ready” looks like on the vendor side, dated and evidenced.
Last updated 2026-07-18. Related pages: Basic OP results · HAIP implementation notes · OIDC OP features · EU Wallet verifier · API reference