CodeB Sovereign Communications

OpenID Foundation Konformitäts-Fahrplan

Öffentliche Nachweiskette für das OpenID-Foundation-Selbstzertifizierungsprogramm von CodeB Sovereign Communications. Jeder Meilenstein verlinkt auf die erzeugten Artefakte. Termine sind Ziele, keine Versprechen — der Fahrplan verschiebt sich, wenn Standards sich bewegen.

Rechtlich gelesen. Keiner der Punkte unten beansprucht das OpenID Certified™-Zeichen. Das Bestehen der OIDF-Konformitätssuite ist eine technische Voraussetzung; das Zeichen wird separat nach kostenpflichtiger Einreichung bei der OpenID Foundation vergeben. Punkte mit erledigt bedeuten, dass die Konformitätssuite auf unserer Infrastruktur grün abgeschlossen wurde. Formale Listungen auf openid.net/certification folgen, sobald wir jedes Profil einreichen.

Meilensteine

1 OpenID Connect Core — Basic OP Erledigt 2026-07-18
Suite Konformitätssuite 5.2.0 Tests 35 / 35 bestanden Fehler 0 Warnungen 0

Basis-Rolle als Identitätsanbieter. Jeder wallet-basierte Ablauf setzt auf einem sauberen OP auf. Abgedeckt sind Discovery, JWKS, /authorize, /token, /userinfo, PKCE, Refresh-Rotation, Code-Reuse-Invalidierung, prompt=none / max_age / id_token_hint sowie OIDC-Core-6.1-Request-Object-Handling.

Vollständige Testergebnisse, Nachweispaket, privater OIDF-Planlink →
2 OpenID for Verifiable Presentations 1.0 — Wallet-Facing Verifier Nächstes · Ziel 2026-08-14
Suite Konformitätssuite 5.x, oid4vp-*-Tests Aufwand mittel (wenige Wochen) Voraussetzung für HAIP, EUDI-Wallet-Akzeptanz

Das Kernprotokoll, das jede wallet-basierte Anmeldung spricht. Die Zertifizierung beweist, dass unser Verifier-Substrat korrekt arbeitet bei:

  • Signierten Authorization Requests (JAR), request_uri-Auslieferung, x509_san_dns- und x509_hash-Client-Identifier-Prefixes
  • DCQL-Credential-Query-Kodierung, Presentation-Definition-Verhandlung
  • JWE-verschlüsselten Responses (ECDH-ES + A128GCM), direct_post.jwt-Response-Mode
  • SD-JWT-VC-Selective-Disclosure mit KB-JWT-Holder-Binding, Nonce- und transaction_data-Erzwingung

Läuft gegen dieselben Verifier-Endpunkte, die intern schon von age-verify, sign-in-widget und OIDC-Clients-Presentation-Requests genutzt werden. Bei den meisten Tests erwarten wir grün beim ersten Lauf; der Wert der Suite besteht darin zu beweisen, dass jedes Feld gemäß Spec ausgegeben wird — nicht gemäß Gedächtnis der Implementierer.

3 High Assurance Interoperability Profile 1.0 (HAIP) — Verifier Nach #2 · Ziel 2026-08-14
Suite haip-*-Tests (Selbst-Zertifizierung seit Feb 2026) Aufwand klein auf OID4VP aufsetzend Passt zu EUDI-Wallet-Architecture-Reference-Framework

Das EU-Wallet-spezifische Profil, das OID4VP auf eine einzige Interop-Menge einschränkt. Weil jedes nationale Wallet-Schema HAIP folgt, scheitern Verifier, die nur generisches OID4VP bestehen, an echten Wallets. HAIP legt fest:

  • ES256 als einzigen Signaturalgorithmus, keine Verhandlung
  • SD-JWT VC als Credential-Format (kein mDoc im Web-Verifier-Profil)
  • Client-Identifier-Prefixes beschränkt auf x509_san_dns und x509_hash
  • KB-JWT mit Nonce-Binding zwingend bei jeder Presentation
  • Vertrauenskette gewurzelt in nationalen EU-Listen vertrauenswürdiger Listen (LOTL)
Aktuelle HAIP-Implementierungshinweise — abschnittsweise Lückenanalyse →
4 OpenID for Verifiable Credential Issuance 1.0 — Issuer Ziel 2026-08-14
Suite oid4vci-*-Tests Aufwand mittel Öffnet „Ausstellen + Verifizieren aus einer Plattform“

Das ergänzende Protokoll — anstatt Credentials von einem Wallet zu akzeptieren, stellt dieses welche aus. Macht aus einem CodeB-Tenant einen operativen Credential-Issuer für Mitarbeiterausweise, Onboarding-Tokens, Altersnachweise oder beliebige domänenspezifische SD-JWT VCs. Die Zertifizierung ergänzt die Verifier-Story um eine volle Issuer-Story: eine Plattform, beide Richtungen.

5 FAPI 2.0 Message Signing — Financial-Grade OP Optional · 2027
Suite fapi2-*-Tests Aufwand groß Nur wenn ein Banking-/Open-Finance-Deal es rechtfertigt

Steht nicht auf dem kurzfristigen Pfad. FAPI ist das Profil, das Banken und PSD2-Open-Banking-Clients verlangen; die Aufnahme bedeutet signierte Request-Objekte überall, verpflichtender PAR, mTLS oder private_key_jwt-Client-Authentifizierung und härtere Replay-Abwehr. Wir machen es, wenn ein Deal die Engineering-Kosten rechtfertigt; ansonsten bleibt es geparkt.

Warum diese Reihenfolge

HAIP ist ein Profil, das strikte Einschränkungen auf OID4VP legt. Zuerst die OID4VP-Suite zu laufen isoliert Basisprotokoll-Probleme von HAIP-spezifischen Regeln — zwei kleine Debug-Zyklen schlagen einen großen. Und Basic OP musste vor beiden Verifier-Profilen landen, weil beide OIDC-Discovery, JWKS-Handling und Token-Endpunkt-Semantik wiederverwenden.

OpenID4VCI läuft parallel zu den Verifier-Profilen — die Tender-Fläche (EUDI-Wallet-Akzeptanz) ist verifier-zentrisch, aber die Ausstellung ist eine natürliche Erweiterung desselben Substrats und wir landen alle drei Selbsttests gemeinsam bis zum 14. August 2026. Das ergibt eine datierte Nachweiskette, die Akzeptanz und Ausstellung von derselben Plattform aus abdeckt.

Wie Sie den Fortschritt unabhängig prüfen

Jeder abgeschlossene Meilenstein verlinkt auf:

Nichts hier muss auf Vertrauen genommen werden. Wenn eine Aussage auf dieser Seite jemals ihren Nachweislink verliert, ist das ein Bug — schreiben Sie dem CodeB-Team und wir korrigieren es.

Der größere Kontext

Unter eIDAS 2.0 (Verordnung (EU) 2024/1183, Artikel 5f) ist jedes regulierte EU-Privatunternehmen ab Dezember 2027 gesetzlich verpflichtet, die EU-Digital-Identity-Wallet als Kundenanmeldung zu akzeptieren. HAIP ist das Interop-Profil, das diese Akzeptanz mit echten Wallets funktionieren lässt. Der Fahrplan oben zeigt, wie „bereit“ auf der Anbieterseite aussieht — datiert und nachgewiesen.

Letzte Aktualisierung 2026-07-18. Verwandte Seiten: Basic-OP-Ergebnisse · HAIP-Implementierungshinweise · OIDC-OP-Funktionen · EU-Wallet-Verifier · API-Referenz