Seminar Selective Disclosure – Intensivseminar für Architektur, Implementierung, Betrieb und Security

Seminarprofil

Das fünftägige Intensivseminar bündelt das gesamte Portfolio in einer durchgängigen Lern- und Laborstrecke. SD-JWT VC, AnonCreds, BBS Data Integrity und allgemeine Zero-Knowledge-Verfahren werden technisch verglichen, implementiert, in Issuance und Presentation integriert, betrieben und sicherheitlich geprüft.

Lernziele

• Technologie- und Architekturentscheidungen über alle relevanten Selective-Disclosure-Ansätze treffen
• Issuer-, Wallet- und Verifier-Flows für SD-JWT VC, AnonCreds und BBS praktisch umsetzen
• ZKP-Prädikate, Holder Binding, Status und Lebenszyklus passend kombinieren
• Interoperabilität, Migration, Datenschutz und Betrieb in einer Zielarchitektur zusammenführen
• Security-, Conformance- und Privacy-Tests als Freigabebasis etablieren

Inhaltsübersicht

1. Grundlagen, Schutzziele und Trust Model
2. Technologievergleich und Auswahl
3. Verifiable Credentials und Protokollschichten
4. SD-JWT-Struktur und Disclosures
5. SD-JWT VC und Type Metadata
6. Key Binding und Verifier-Pipeline
7. AnonCreds-Datenmodell
8. AnonCreds-Proofs und Prädikate
9. AnonCreds-Revocation
10. BBS-Kryptografie und Kanonisierung
11. BBS Base und Derived Proofs
12. Zero-Knowledge-Grundmuster
13. OpenID-basierte Issuance
14. OpenID-basierte Presentation
15. Holder- und Device-Binding
16. Status und Lebenszyklus
17. Interoperabilität und Migration
18. Datenschutz und Threat Modeling
19. Security und Conformance Testing
20. Betrieb, Recovery und Abschlusslabor

Seminarinhalte

Schritt 1: Grundlagen, Schutzziele und Trust Model

Selective Disclosure, Datenminimierung, Unlinkability, Holder Binding und Zero Knowledge werden präzise getrennt. Ein gemeinsamer Use Case liefert Assets, Rollen, Vertrauensgrenzen und messbare Schutzanforderungen.

Schritt 2: Technologievergleich und Auswahl

SD-JWT VC, AnonCreds, BBS und allgemeine ZKP werden nach Aussagefähigkeit, Reife, Interoperabilität, Offline-Fähigkeit, Privacy, Performance und Betriebsaufwand bewertet. Die Auswahl wird als Architecture Decision Record dokumentiert.

Schritt 3: Verifiable Credentials und Protokollschichten

Credential-Datenmodell, kryptografischer Proof, Issuance, Presentation, Status und Trust werden als separate Schichten modelliert. Dadurch bleiben hybride Architekturen und Migration möglich.

Schritt 4: SD-JWT-Struktur und Disclosures

Salts, Digests, sichtbare Claims, verschachtelte Objekte und Arrays werden implementiert. Manipulierte oder fremde Disclosures bilden erste Negativtests.

Schritt 5: SD-JWT VC und Type Metadata

Credential-Typ, Claim-Semantik, Offenlegungspolitik und vertrauenswürdige Typmetadaten werden aufgebaut. Issuer und Wallet prüfen Versionen und Algorithmus-Policy.

Schritt 6: Key Binding und Verifier-Pipeline

Holder-Schlüssel, Nonce, Audience, Zeit und Präsentationshash werden in einen vollständigen Prüfpfad integriert. Replay und Teilakzeptanz werden verhindert.

Schritt 7: AnonCreds-Datenmodell

Schema, Credential Definition, Link Secret und geblendete Credential Request werden eingerichtet. Die Unterschiede zum JWT-basierten Modell werden praktisch sichtbar.

Schritt 8: AnonCreds-Proofs und Prädikate

Offengelegte Attribute, verborgene Werte, numerische Prädikate und Multi-Credential-Proofs werden erzeugt. Restriktionen und Nonces werden als verbindlicher Prüfvertrag behandelt.

Schritt 9: AnonCreds-Revocation

Revocation Registry, Tails-Daten, Witness-Aktualisierung und Nicht-Widerrufsintervalle werden integriert. Verfügbarkeit und Datenschutz werden im Betriebsmodell berücksichtigt.

Schritt 10: BBS-Kryptografie und Kanonisierung

Mehrnachrichtensignatur, RDF-Kanonisierung, Nachrichtenzuordnung und Proof-Konfiguration werden nachvollzogen. Kontext- und Serialisierungsabweichungen werden getestet.

Schritt 11: BBS Base und Derived Proofs

Ein Base Proof wird ausgestellt und durch den Holder in mehrere selektiv offengelegte Derived Proofs überführt. Nonce und randomisierte Proof-Erzeugung unterstützen nicht verkettbare Präsentationen.

Schritt 12: Zero-Knowledge-Grundmuster

Witness, Statement, Commitment, Challenge und Response werden anhand kleiner Protokolle verstanden. Prädikate, Range Proofs und Equality-Beziehungen werden in Credential-Szenarien eingeordnet.

Schritt 13: OpenID-basierte Issuance

Credential Offer, Authorization, Proof und Credential Response werden zu einem sicheren Flow verbunden. Metadaten, Redirects, PKCE und Pre-Authorized Codes erhalten konkrete Prüfregeln.

Schritt 14: OpenID-basierte Presentation

Verifier Requests, Credential-Auswahl, Consent, Response Modes und Validierung werden implementiert. Übermäßige Anfragen und Downgrade werden als Missbrauchsfälle behandelt.

Schritt 15: Holder- und Device-Binding

Key Binding, Link Secret, gerätegebundene Schlüssel, Mehrgerätebetrieb, Recovery und Delegation werden verglichen. Der Schutzbedarf bestimmt die Bindungsstärke.

Schritt 16: Status und Lebenszyklus

Ablauf, Statuslisten, kryptografische Revocation, kurzlebige Credentials und Re-Issuance werden kombiniert. Cache-, Offline- und Ausfallstrategien werden dokumentiert.

Schritt 17: Interoperabilität und Migration

Formatneutrales Claim-Modell, Trust Mapping, Dual Issuance, Re-Issuance und Cross-Format-Verifier werden entworfen. Gateway-Risiken und Eigenschaftsverlust bleiben transparent.

Schritt 18: Datenschutz und Threat Modeling

Korrelation durch Attribute, Anfragen, Netzwerk, Telemetrie, Logs und Status wird untersucht. Technische und organisatorische Kontrollen werden priorisiert.

Schritt 19: Security und Conformance Testing

Parser-, Kryptografie-, Protokoll-, Replay-, Downgrade-, Status- und Privacy-Tests werden automatisiert. Golden Files und negative Testvektoren bilden eine wiederholbare Suite.

Schritt 20: Betrieb, Recovery und Abschlusslabor

Observability, Schlüsselrotation, Incident Response, Ausfalltests und Freigabekriterien werden in Runbooks überführt. Das Abschlusslabor verbindet Issuer, Wallet, Verifier, Status und Policy in einer getesteten Referenzarchitektur.

Praxisanteil

• Architektur- und Technologieentscheidung für einen durchgängigen Use Case dokumentieren
• SD-JWT-VC-, AnonCreds- und BBS-Flows in einer Laborumgebung umsetzen
• Prädikats-, Status-, Holder-Binding- und Protokolltests kombinieren
• Cross-Format-Policy Engine und Migrationspfad entwerfen
• Security- und Privacy-Test-Suite mit Betriebs-Runbook erstellen

Zielgruppe

Erfahrene Entwickler, Enterprise- und Solution-Architekten, Security Engineers, technische Projektleitungen, Wallet-, Issuer- und Verifier-Teams

Voraussetzungen

Gute Kenntnisse von APIs, digitalen Identitäten, JWT oder Verifiable Credentials sowie sichere Programmierpraxis