Seminar Architekturworkshop – Privacy-preserving Credential Systems

Seminarprofil

Der Workshop entwickelt eine herstellerneutrale Zielarchitektur für datensparsame Credential-Systeme. SD-JWT VC, AnonCreds, BBS-basierte Data-Integrity-Nachweise und weitere ZKP-Verfahren werden anhand von Schutzbedarf, Interoperabilität, Betrieb und Migrationsfähigkeit bewertet.

Lernziele

• Geschäftsanforderungen in überprüfbare Privacy- und Security-Ziele übersetzen
• Trust Boundaries, Datenflüsse und Angriffsflächen eines Credential-Ökosystems modellieren
• Kryptografisches Format, Austauschprotokoll, Statusmechanismus und Wallet-Bindung getrennt auswählen
• Technologieentscheidungen mit nachvollziehbaren Kriterien und Ausschlussgründen dokumentieren
• Eine umsetzbare Roadmap mit Pilot, Absicherung, Migration und Betriebsübergabe erstellen

Inhaltsübersicht

1. Use Cases und Muss-Kriterien
2. Datenklassifikation und Privacy-Ziele
3. Trust Model und Rollen
4. Technologiebausteine entkoppeln
5. Optionenvergleich
6. Threat Modeling
7. Referenzarchitektur
8. Entscheidungsprotokoll und Roadmap

Seminarinhalte

Schritt 1: Use Cases und Muss-Kriterien

Fachliche Nachweise werden auf minimale Aussagen reduziert. Muss-, Soll- und Kann-Anforderungen verhindern, dass ein einzelner Produktwunsch vorschnell zur Architekturvorgabe wird.

Schritt 2: Datenklassifikation und Privacy-Ziele

Attribute, Identifikatoren, Statusdaten und Telemetrie werden klassifiziert. Daraus werden Anforderungen an Datenminimierung, Unverkettbarkeit, Offline-Fähigkeit, Auditierbarkeit und Löschung abgeleitet.

Schritt 3: Trust Model und Rollen

Issuer, Holder, Verifier, Registry, Wallet Provider und Governance-Stellen werden mit Verantwortlichkeiten versehen. Vertrauensannahmen und mögliche Kollusion werden explizit dokumentiert.

Schritt 4: Technologiebausteine entkoppeln

Credential-Format, Signaturverfahren, Issuance, Presentation, Holder Binding, Status und Policy werden als eigenständige Architekturentscheidungen betrachtet. Dadurch lassen sich hybride Lösungen und spätere Migrationen sauberer planen.

Schritt 5: Optionenvergleich

SD-JWT VC, AnonCreds, BBS und allgemeine ZKP-Ansätze werden nach Offenlegungsmodell, Unverkettbarkeit, Rechenaufwand, Reifegrad, Bibliothekslage und Integrationskosten verglichen.

Schritt 6: Threat Modeling

Missbrauchsfälle wie korrelierbare Präsentationen, überpräzise Anfragen, bösartige Issuer, kompromittierte Wallets und Status-Tracking werden analysiert. Gegenmaßnahmen werden technischen oder organisatorischen Kontrollen zugeordnet.

Schritt 7: Referenzarchitektur

Aus den Ergebnissen entsteht ein logisches Komponentenmodell mit Vertrauensgrenzen, Schnittstellen und Datenhaltung. Abhängigkeiten zu IAM, PKI, HSM, Mobile Security, API Gateway und Monitoring werden sichtbar gemacht.

Schritt 8: Entscheidungsprotokoll und Roadmap

Architecture Decision Records halten Wahl, Alternativen, Konsequenzen und offene Risiken fest. Ein Stufenplan beschreibt Proof of Concept, Pilot, Interoperabilitätstest, Security Review und Produktionsfreigabe.

Praxisanteil

• Anforderungs- und Kriterienmatrix für einen eigenen Anwendungsfall ausfüllen
• Datenflussdiagramm und Threat Model im Team erstellen
• Zielarchitektur sowie priorisierte Umsetzungsroadmap dokumentieren

Zielgruppe

Enterprise- und Solution-Architekten, CISO-Organisationen, Datenschutz, Produktverantwortliche und technische Programmleitungen

Voraussetzungen

Erfahrung mit Identitätsarchitekturen, API-Systemen oder Informationssicherheitsmanagement