HAIP 1.0 OID4VP Verifier — Konformitäts-Selbsttest

Unabhängiger Nachweis, dass der EU-Wallet-Verifier von CodeB das Zertifizierungsprofil OpenID Foundation OID4VP-1.0-FINAL + HAIP-1.0-FINAL Verifier (Alpha) besteht, ausgeführt am 2026-07-19 durch den von der OIDF gehosteten Konformitätsharness.

Von Aloaha Limited gebaut. Kein Fork eines SDKs.

Jede Protokollschicht — SD-JWT-VC-Parsing, JWS- + KB-JWT-Signaturprüfung, OpenID4VP Request/Response, DCQL-Query-Builder, direct_post.jwt JWE ECDH-ES, x5c-Chain-Validierung, OpenID Federation 1.0 Entity-Statements, HAIP-client_id-Prefix x509_hash (wie von HAIP 1.0 Final vorgeschrieben) sowie das zusätzliche OpenID4VP-Kompatibilitäts-Prefix x509_san_dns für ältere Wallets, die vor HAIP entstanden sind — wurde vom Aloaha-Limited-Team intern geschrieben. Kein eudi-lib-*, kein Drittanbieter-EUDI-SDK irgendwo im Dependency-Tree. Das bedeutet für Sie drei konkrete Zusagen:

1. Der Code gehört uns. Jede Zeile der Implementierung kann im eigenen Security-Audit inspiziert werden. Keine geschlossenen EUDI-Bibliotheken, denen Ihr CISO blind vertrauen müsste. Generische Infrastruktur-Bibliotheken (JWT/JWS, HTTP, .NET-BCL-Krypto-Primitives) sind weit verbreitete Open-Source-Komponenten; der EUDI-Protokoll-Code selbst ist zu 100% von Aloaha geschrieben.
2. Eigener Lieferkalender. Wir liefern nach unserem eigenen Release-Rhythmus — nicht abhängig von der nächsten SDK-Version eines Konsortiums, nicht gebunden an Withdrawal-Zyklen, die wir nicht gewählt haben. CVE-Patches und Trust-Policy-Änderungen gehen live, sobald wir sie getestet haben.
3. Strikt standardbasierte Interoperabilität. Wallet, Verifier und Issuer sprechen ausschließlich über veröffentlichte RFCs (RFC 7519 JWT, RFC 7515 JWS, RFC 7516 JWE, RFC 8725 JWT BCP, RFC 9126 PAR) und EUDI-Protokolle (OID4VP 1.0 FINAL, OID4VCI 1.0 Final, HAIP 1.0 FINAL, SIOP v2, OpenID Federation 1.0) miteinander. Jedes Stück ist austauschbar — kein Vendor-Lock-in, nicht einmal zwischen unseren eigenen Komponenten.

Übersicht

Nachweise

Drei unabhängige Nachweisspuren, jede einzelne genügt, um den Test auf eigener Infrastruktur zu reproduzieren.

Testaufschlüsselung — 9 Tests, alle bestanden

Alle neun Tests endeten mit Harness-Status FINISHED und ergaben PASSED.

Happy Path (2)

Kryptographische Integrität (3)

Session-Bindung (2)

Freshness (2)

Reproduzieren

1. Kostenloses Konto anlegen auf certification.openid.net, einen Plan vom Typ „OID4VP-1.0-FINAL + HAIP-1.0-FINAL Verifier“ (Alpha) mit Variante credential_format=sd_jwt_vc und response_mode=direct_post.jwt erstellen.
2. Den server-Abschnitt des Plans mit den Verifier-Metadaten Ihres CodeB-Tenants konfigurieren: Authorization-Endpoint-URL, Per-Tenant X.509-Leaf-Public-Key und gewählter client_id_prefix. HAIP 1.0 Final schreibt x509_hash vor; wir unterstützen zusätzlich x509_san_dns als OpenID4VP-Kompatibilitätsmodus für ältere Wallets (nicht Teil von HAIP Final).
3. Alle 9 Alpha-Sub-Tests ausführen. Der Verifier steuert jeden End-to-End von der Wallet-Auswahl bis zur entschlüsselten Claim-Lieferung; keine manuelle Interaktion nötig.
4. Zertifizierungspaket-ZIP von der Plandetail-Seite herunterladen und die results-Arrays je Test gegen das oben verlinkte JSON-Bundle abgleichen.

Roadmap zur OpenID Certified™-Marke

Das Bestehen der Alpha-Konformitätssuite ist Schritt eins. Der vollständige Weg zur Listung auf der Seite der zertifizierten OpenID-Foundation-Implementierungen:

1. Erledigt — OID4VP-1.0-FINAL + HAIP-1.0-FINAL Verifier-Alpha-Suite, sd_jwt_vc + direct_post.jwt-Variante, fehler- und warnungsfreier Durchlauf im OIDF-Harness.
2. In Arbeit — 2026-07-20: wachsende mDoc-/ISO 18013-5-Pipeline — Fundamente stehen (abhängigkeitsfreies CBOR + COSE_Sign1 + mDoc-Primitiven in Wallet + MDocIssuer + MDocVerifier; wallet-seitiger QR-Kamera-Scanner über BarcodeDetector; OID4VCI-Code-Flow mit RFC 9126 PAR + PKCE + wallet-clients.json-Whitelist neben dem pre-authorized_code-Grant). Ende-zu-Ende-Vertrauensanker unter App_Data/<tenant>/trust/mdoc-issuers/ weiterhin durch Operator bereitzustellen; leeres Verzeichnis liefert HTTP 501 mdoc_verify_not_configured.
3. Neuerungen 2026-07-20 — CWT-Proof-of-Possession (RFC 8747) neben JWT-Proofs am mDoc-Mint-Endpunkt akzeptiert; pro-Mandant Wallet-client_id-Whitelist über App_Data/<tenant>/wallet-clients.json (5-Min-Cache, hartcodierter Fallback); terser-minifizierte Wallet-PWA-Module ersetzen die bisherigen kopier-nur-.min-Zwillinge; ein semantisches App_Code-Vorkompilations-Prüftool (testscripts/App_Code-precompile-check.py) sichert jeden C#-5-kompatiblen Edit vor dem Deploy ab. Keiner dieser Punkte wurde erneut über die OIDF-Testsuite gefahren — der Alpha-Suite-Durchlauf in Zeile 1 oben bleibt die letzte zertifizierte Evidenz.
4. Neuerungen 2026-07-22 — HAIP §5.11 Wallet-Attestation — Wallet-Attestation-JWT-Prüfung ist im Verifier verdrahtet (App_Code/WalletAttestationVerifier.cs + WalletAttestationPopVerifier.cs). Der Verifier akzeptiert ein wallet_attestation-JWT über Header, Formularfeld oder JSON-Umschlag; die Signatur wird gegen die durch den Operator hinterlegten Wallet-Provider-Schlüssel unter App_Data/<tenant>/trust/wallet-providers/*.jwks.json (oder *.pem) geprüft. Fehlen die Anker und liefert das Wallet trotzdem eine Attestation (oder verlangt der JAR sie), liefert der Verifier HTTP 501 wallet_attestation_not_configured, statt dem JWT stillschweigend zu vertrauen. Das PoP-JWT (Holder-signiertes wallet-attestation-pop+jwt mit aud=response_uri + nonce=<JAR-Nonce>) wird beim Mitliefern verifiziert. Verifier-Modus: mso_mdoc braucht weiterhin durch den Operator geladene Issuer-Anker unter App_Data/<tenant>/trust/mdoc-issuers/; leeres Verzeichnis liefert HTTP 501 mdoc_verify_not_configured. Keiner dieser Punkte wurde erneut über die OIDF-Testsuite gefahren — der Alpha-Suite-Durchlauf in Zeile 1 oben bleibt die letzte zertifizierte Evidenz.
5. Neuerungen 2026-07-22 — ARF-konformer VCT-Katalog — der mandantenlokale Issuer (vci.ashx) stellt jetzt die drei ARF-definierten Credential-Typen aus, die die European Digital Identity Wallet Reference Implementation adoptiert hat: urn:eu.europa.ec.eudi:pid:1 (gebündelt aus given_name, family_name, birth_date, age_over_18, age_in_years, age_birth_year), urn:eu.europa.ec.eudi:email:1 und urn:eu.europa.ec.eudi:address:1. Aloaha-eigene VCTs bleiben für Konzepte, für die es heute noch keinen ARF-Gegenpart gibt (username, preferred-username, tenant-membership, phone-verified). Ausgemusterte Aloaha-VCTs mit ARF-Nachfolger antworten mit HTTP 404 vct_retired und einem strukturierten {vct, successor, hint}-Body, damit Wallets sauber migrieren können. Die PID-Ausstellung verweigert die Mint-Operation, wenn dem eingeloggten Nutzerprofil eines von {given_name, family_name, birth_date} fehlt — der Issuer bevorzugt einen ehrlichen Fehler gegenüber einer synthetischen PID. Diese Erweiterung ist eine Scope- und Honesty-Änderung, keine Zertifizierungsaussage.
6. Neuerungen 2026-07-22 — OID4VP 1.0 FINAL DCQL-Feature-Parität — der Verifier setzt jetzt wallet_attestation_required=true im JAR, sobald der Mandant Wallet-Provider-Anker konfiguriert hat (OID4VP §5.10 + HAIP §5.11) — Wallets wissen so vorab, dass sie eine Attestation mitliefern müssen. Der Wallet-seitige Matcher versteht jetzt claims[*].values-Filter-Arrays, pro-Credential-claim_sets als Alternativ-Bündel, credential_sets.required=false für rein optionale Kombinationen und mDoc intent_to_retain (im Audit-Log vermerkt, sodass Datenschutzbeauftragte jede Speicherabsicht prüfen können). Explizites require_cryptographic_holder_binding wird implizit über die bestehenden KB-JWT-/DeviceAuth-Prüfungen erfüllt; purpose-i18n-Objekte und JSON-Schema-filter bleiben ehrlich offen bis die OIDF-Testsuite Deckung dafür ausliefert. Keiner dieser Punkte wurde erneut über die OIDF-Testsuite gefahren — der Alpha-Suite-Durchlauf in Zeile 1 oben bleibt die letzte zertifizierte Evidenz.
7. Neuerungen 2026-07-26 — ARF-TS3-Key-Attestation-Annahme — der mandantenlokale Issuer (vci.ashx) akzeptiert jetzt Key-Attestation-JWTs zusätzlich zur bestehenden Wallet-Instance-Attestation. Eine Key Attestation belegt, dass der konkrete Proof-of-Possession-Schlüssel in einer vertrauenswürdigen sicheren Umgebung (StrongBox, Secure Enclave o. ä.) erzeugt wurde; die Wallet transportiert sie im OpenID4VCI-Proof-JWT entweder im JOSE-Header (key_attestation) oder im Payload (attestations[]). Per-Tenant-Modus Vci:KeyAttestationMode = off / optional (Default) / require. Trust-Anchors unter App_Data/<tenant>/trust/key-attestation-issuers/*.pem. Die Credential-Issuer-Metadaten kündigen key_attestation_signing_alg_values_supported + key_attestations_required an. Es wird nur die generische JWT-Form geprüft; hersteller-spezifische Formate (android-key, apple-anonymous, TPM) sind zurückgestellt. Diese Erweiterung ist eine Scope- und Honesty-Notiz, keine Zertifizierungsaussage; der Alpha-Suite-Durchlauf in Zeile 1 oben bleibt die letzte unabhängig geprüfte Evidenz.
8. Neuerungen 2026-07-26 — ARF 3.0 Narrativprüfung — das Architektur- und Referenzrahmenwerk der European Digital Identity Wallet in der Version 3.0 (veröffentlicht am 21.07.2026) wurde gegen das oben ausgelieferte Verifier-Profil gelesen. Der obligatorische Präsentations-Stack in ARF §5.7 (OpenID4VP + HAIP für SD-JWT VC über direct_post.jwt) entspricht dem, was die Alpha-Suite exerziert; der obligatorische Ausstellungs-Stack in ARF §5.8 (OpenID4VCI + HAIP mit Wallet-Instance-Attestation-Annahme) entspricht dem, was vci.ashx heute anbietet. Die Registrierung nach Durchführungsverordnung (EU) 2025/848 (ARF §6.4.2) bleibt ein Operator-Schritt: Zugriffszertifikate und pro-Nutzungszweck-Registrierungszertifikate werden aus operator-geladenen mandantenlokalen Trust-Stores konsumiert, sobald der zuständige Member-State-Registrar sie ausstellt; nichts wird stillschweigend fabriziert. Die W3C Digital Credentials API als Transport (ARF §5.7.1) und der ARF-Zero-Knowledge-Proof-Track (TS4 / TS13 / TS14) sind heute nicht implementiert — Wallets, die diese verlangen, fallen auf den ausgelieferten OpenID4VP + Custom-URI-Scheme-Transport zurück. Dieser Punkt ist eine Scope- und Alignment-Notiz, keine Zertifizierungsaussage; der Alpha-Suite-Durchlauf in Zeile 1 oben bleibt die letzte unabhängig geprüfte Evidenz.
9. Neuerungen 2026-07-26 — JAdES Baseline B + WIA-EUDI-Erweiterungen — gemäss den Durchführungsvorschriften der European Digital Identity Wallet vom Juli 2026 validiert der mandantenlokale Issuer (vci.ashx) jetzt die JAdES-Baseline-B-Header-Claims nach ETSI TS 119 182-1 (crit, sigT, x5t#S256, sigPl) an Key-Attestation-JWTs und kündigt sowohl key-attestation+jwt als auch key-attestation+jades als akzeptierte Envelope-Typen in den Credential-Issuer-Metadaten an. Ein per-Tenant-Opt-in Vci:KeyAttestationRequireSealed gated das Leaf-Zertifikat gegen die EKU-OID 0.4.0.194112.1.4 (id-kp-EIDASSeal). Der Wallet-Instance-Attestation-Verifier akzeptiert jetzt die EUDI-spezifischen Claims wallet_link, wallet_name, wallet_metadata (mit verschachteltem wallet_provider + wallet_version), attestation_type und key_type_ref — anwesenheits-optional, strikt-shape-if-present, unbekannte Claims werden zur Vorwärtskompatibilität auf DEBUG geloggt. Diese Erweiterung ist eine Scope- und Honesty-Notiz, keine Zertifizierungsaussage; der Alpha-Suite-Durchlauf in Zeile 1 oben bleibt die letzte unabhängig geprüfte Evidenz.
10. Nächstens — dieselbe Suite gegen die weiteren vom Profil erlaubten Varianten fahren (request_uri_method=post, mDL-Credential-Format), sobald der OIDF-Harness über Alpha hinausgeht, und jeden Plan archivieren.
11. Dann — die Plan-IDs + OIDF-Zertifizierungsgebühr an die OpenID Foundation einreichen über openid.net/certification/instructions/. Die Listung erscheint typischerweise innerhalb von ein bis zwei Wochen nach Einreichung.
12. Separater Track — OpenID4VCI Issuer-Konformität für die Credential-Issuance-Seite. Im Rundgang 2026-07-26 wurde der mandantenlokale Issuer (vci.ashx) auf das OID4VCI 1.0-Final-Wire-Format umgestellt (nach Draft 15 veröffentlicht): dedizierter Nonce-Endpunkt gemäß Final §7.2 (/vci.ashx?nonce), Notification-Endpunkt gemäß Final §10 (/vci.ashx?notification), Credential Response im Final-credentials[]-Array-Format gemäß §8.3 (das Draft-15-Skalarfeld credential bleibt als Rückwärtskompatibilitätsfallback erhalten). Die Credential-Issuer-Metadaten kündigen jetzt nonce_endpoint, notification_endpoint und spec_version = "OID4VCI 1.0" an. Ein formeller Issuer-Konformitätslauf gegen die OIDF-Suite folgt, sobald das entsprechende Profil veröffentlicht wird; heute ist der Pass ein selbst-deklariertes Wire-Alignment gegen die Final-Spezifikation.

Details zum Testlauf

Zugehörige Spezifikationen

• OpenID for Verifiable Presentations 1.0 (FINAL) — das getestete Wallet-Verifier-Protokoll.
• High Assurance Interoperability Profile 1.0 (FINAL) — das an eIDAS 2.0 ausgerichtete Profil, das Credential-Format, Kryptographie, Client-ID-Prefixes, Response-Mode und Key-Binding festlegt.
• SD-JWT VC (IETF) — das in allen Tests verwendete Credential-Format.
• OpenID4VCI — die begleitende Issuer-Spezifikation; CodeB zielt heute auf OID4VCI 1.0 Final (dedizierter Nonce-Endpunkt, Notification-Endpunkt, credentials[]-Final-Response-Format; separater Konformitätstrack).

Letzte Aktualisierung 2026-07-26. Zugehörige Seiten: Betreiber-Setup-Runbook · EU-Wallet-Verifier-Referenz · OIDC Basic OP Konformität · API-Referenz · English

Siehe auch: Wallet-Interoperabilitätsmatrix · Glossar.