Seminar Praxisworkshop – End-to-End Selective Disclosure Credential Lab

Seminarprofil

Der viertägige Praxisworkshop baut eine vollständige Laborplattform aus Issuer, Wallet, Verifier, Statusdienst und Policy-Komponente auf. Mehrere Credential-Formate werden ausgestellt, präsentiert, geprüft, widerrufen und mit automatisierten Sicherheits- und Interoperabilitätstests abgesichert.

Lernziele

• Eine modular getrennte Credential-Laborarchitektur reproduzierbar bereitstellen
• SD-JWT-VC-, AnonCreds- und BBS-basierte Flows praktisch vergleichen
• Status, Holder Binding und fachliche Verifier-Policies formatgerecht integrieren
• Observability und Fehlerdiagnose ohne unnötige personenbezogene Protokollierung umsetzen
• End-to-End-, Negativ-, Interoperabilitäts- und Recovery-Tests automatisieren

Inhaltsübersicht

1. Laborplanung und Komponenten
2. Gemeinsames fachliches Datenmodell
3. SD-JWT-VC-Issuance
4. SD-JWT-VC-Presentation
5. AnonCreds-Issuance
6. AnonCreds-Proof
7. BBS Base Proof
8. BBS Derived Proof
9. Status und Lebenszyklus
10. Policy Engine
11. Wallet- und API-Sicherheit
12. Datensparsame Observability
13. Interoperabilitäts- und Regressionstests
14. Recovery und Betriebsübergabe

Seminarinhalte

Schritt 1: Laborplanung und Komponenten

Die Teilnehmer definieren Issuer, Wallet, Verifier, Registry, Statusdienst und Test-Client als getrennte Komponenten. Konfiguration, Schlüsselmaterial und Testdaten werden versioniert, während Secrets außerhalb des Quellcodes bleiben.

Schritt 2: Gemeinsames fachliches Datenmodell

Ein Qualifikations- und Berechtigungsnachweis wird als formatneutrales Claim-Modell beschrieben. Abbildungstabellen zeigen, welche Eigenschaften in den einzelnen Formaten direkt, nur angenähert oder gar nicht verfügbar sind.

Schritt 3: SD-JWT-VC-Issuance

Der Issuer erzeugt ein Credential mit selektiv offenlegbaren Claims, Salt-Strategie und Holder-Schlüsselbindung. Wallet und Verifier prüfen Typ, Metadaten, Disclosures, Key Binding und Status.

Schritt 4: SD-JWT-VC-Presentation

Mehrere Offenlegungsvarianten werden für unterschiedliche Verifier erstellt. Übungen testen fehlende, doppelte, fremde und manipulierte Disclosures sowie Replay einer Key-Binding-Präsentation.

Schritt 5: AnonCreds-Issuance

Schema, Credential Definition und geblendete Credential Request werden eingerichtet. Das Wallet speichert das Credential und bereitet Revocation-Daten für spätere Präsentationen vor.

Schritt 6: AnonCreds-Proof

Eine Präsentation kombiniert offengelegte Attribute, ein Altersprädikat und Nicht-Widerruf. Restriktionen, Nonce und Witness-Aktualisierung werden mit positiven und negativen Fällen geprüft.

Schritt 7: BBS Base Proof

Ein Data-Integrity-Credential wird kanonisiert und mit einer BBS-Cryptosuite gesichert. Kontexte, Schlüsselauflösung und Proof-Konfiguration werden in reproduzierbare Tests überführt.

Schritt 8: BBS Derived Proof

Das Wallet leitet zwei unterschiedlich minimierte Proofs ab. Der Verifier validiert nur die offengelegten Aussagen und prüft Nonce, Proof Purpose sowie erlaubte Kontexte.

Schritt 9: Status und Lebenszyklus

Ablauf, Statusliste, Revocation Registry und Re-Issuance werden als unterschiedliche Lebenszyklusmechanismen umgesetzt. Die Laborumgebung simuliert veraltete Daten und temporäre Unerreichbarkeit.

Schritt 10: Policy Engine

Formatspezifische Prüfer liefern normalisierte, aber herkunftsmarkierte Ergebnisse an eine fachliche Policy. Assurance, Issuer-Vertrauen, Claim-Werte, Status und Bindung bleiben nachvollziehbar.

Schritt 11: Wallet- und API-Sicherheit

Schlüsselzugriff, Consent, Request-Validierung, sichere Redirects und Eingabegrenzen werden gehärtet. Eine Missbrauchsfallliste steuert zusätzliche Schutzmaßnahmen.

Schritt 12: Datensparsame Observability

Korrelationsarme Ereigniskennungen, strukturierte Fehlerklassen und kurze Aufbewahrung ermöglichen Betrieb ohne Credential-Inhalte im Log. Metriken messen Verfügbarkeit und Fehlerraten statt Nutzerprofile.

Schritt 13: Interoperabilitäts- und Regressionstests

Testvektoren werden zwischen Komponenten und Formaten ausgetauscht. Ein automatisierter Lauf prüft erfolgreiche Flows, manipulierte Artefakte, falsche Schlüssel, Downgrade und inkompatible Versionen.

Schritt 14: Recovery und Betriebsübergabe

Schlüsselrotation, Wallet-Verlust, Statusausfall und Rollback werden simuliert. Runbooks, Freigabekriterien und offene technische Schulden schließen den Laboraufbau ab.

Praxisanteil

• Drei vollständige Credential-Flows in einer gemeinsamen Laborplattform aufbauen
• Formatübergreifende Policy Engine mit getrennten Verifikationsadaptern implementieren
• Statusausfall, Wallet-Verlust und Schlüsselrotation simulieren
• Automatisierte End-to-End- und Angriffstests als reproduzierbare Test-Suite erstellen

Zielgruppe

Erfahrene Entwickler, Architekten, DevSecOps, technische Tester sowie Issuer-, Wallet- und Verifier-Teams

Voraussetzungen

Gute Kenntnisse von APIs, Kryptografiegrundlagen und mindestens einem Credential-Format; eigene Entwicklungsumgebung