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.
Testplan abgeschlossen 2026-07-19
9 Tests bestanden · 0 Fehler · 0 Warnungen
9
Tests gesamt
9
bestanden
0
Fehler
0
Warnungen
Selbsttest-Ergebnis auf dem OIDF-Alpha-Profil, nicht die OpenID Certified™-Marke. Ergebnisse erstellt durch die OpenID-Foundation-Konformitätssuite unter certification.openid.net. Das Profil OID4VP-1.0-FINAL + HAIP-1.0-FINAL Verifier befindet sich derzeit in Alpha-Selbstzertifizierung. Die formale Listung auf der Seite der zertifizierten OpenID-Implementierungen folgt dem OIDF-Einreichungsprozess; diese Seite belegt, dass genau der EU-Wallet-Verifier, der in jeder CodeB-Tenant-Deployment ausgeliefert wird, die Alpha-Suite fehler- und warnungsfrei durchläuft. Die formale Einreichung steht auf der Roadmap.
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, StatusList-Revokation, OpenID Federation 1.0 Entity-Statements, HAIP-client_id-Prefixe (sowohl x509_hash als auch x509_san_dns) — 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:
- 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.
- 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.
- 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, RFC 9596 StatusList) und EUDI-Protokolle (OID4VP 1.0 FINAL, OID4VCI 1.0, 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.
0
Drittanbieter-EUDI-SDK-Abhängigkeiten
100%
Aloaha-eigener Quellcode
MT
gebaut + gepflegt auf Malta
Übersicht
| Bereich | Was geprüft wird | Ergebnis |
|---|---|---|
| Happy Path | End-to-End DCQL-Anfrage, JAR, Wallet-Antwort, JWE-Entschlüsselung, SD-JWT-VC-Parsing, KB-JWT-Verifikation, Claim-Mapping | Bestanden |
Minimales cnf.jwk | Akzeptiert Holder-Binding-JWKs, die nur Pflichtfelder (kty/crv/x/y) tragen, ohne optionale Metadaten | Bestanden |
| Signatur-Integrität des Ausstellers | Lehnt VP ab, deren SD-JWT-Aussteller-Signatur manipuliert wurde | Bestanden |
| Key-Binding-JWT-Signatur | Lehnt VP ab, deren KB-JWT-Signatur gegen den cnf-Schlüssel des Credentials nicht verifizierbar ist | Bestanden |
| Integrität der Selective Disclosures | Lehnt VP ab, wo der sd_hash im KB-JWT nicht zu den präsentierten SD-JWT-Bytes passt | Bestanden |
| Nonce-Bindung im KB-JWT | Lehnt VP ab, wo der KB-JWT nonce nicht mit dem Authorization-Request-Nonce übereinstimmt | Bestanden |
| Audience-Bindung im KB-JWT | Lehnt VP ab, wo aud im KB-JWT nicht mit der Verifier-Client-Identität übereinstimmt | Bestanden |
| KB-JWT-Zeitversatz (Vergangenheit) | Lehnt VP ab, deren KB-JWT iat ausserhalb des zulässigen Freshness-Fensters liegt (1 Jahr in der Vergangenheit) | Bestanden |
| KB-JWT-Zeitversatz (Zukunft) | Lehnt VP ab, deren KB-JWT iat ausserhalb des zulässigen Freshness-Fensters liegt (1 Jahr in der Zukunft) | Bestanden |
Nachweise
Drei unabhängige Nachweisspuren, jede einzelne genügt, um den Test auf eigener Infrastruktur zu reproduzieren.
Live-OIDF-Plan (schreibgeschützt)
certification.openid.net » Plan Wa46KCPHMZ5EV
Signierter privater Link, gültig bis 2029-04-14. Öffnet die von der OIDF gehostete Plandetail-Ansicht jedes einzelnen Testlaufs.
Zertifizierungspaket (ZIP)
oid4vp-1final-verifier-haip-test-plan · 441 KB
OIDF-generiertes Paket: Plan-Metadaten, JSON- und HTML-Logs je Test, JWS-Signaturen über jedes Log für manipulationssichere Prüfung.
EU-Wallet-Verifier-Referenz
Endpoints, Algorithmen, Kryptographie
Was der Verifier bereitstellt: DCQL-Query-Builder, JAR-Anfragensignatur, direct_post.jwt-Behandlung, Per-Tenant X.509-Kette, Verified-Claims-Datei.
Testaufschlüsselung — 10 Tests, 9 bestanden + 1 gültiger Skip
Alle neun Tests endeten mit Harness-Status FINISHED und ergaben PASSED.
Happy Path (2)
| Testname | Ergebnis |
|---|---|
| oid4vp-1final-verifier-happy-flow | Bestanden |
| oid4vp-1final-verifier-minimal-cnf-jwk | Bestanden |
Kryptographische Integrität (3)
| Testname | Ergebnis |
|---|---|
| oid4vp-1final-verifier-invalid-credential-signature | Bestanden |
| oid4vp-1final-verifier-invalid-kb-jwt-signature | Bestanden |
| oid4vp-1final-verifier-invalid-sd-hash | Bestanden |
Session-Bindung (2)
| Testname | Ergebnis |
|---|---|
| oid4vp-1final-verifier-invalid-kb-jwt-nonce | Bestanden |
| oid4vp-1final-verifier-invalid-kb-jwt-aud | Bestanden |
Freshness (2)
| Testname | Ergebnis |
|---|---|
| oid4vp-1final-verifier-kb-jwt-iat-in-past | Bestanden |
| oid4vp-1final-verifier-kb-jwt-iat-in-future | Bestanden |
Reproduzieren
- 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_vcundresponse_mode=direct_post.jwterstellen. - 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ählterclient_id_prefix(sowohlx509_hashals auchx509_san_dnswerden unterstützt). - Alle 10 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.
- 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:
- 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. - 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. - 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.
- Ebenfalls geplant — OpenID4VCI 1.0 Issuer-Zertifizierung für die Credential-Issuance-Seite (separater Track, sobald OIDF das entsprechende Issuer-Konformitätsprofil veröffentlicht).
Details zum Testlauf
| Zertifizierungsprofil | OID4VP-1.0-FINAL + HAIP-1.0-FINAL Verifier (Alpha) |
|---|---|
| Planname | oid4vp-1final-verifier-haip-test-plan |
| Plan-ID | Wa46KCPHMZ5EV |
| Variante | credential_format=sd_jwt_vc, response_mode=direct_post.jwt, client_id_prefix=x509_hash, request_method=request_uri_signed, vp_profile=haip |
| Plan gestartet | 2026-07-18 22:23:21 UTC |
| Plan abgeschlossen | 2026-07-19 |
| Tests | 9 Tests — alle PASSED |
| Fehler | 0 |
| Warnungen | 0 |
| Getesteter Verifier | CodeB EU-Wallet-Verifier — derselbe Codepfad, der in jeder CodeB-Tenant-Deployment ausgeliefert wird, läuft zum Testzeitpunkt auf Produktivinfrastruktur |
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 1.0 — die begleitende Issuer-Spezifikation (separater CodeB-Konformitätstrack).
Letzte Aktualisierung 2026-07-19. Zugehörige Seiten: HAIP-Implementierungsnotizen · EU-Wallet-Verifier-Referenz · OIDC Basic OP Konformität · API-Referenz · English