EU‑Wallet‑Anmeldung — Verifizierter Funktionsnachweis

Von Aloaha Limited gebaut. Kein Fork eines SDKs.

Jede Protokollschicht im Transkript weiter unten — 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, das HAIP-mandatierte x509_hash-Client-Identifier-Prefix plus das zusaetzliche x509_san_dns-Prefix (OpenID4VP-Kompatibilitaetsmodus, nicht HAIP 1.0 Final) — wurde vom Aloaha-Limited-Team intern geschrieben. Kein eudi-lib-*, kein Drittanbieter-EUDI-SDK irgendwo im Dependency-Tree. Drei konkrete Zusagen:

1. Der Code gehört uns. Jede EUDI-Protokoll-Zeile prüfbar im eigenen Security-Audit. Keine geschlossenen EUDI-Bibliotheken, denen Ihr CISO blind vertrauen müsste (generische Infrastruktur-Libs sind Open-Source-Standardkomponenten).
2. Eigener Release-Rhythmus. CVE-Patches und Features landen auf unserem eigenen Zeitplan — nicht abhängig von der nächsten SDK-Version eines Konsortiums.
3. Strikt standardbasierte Interoperabilität. Kommunikation ausschließlich über veröffentlichte RFCs und EUDI-Protokolle. Jedes Stück austauschbar — kein Vendor-Lock-in, nicht einmal zwischen unseren eigenen Komponenten.

0 Drittanbieter-EUDI-SDK-Abhängigkeiten · 100% Aloaha-eigener Quellcode · gebaut und gepflegt auf Malta von Aloaha Limited, einem in Malta ansässigen europäischen Souverän-Tech-Anbieter.

Warum eine Mock‑Wallet?

Das EUDI‑Wallet‑Ökosystem ist mitten im Rollout. Nationale Pilot‑Apps existieren, aber spezifikationskonforme OID4VP 1.0 + SD‑JWT VC + DCQL‑Unterstützung landet erst nach und nach in echten Wallets. Um zu beweisen, dass der Verifier unabhängig von einem bestimmten Wallet‑Anbieter funktioniert, folgt ein interner deterministischer Test‑Client dem OID4VP 1.0‑Happy‑Path exakt nach Spezifikation — und zeigt damit, dass jede konforme Wallet interoperieren wird.

Reale Wallet‑Interoperabilität skaliert mit der Reife des Ökosystems. Das Substrat ist heute eingebaut.

Was End‑to‑End gelaufen ist

Elf Schritte, jede kryptografische Prüfung bestanden, HTTP 200 mit verifizierten Claims:

Vier selektive Offenlegungen (given_name, family_name, birth_date, age_over_18) wurden gegen das _sd‑SHA‑256‑Hash‑Array der SD‑JWT VC verifiziert. Die SSO‑Assertion ist ein Standard‑RS256‑JWT mit amr=["vc"] und acr="urn:codeb:acr:eudi-wallet" — jede föderierte App im Tenant erbt die verifizierte Identität über den normalen OIDC‑userinfo‑Pfad. Eine Präsentation, alle abhängigen Apps profitieren, keine spezifische Integration nötig.

Der ausgerollte Krypto‑Stack

• Client‑Identifier‑Prefix — x509_hash (OID4VP 1.0 §5.9.3, base64url SHA‑256 des DER‑Leaf‑Zertifikats) ist die Wallet‑bevorzugte Form, an die sich reale EUDI‑Wallets binden; x509_san_dns (HAIP 1.0 Final) wird zur Kompatibilität unterstützt. Der Aufrufer wählt pro Request über ?client_id_prefix= am vp‑start‑Endpunkt; Verifier‑Metadaten kündigen beide via client_id_schemes_supported an. Bei jedem Release end‑to‑end getestet via eu‑wallet‑mock‑both.py. Mehrere identitätsfokussierte Verifier im breiteren Ökosystem unterstützen mittlerweile beide Prefixes; nach unserem Kenntnisstand ist CodeB der einzige OID4VP‑1.0‑Verifier mit dieser Kombination, der direkt in eine SIP / WebRTC‑Business‑Kommunikationsplattform integriert ist.
• Authorization Request — signierter JAR (ES256), typ=oauth-authz-req+jwt, x509_hash‑client_id‑Schema (Wallet‑bevorzugt) bzw. x509_san_dns (HAIP 1.0 Final-Kompatibilität), x5c‑Kette
• DCQL — native OID4VP 1.0‑Credential‑Query‑Syntax. Kein Presentation‑Exchange‑Ballast
• Antwort‑Verschlüsselung — JWE Compact Serialisation, alg=ECDH-ES + enc=A128GCM, NIST SP 800‑56A‑Concat‑KDF, konform zu RFC 7518 §4.6 / §5.1
• SD-JWT VC — vc+sd-jwt‑Format, _sd‑Array aus SHA‑256‑Disclosure‑Hashes, strukturelle Integrität Blatt‑für‑Blatt verifiziert
• KB-JWT — Holder‑Schlüsselbindung via cnf.jwk; nonce, aud und sd_hash alle gegen die Verifier‑Challenge geprüft
• Result‑Envelope — response=<JWE>‑Form‑Parameter gemäss OID4VP §8.4; der entschlüsselte Klartext ist ein JSON‑Envelope mit DCQL‑förmigem vp_token‑Objekt
• Session‑Persistenz — vp‑Sessions atomar geschrieben unter App_Data/<tenant>/vp‑sessions/, sodass IIS‑App‑Pool‑Recycles oder Multi‑Worker‑Routing keine laufende Präsentation verlieren

Was noch aussteht (Iteration 2)

Das aktuelle iter‑1‑Substrat prüft strukturelle Integrität und Holder‑Bindung. Was noch kommt, transparent gekennzeichnet:

• JWS‑Aussteller‑Signaturprüfung gegen Issuer‑JWKS / x5c‑Trust‑Chain
• LoTL‑Trust‑Chain‑Validierung — PKI → Mitgliedstaaten‑Vertrauensliste → EU‑LoTL
• Status‑List / Revokation für ausgestellte Credentials (IETF OAuth Status List)
• Multi‑Credential DCQL‑Queries — aktuell wird der erste Credential‑Eintrag konsumiert
• Phase B Issuer (OID4VCI), damit CodeB‑Tenants eigene Mitglieder‑Credentials ausgeben können

Bis iter‑2 lebt, akzeptiert der Verifier wohlgeformte SD‑JWT VCs für Anwendungsfälle, in denen der Tenant dem Aussteller bei Präsentation vertraut — Pilotdeployments, Identitäts‑Demos, Mitglieder‑Logins. Produktiver hochsichernder Identitätsnachweis sollte auf iter‑2 + eine notifizierte nationale Wallet warten.

Warum das wichtig ist

eIDAS 2.0 verpflichtet jeden EU‑Mitgliedstaat, bis 2026 eine nationale Digital‑Identity‑Wallet auszugeben — und öffentliche Verwaltungen sind verpflichtet, sie zu akzeptieren. Die OID4VP 1.0 / SD‑JWT VC / DCQL‑Specs sind das Drahtformat. Ein funktionierender Verifier ist die Vorbedingung für Wallet‑Anmeldung — ohne ihn ist «EU‑Wallet‑ready» nur eine Marketing-Aussage.

CodeB‑Tenants bekommen den Verifier heute. Self‑hosted, EU‑souverän, NIS2 / DORA aligned, mit verifiziertem Claim‑Relay durch dieselbe OIDC‑Schicht, die der Rest der Plattform schon nutzt.