HAIP-Verifier — Betreiber-Setup

Runbook für IT-Administratoren, die den CodeB HAIP-Verifier pro Tenant als IIS-Site ausrollen. Beschreibt die drei vom Betreiber gepflegten Vertrauensanker-Speicher, die zwei zugehörigen Tenant-Einstellungen und die Post-Deploy-Smoketests, mit denen jeder Speicher verifiziert wird.

Optionale Einrichtung, ehrliche Gates. Der Verifier startet und beantwortet Anfragen auch ohne Vertrauensanker. Aber ohne sie geben HAIP-konforme Credential-Pfade HTTP 501 mit klarer Diagnose zurück (mdoc_verify_not_configured, wallet_attestation_not_configured) — statt einem Wallet stillschweigend zu vertrauen. Diese Seite beschreibt, was ein Betreiber vor dem Produktivbetrieb tut.

1. mDoc-Issuer-Anker

Verzeichnis: App_Data/<tenant>/trust/mdoc-issuers/
Dateiformat: *.cer oder *.crt — DER- oder PEM-codierte X.509-Zertifikate
Zweck: Vertrauensanker für ISO 18013-5 mDoc-Credentials. Der Verifier läuft die x5chain in jedem DeviceResponse-IssuerAuth-COSE_Sign1 hoch und verlangt, dass sie an einem dieser Anker terminiert.
Fehlender Zustand: HTTP 501 mdoc_verify_not_configured bei jeder mDoc-Credential-Verifikation und bei jeder VP, deren Token mit einem mso_mdoc-CBOR-Map-Header beginnt.
Bezugsquelle: Vom PID-Issuer oder von der ausstellenden Behörde des Mitgliedstaats, dessen mDL / PID akzeptiert werden soll. Ebenso für die eigene MDocIssuer-Testroot verwendbar.

New-Item -ItemType Directory -Force `
  -Path 'C:\inetpub\wwwroot\<tenant>\App_Data\<tenant>\trust\mdoc-issuers'
Copy-Item .\pid-issuer-root.cer `
  'C:\inetpub\wwwroot\<tenant>\App_Data\<tenant>\trust\mdoc-issuers\'

2. Wallet-Provider-Anker — HAIP §5.11

Verzeichnis: App_Data/<tenant>/trust/wallet-providers/
Dateiformat: *.jwks.json (JSON Web Key Set) oder *.pem (SPKI oder X.509-CERT)
Zweck: Öffentliche Schlüssel, mit denen die von einem Wallet vorgelegte Wallet-Attestation-JWT signiert wurde (draft-ietf-oauth-attestation-based-client-auth).
Fehlender Zustand: HTTP 501 wallet_attestation_not_configured, sobald ein Wallet wallet_attestation liefert oder der Tenant Oidc:WalletAttestationRequired=true gesetzt hat.
Bezugsquelle: Vom Attestation-Issuer-Dienst des Wallet-Herstellers (JWKS-Endpoint-Export) oder von dem Betreiber, den Sie mit der Attestation-Ausstellung beauftragt haben.

Invoke-WebRequest 'https://wallet-vendor.example/attestation-issuer/jwks.json' `
  -OutFile 'C:\inetpub\wwwroot\<tenant>\App_Data\<tenant>\trust\wallet-providers\vendor-a.jwks.json'

3. SD-JWT-VC-Issuer-Anker — LOTL-Overlay

Verzeichnis: App_Data/<tenant>/trust/vc-issuers/ (bevorzugt). Legacy-Fallback: App_Data/<tenant>/trust/mdoc-issuers/.
Dateiformat: *.cer oder *.crt — DER- oder PEM-codiertes X.509
Zweck: Vom Betreiber gepflegtes Overlay über dem eingebauten EU-LOTL-Cache. Iter-3 / iter-3b des SD-JWT-VC-Issuer-Chain-Gates in oidc.ashx verlangt, dass die x5c-Kette im JWS-Header der VC entweder am LOTL-Cache oder an einem dieser Anker terminiert.
Fehlender Zustand: Sind beide Verzeichnisse leer, wird nur der eingebaute LOTL-Cache verwendet. Findet auch der keinen Treffer, entscheidet Oidc:LotlRequireChain: strikter Modus → HTTP 400 unaufgelöst; nicht-strikt → iter-2 SAN-only oder darunter.
Bezugsquelle: Die EU List-of-the-Lists unter ec.europa.eu/tools/lotl/eu-lotl.xml, die Trusted List (TSL) Ihres Mitgliedstaats oder eine Issuer-Root, die Sie out-of-band erhalten haben.

Einstellungen pro Tenant

Einstellung	Default	Wirkung wenn aktiv
Oidc:WalletAttestationRequired	false	Der Verifier kündigt `wallet_attestation_required=true` in der JAR an und lehnt OID4VP-Antworten ohne gültige `wallet_attestation`-JWT ab.
Oidc:LotlRequireChain	false	Strikter SD-JWT-VC-Modus: Iter-3, das die `x5c`-Kette nicht auflösen kann, scheitert geschlossen (HTTP 400) statt auf iter-2 SAN-only durchzufallen.
Recording:AppDataRoot	(nicht gesetzt)	Überschreibt das Standardverzeichnis `App_Data/<tenant>/recordings/` — nützlich, um auf ein dediziertes Volume zu zeigen.

Zu setzen über App_Data/<tenant>/appsettings.json oder in der Tenant-Admin-UI (Einstellungen → OIDC / Recording).

Post-Deploy-Smoketests

Jedes Skript adressiert einen laufenden Tenant und beendet sich entweder mit Exit-Code 0 (grün) oder gibt eine Diagnose aus. Ausführbar von jedem Windows- oder Linux-Host, der den Tenant-HTTPS-Endpoint erreicht.

Skript	Was es abprüft
testscripts/mdoc-cred-verify-smoke.py	Round-Trip eines selbst ausgestellten mDoc durch den Credential-Verify-Endpoint. Grün bedeutet, dass die Anker unter `trust/mdoc-issuers/` geladen sind und die Chain-Walk-Prüfung greift.
testscripts/wallet-attestation-smoke.py	Sendet einen OID4VP-Flow mit Wallet-Attestation-JWT und PoP. Grün bedeutet, dass die Anker unter `trust/wallet-providers/` geladen sind und die JWT verifiziert.
testscripts/lotl-iter3-smoke.py	Legt eine SD-JWT VC mit `x5c`-Kette vor und bestätigt, dass Iter-3 bis zum Betreiber-Overlay oder EU-LOTL-Cache hochläuft.
testscripts/wa-pop-selfcheck.py	Prüft die Negativ-Pfade des Wallet-Attestation-Verifiers (falscher Alg, fehlendes cnf, fehlendes iat, PoP-Nonce/Aud-Fehltreffer) ohne Produktions-Credentials. Grün bedeutet, dass alle Reject-Zweige ihre erwarteten Diagnose-Gründe ausgeben.
testscripts/dcql-smoke.py	Treibt eine OID4VP-1.0-FINAL-DCQL-Abfrage end-to-end — guter abschließender Sanity-Check, sobald alle drei Anker-Speicher stehen.

Ehrlichkeit. Der Verifier ist gegen die OpenID-Foundation-Alpha-Suite HAIP-1.0-FINAL conformance-tested (Selbsttest-Nachweise). Er ist noch nicht auf der OIDF-Seite der zertifizierten Implementierungen gelistet — die formale Einreichung steht auf der Roadmap. Die hier dokumentierten Pfade für mDoc, Wallet-Attestation und LOTL-Overlay sind gegen ihre jeweiligen Spezifikationen spec-konform; eine unabhängige Zertifizierung dieser Pfade folgt, sobald der OIDF-Harness die entsprechende Abdeckung liefert.

Letzte Aktualisierung 2026-07-23. Zugehörige Seiten: HAIP-Verifier-Konformität · EU-Wallet-Verifier-Referenz · API-Referenz · English