CodeB Sovereign Communications

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.

Reading this like a lawyer. None of the items below claim the OpenID Certified™ mark. Passing the OIDF conformance suite is a technical prerequisite; the mark is granted separately after paid submission to the OpenID Foundation. Items marked done mean the conformance suite finished green on our infrastructure. Formal listings on openid.net/certification follow when we submit each profile.

Milestones

1 OpenID Connect Core — Basic OP Done 2026-07-18
Suite conformance suite 5.2.0 Tests 35 / 35 pass Failures 0 Warnings 0

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 →
2 OpenID for Verifiable Presentations 1.0 — Wallet-Facing Verifier Next · target 2026-08-14
Suite conformance suite 5.x, oid4vp-* tests Effort medium (few weeks) Blocker for HAIP, EUDI wallet acceptance

The core protocol every wallet-based sign-in speaks. Certifying this proves our verifier substrate is correct across:

  • Signed Authorization Request (JAR) construction, request_uri serving, x509_san_dns and x509_hash client identifier prefixes
  • DCQL credential-query encoding, presentation-definition negotiation
  • JWE-encrypted responses (ECDH-ES + A128GCM), direct_post.jwt response mode
  • SD-JWT VC selective disclosure with KB-JWT holder binding, nonce + transaction_data enforcement

Runs against the same verifier endpoints already exposed for internal age-verify, sign-in-widget and OIDC-clients presentation requests. Most tests expected green on first run; the suite’s value is proving each field is emitted per spec, not per implementer memory.

3 High Assurance Interoperability Profile 1.0 (HAIP) — Verifier After #2 · target 2026-08-14
Suite haip-* tests (self-cert opened Feb 2026) Effort small on top of OID4VP Aligns with EUDI Wallet Architecture Reference Framework

The EU-Wallet-specific profile that constrains OID4VP to a single interop set. Because every national wallet scheme aligns to HAIP, verifiers that only pass generic OID4VP still fail against real wallets. HAIP nails down:

  • ES256 signature algorithm only, no negotiation
  • SD-JWT VC as the credential format (no mDoc for the web-verifier profile)
  • Client Identifier Prefixes limited to x509_san_dns and x509_hash
  • KB-JWT with nonce binding mandatory on every presentation
  • Trust chain rooted in national EU Lists of Trusted Lists (LOTL)
Current HAIP implementation notes — section-by-section gap analysis →
4 OpenID for Verifiable Credential Issuance 1.0 — Issuer Target 2026-08-14
Suite oid4vci-* tests Effort medium Unlocks “issue + verify from one platform”

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. Certifying it adds a full issuer story to the verifier story: same platform, both directions.

5 FAPI 2.0 Message Signing — Financial-Grade OP Optional · 2027
Suite fapi2-* tests Effort large Only if a banking / open-finance deal materialises

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. Running the OID4VP suite first isolates baseline protocol issues from HAIP-specific rules — two smaller debugging cycles beats one large one. And Basic OP had to land before either verifier profile because both re-use OIDC discovery, JWKS handling, and token-endpoint semantics.

OpenID4VCI runs in parallel with the verifier profiles — the tender surface (EUDI wallet acceptance) is verifier-first, but issuing is a natural extension of the same substrate and we’re landing all three self-tests together by 14 August 2026. That gives one dated evidence trail covering acceptance and issuance from the same platform.

How to verify progress independently

Every finished milestone links to:

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