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 gepflegte X.509-Anker in einem Verzeichnis, das der ETSI TS 119 612-Struktur nachempfunden ist (ein LOTL-förmiger lokaler Trust Store, kein amtliches EU-List-of-Trusted-Lists, das von einem mitgliedstaatlich notifizierten Endpunkt bezogen wird). Iter-3 / iter-3b des SD-JWT-VC-Issuer-Chain-Gates in oidc.ashx verlangt, dass die x5c-Kette im JWS-Header der VC an einem dieser vom Betreiber geladenen Anker terminiert.
Fehlender Zustand: Sind beide Verzeichnisse leer, wird nur der eingebaute LOTL-Cache verwendet. Findet auch der keinen Treffer, entscheidet Oidc:LotlRequireChain (neuer Standard: true ab Build haipclose-cominotto): strikter Modus → HTTP 400 unaufgelöst; explizit nicht-strikt (Oidc:LotlRequireChain=false) → iter-2 SAN-only oder darunter — es sei denn der Tenant läuft im EUDI-Produktionsprofil (eudiProductionProfile=true oder dcqlTrustedAuthoritiesMode=all), dann wird der Downgrade verweigert und ein lotl-chain-compliance-override-Event geloggt.
Bezugsquelle: Zertifikate aus der amtlichen EU List-of-Trusted-Lists unter ec.europa.eu/tools/lotl/eu-lotl.xml oder aus der Trusted List (TSL) Ihres Mitgliedstaats extrahieren und als .cer- / .crt-Dateien in dieses Verzeichnis ablegen (ein automatischer ETSI-TS-119-612-LoTE-Fetcher / Chain-Walker steht auf der Roadmap — heute ist das ein manueller Betreiberschritt), oder eine Issuer-Root verwenden, 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	true (Standard gedreht 2026-07-26 `haipclose-cominotto`)	Strikter SD-JWT-VC-Modus: Iter-3, das die `x5c`-Kette nicht auflösen kann, scheitert geschlossen (HTTP 400). Nicht-strikter Fallback (SAN-only) ist verfügbar durch explizites Setzen von `false`, das EUDI-Produktionsprofil verweigert diesen Downgrade jedoch. Pro-Session-Übersteuerung `?lotl_require_chain=1\|0` bei `vp-start` (siehe eu-wallet-api); im EUDI-Produktionsprofil ignoriert.
Oidc:StatusListCheckMode	enforce (Standard)	OAuth Status List (draft-ietf-oauth-status-list-13) Revokationsprüfung. `enforce` lehnt widerrufene/suspendierte Credentials ab; `warn` loggt und fährt fort; `skip` deaktiviert den Fetch. EUDI-Produktionsprofil erzwingt `enforce`. LOUD `[STATUSLIST-DIAG]`-Traces. Pro-Session-Übersteuerung `?status_list_check=enforce\|warn\|skip` bei `vp-start`; im EUDI-Produktionsprofil ignoriert.
Vci:DpopMode	optional	RFC 9449 DPoP-Proofs an den OpenID4VCI-Endpunkten `?token` + `?credential`. `optional` akzeptiert DPoP-gebundene Tokens und Legacy-Bearer; `enforce` verlangt DPoP-Proofs an beiden Endpunkten (HAIP-strict); `off` deaktiviert. LOUD `[DPOP-DIAG]`-Traces.
Vci:ClientAuthMode	optional	`attest_jwt_client_auth` an OpenID4VCI `?par` + `?token`. `optional` akzeptiert sowohl `client_id`-Whitelist als auch attestierungsbasierte Authentifizierung; `enforce` lehnt Requests ohne gültiges `<WalletAttestation>~<PoP>`-Assertion ab (HAIP-strict); `off` deaktiviert. LOUD `[VCI-CLIENT-AUTH-DIAG]`.
Vci:KeyAttestationMode	optional	ARF-TS3-Key-Attestation-Annahme auf `?credential` (mDoc/JWT- und SD-JWT/JWT-Proof-Pfad). `optional` prüft, wenn die Wallet eine mitliefert, sonst ignoriert; `require` lehnt Wallets ohne Attestation ab (`400 key_attestation_required`); `off` deaktiviert das Gate. Trust-Anchors unter `App_Data/<tenant>/trust/key-attestation-issuers/*.pem` (auch `.cer`, `.crt`). LOUD `[KEY-ATTESTATION-DIAG]`-Traces.
Vci:KeyAttestationRequireSealed	false	ETSI TS 119 182-1 JAdES Baseline B / ARF Juli 2026 — wenn `true`, MUSS das Leaf-Zertifikat der Key-Attestation-`x5c`-Kette die EKU-OID `0.4.0.194112.1.4` (`id-kp-EIDASSeal`) tragen. Fehlt sie, wird mit `cert_not_sealed` abgelehnt. Default `false` akzeptiert Signatur- und Siegel-Zertifikate gleichermassen. Gilt für beide typ-Pfade `key-attestation+jwt` und `key-attestation+jades`. LOUD `[KEY-ATTESTATION-DIAG] sealed-vs-signed`-Trace bei jeder Prüfung.
eudiProductionProfile	false	Wenn `true`, wird `Oidc:LotlRequireChain=true`, `Oidc:StatusListCheckMode=enforce` erzwungen und `Oidc:PidRetentionSeconds=-1` auf 30 Tage geklemmt. Jeder Tenant-Versuch, diese zu schwächen, wird als Compliance-Override protokolliert.
Oidc:WalletClaimDefaultAllowAll	false	Rückwärtskompatibilitäts-Escape für die client-bezogene Wallet-Claim-Allowlist. Standard `false`: existiert keine Allowlist-Datei unter `App_Data/<tenant>/oidc-clients/<client_id>/wallet-claim-allowlist.json`, werden die zusammengeführten Wallet-Claims aus der userinfo-Antwort für diesen Client entfernt (safe-by-default nach VC default-on). `true` stellt das Verhalten vor der Härtung wieder her und reicht alle wallet-basierten Claims durch. RASP: Allowlist-Datei auf 8 KB begrenzt, `allow`-Array auf 32 Einträge begrenzt, jeder Eintrag Regex `^[a-z][a-z0-9_]{0,63}$`. LOUD `[WALLET-CLAIM-ALLOWLIST-DIAG]` in jedem Zweig. Siehe eu-wallet-api § wallet-claim-allowlist.
Oidc:PidRetentionSeconds	2592000 (30 Tage)	Speicher-TTL für verifizierte Person-Identification-Data-Claims (PID) aus einer European Digital Identity Wallet Präsentation, die im Tenant-Nutzerdatensatz persistiert werden. `0` = nie persistieren (nur Sitzung, Write-Pfad wird übersprungen); positive Ganzzahl = Sekunden bis zum Lazy-Ablauf beim nächsten userinfo-Read; `-1` = unbegrenzt (Opt-out) und im Produktionsprofil verweigert (auf 30 Tage geklemmt mit einem `pid-retention-compliance-override`-Audit-Event). Ablauf ist lazy beim Read; kein aktiver Sweeper in dieser Runde. LOUD `[PID-RETENTION-DIAG]`-Traces in den Zweigen written, expired-lazy, skip-write und COMPLIANCE-OVERRIDE. Siehe eu-wallet-api § pid-retention.
Ts7:DisableDeletionRequests	false	ARF 3.0 TS7 Data-Deletion-Request-Endpoint (`POST /oidc.ashx?action=data-deletion-request`). Standardmässig aktiviert gemäss VC default-on-Regel. Auf `true` setzen, damit der Endpunkt `404` liefert — für Tenants, die Löschanträge über einen separaten Kanal abwickeln.
Ts7:DeletionQueueMaxEntries	10000	Harte Obergrenze für die Anzahl eingereihter Deletion-Request-Dateien in `App_Data/<tenant>/data-deletion-queue/`. Bei Überschreitung liefert der Endpunkt `503` mit `Retry-After: 600`. Operator entleert die Warteschlange durch Review + Löschen bearbeiteter Dateien.
WebPhone:AdminSharedSecret	(nicht gesetzt)	HMAC-SHA256-Shared-Secret für den `X-CodeB-Admin-Signature`-Header auf dem TS7-Listing (`?action=data-deletion-list`) und dem TS8-DPA-Report (`?action=dpa-report`). Bucket-String lautet `ts7-ts8-admin`. Nicht gesetzt: die beiden Endpunkte akzeptieren ausschliesslich OIDC-Bearer-JWTs mit `role=admin` oder `role=superuser`. Meta-Audit-Trails werden nach `App_Data/<tenant>/audit/deletion-requests-YYYY-MM.log.jsonl` und `dpa-reports-YYYY-MM.log.jsonl` geschrieben.
Csc:CryptoModuleProvider	software	Provider, der jede CSC-v2-Signaturoperation absichert (`credentials/authorize`, `signatures/signHash`). `software` (Standard, ausgeliefert) → pro Tenant ein ECDsa-P-256-Signaturzertifikat, privater Schlüssel im Windows-CNG-LocalMachine-Key-Set, PFX-Passwort mit DPAPI im LocalMachine-Scope gewickelt, dreistufiger Lifecycle (PFX auf Platte → wacs-ausgestelltes Zertifikat → auto-generiertes selbst-signiertes Sub-Zertifikat). `hsm-azurekv` und `hsm-pkcs11` sind für spätere HSM-Konnektoren reserviert und liefern derzeit HTTP 501 mit `crypto_module_not_configured`. Unbekannte Werte scheitern geschlossen mit demselben Fehler. Die CSC-v2-Antwort `credentials/info` weist das ausgelieferte Modul in `key.protection`, `key.moduleType` und `key.moduleCertification` aus. LOUD-`[CRYPTOMOD-DIAG]`-Traces in jedem Zweig. Siehe eu-wallet-api § crypto-module-architecture.
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 zu einem Anker im vom Betreiber geladenen LOTL-förmigen lokalen Trust Store 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.

Für DSFA- und VVT-Vorlagen siehe /de/dpia.html und /de/ropa.html — der Tenant-DSB passt an und gibt frei; keine Rechtsberatung.

Letzte Aktualisierung 2026-07-26 (haipclose-cominotto). Zugehörige Seiten: HAIP-Verifier-Konformität · EU-Wallet-Verifier-Referenz · API-Referenz · DSFA-Vorlage · VVT-Vorlage · English