Seminar SD-JWT VC – Implementierung für Issuer, Wallet und Verifier

Seminarprofil

Das dreitägige Implementierungsseminar entwickelt einen vollständigen SD-JWT-VC-Stack. Issuer-Erzeugung, Wallet-Speicherung und Disclosure-Auswahl, Key-Binding-Präsentation, Verifier-Pipeline, Typmetadaten, Status, Protokollintegration und automatisierte Angriffstests werden praktisch umgesetzt.

Lernziele

• SD-JWT VC mit konsistentem Typ-, Claim- und Disclosure-Modell ausstellen
• Wallet-Speicherung, Auswahl und Consent ohne Disclosure-Verwechslung implementieren
• Key Binding, Nonce, Audience und Präsentationshash vollständig prüfen
• Typmetadaten, Status und Issuer Trust sicher auflösen und cachen
• End-to-End- und Negativtests als automatisierte Conformance-Suite aufbauen

Inhaltsübersicht

1. Repository und Sicherheitsgrenzen
2. Credential-Typ und Claim-Definition
3. Issuer-Implementierung
4. Type Metadata
5. Wallet-Ingestion
6. Disclosure-Auswahl und Consent
7. Key-Binding-Präsentation
8. Verifier-Eingangsprüfung
9. Kryptografische Verifikation
10. Status und Lebenszyklus
11. Protokollintegration
12. Angriffstests
13. Betrieb und Observability

Seminarinhalte

Schritt 1: Repository und Sicherheitsgrenzen

Issuer, Wallet, Verifier und gemeinsame Testvektoren werden in getrennten Modulen aufgebaut. Secrets, Testschlüssel, Produktionskonfiguration und simulierte Trust Stores bleiben sauber getrennt.

Schritt 2: Credential-Typ und Claim-Definition

Ein versionierter Credential-Typ legt Datentypen, Pflichtfelder und Offenlegungspolitik fest. Validierung erfolgt bereits vor der kryptografischen Erzeugung.

Schritt 3: Issuer-Implementierung

Disclosures, Salts, Digests, sichtbare Claims und Schlüsselbestätigung werden erstellt. Algorithmus-Policy, Zeitangaben und eindeutige Fehlerklassen werden implementiert.

Schritt 4: Type Metadata

Metadaten werden veröffentlicht, signiert oder anderweitig integritätsgesichert und vom Wallet kontrolliert verarbeitet. Cache-Invalidierung und Versionskonflikte werden getestet.

Schritt 5: Wallet-Ingestion

Das Wallet prüft Issuer-Signatur, Typ, Algorithmen und Disclosure-Zuordnung vor der Speicherung. Unbekannte kritische Eigenschaften oder inkonsistente Metadaten führen zur Ablehnung.

Schritt 6: Disclosure-Auswahl und Consent

Aus einer Verifier-Anfrage wird eine minimal passende Auswahl abgeleitet. Die Benutzeroberfläche zeigt Werte und Empfänger, ohne versteckte Pflichtoffenlegungen zu verschleiern.

Schritt 7: Key-Binding-Präsentation

Das Wallet erzeugt eine kontextgebundene Proof-Komponente mit Nonce, Audience, Zeit und Hash über die konkrete Präsentation. Schlüsselzugriff wird lokal autorisiert.

Schritt 8: Verifier-Eingangsprüfung

Transport, Content Type, Größenlimits, Serialisierung und erwarteter Flow werden vor kryptografischer Verarbeitung geprüft. Ungeprüfte Claims gelangen nicht in Logs oder Geschäftslogik.

Schritt 9: Kryptografische Verifikation

Issuer-Signatur, Algorithmen, Digests, Disclosures, Holder-Schlüssel, Key Binding, Nonce, Audience und Zeitfenster werden in einer deterministischen Pipeline validiert.

Schritt 10: Status und Lebenszyklus

Statusprüfung, Ablauf, Schlüsselrotation und Re-Issuance werden integriert. Fail-open- und Fail-closed-Entscheidungen werden je Geschäftsrisiko dokumentiert.

Schritt 11: Protokollintegration

Credential Issuance und Presentation werden mit OpenID-basierten Flows oder klaren API-Verträgen verbunden. Formatverhandlung und Downgrade-Schutz erhalten eigene Testfälle.

Schritt 12: Angriffstests

Fremde Disclosures, Algorithmusverwechslung, doppelte Claims, manipulierte Metadaten, Replay, falsche Audience und veralteter Status werden automatisiert geprüft.

Schritt 13: Betrieb und Observability

Metriken, korrelationsarme Logs, Rate Limits, Schlüsselrotation und Incident-Abläufe werden ergänzt. Ein Runbook beschreibt Diagnose ohne Speicherung vollständiger Präsentationen.

Praxisanteil

• Issuer, Wallet und Verifier als getrennte Dienste implementieren
• Key-Binding-Präsentation mit minimaler Disclosure-Auswahl durchführen
• Type-Metadata- und Status-Cache mit kontrolliertem Fehlerverhalten bauen
• Automatisierte Conformance- und Angriffstests ausführen

Zielgruppe

Softwareentwickler, Wallet- und Backend-Teams, DevSecOps, Security Engineers und technische Tester

Voraussetzungen

Gute Kenntnisse von JWT/JWS, APIs und automatisierten Tests; SD-JWT-Grundlagen