Seminar Selektive Offenlegung mit BBS Data Integrity

Der Kurs behandelt die Erzeugung eines BBS-gesicherten Basisnachweises und die Ableitung eines neuen Nachweises, der nur ausgewählte Aussagen offenlegt. Neben der Kryptopipeline werden Datenmodellierung, Nonce-Bindung, Unlinkability, Holder Binding, Einschränkungen und Interoperabilität praktisch untersucht.

Inhaltsverzeichnis

• Einordnung
• Zielgruppe
• Voraussetzungen
• Lernziele
• Seminarinhalte
• Zielbild selektiver Offenlegung
• BBS-Basisproof
• Auswahl offenzulegender Aussagen
• Ableitung eines Proofs
• Verifikation des abgeleiteten Nachweises
• Unlinkability und Korrelationsgrenzen
• Holder Binding und Replay-Schutz
• Statusprüfung und Lifecycle
• Interoperabilität und Grenzen
• Praktische Übungen
• Methodik
• Einordnung im Seminarprogramm

Einordnung

Der Schwerpunkt liegt auf datensparsame abgeleitete Nachweise mit BBS-basierten Kryptosuiten. Die Inhalte werden von der fachlichen Anforderung über Datenmodell und Protokoll bis zu Validierung, Fehlerbehandlung und betrieblichen Kontrollen entwickelt.

Zielgruppe

Wallet-, Issuer- und Verifier-Entwicklung, Kryptografie- und Security Engineering, Datenschutztechnik, Lösungsarchitektur und technische Produktverantwortung.

Voraussetzungen

Gute Kenntnisse von VC 2.0, JSON-LD-Kanonisierung und Data Integrity. Grundverständnis selektiver Offenlegung und asymmetrischer Kryptografie wird vorausgesetzt.

Lernziele

• Basis- und abgeleitete BBS-Proofs unterscheiden
• offenzulegende Aussagen deterministisch auswählen
• abgeleitete Nachweise mit Nonce und Kontext binden
• Unlinkability und verbleibende Korrelationsrisiken bewerten
• Issuer-, Wallet- und Verifier-Pipeline interoperabel gestalten
• Holder Binding und Replay-Schutz ergänzen
• Grenzen gegenüber Prädikatsnachweisen und anderen Verfahren erkennen

Seminarinhalte

Modul 1: Zielbild selektiver Offenlegung

1. Schritt 1: Das vollständige Credential wird vom minimal erforderlichen Offenlegungsergebnis getrennt.
2. Schritt 2: Es wird festgelegt, welche Aussagen sichtbar, verborgen oder durch abgeleitete Aussagen ersetzt werden sollen.
3. Schritt 3: Verifier-Anforderungen werden auf Datenminimierung und fachliche Notwendigkeit geprüft.
4. Schritt 4: Das gewählte Verfahren wird gegen klassische Mehrfach-Credentials und alternative Disclosure-Mechanismen abgegrenzt.

Modul 2: BBS-Basisproof

1. Schritt 1: Das Credential wird in kanonische Aussagen überführt.
2. Schritt 2: Die signierbaren Nachrichten werden in eine stabile Reihenfolge gebracht.
3. Schritt 3: Der Issuer erzeugt einen BBS-basierten Data-Integrity-Proof über die vollständige Aussagemenge.
4. Schritt 4: Die Wallet prüft Basisproof, Issuer-Vertrauen und Datenmodell, bevor eine Ableitung erfolgt.

Modul 3: Auswahl offenzulegender Aussagen

1. Schritt 1: Die Verifier-Anfrage wird in eine konkrete Menge benötigter Claims übersetzt.
2. Schritt 2: Abhängige Strukturinformationen, Typen und erforderliche Kontextaussagen werden ergänzt.
3. Schritt 3: Die Auswahl wird gegen unbeabsichtigte Nebeninformationen und fehlende semantische Bindung geprüft.
4. Schritt 4: Nicht angeforderte Aussagen bleiben außerhalb des abgeleiteten Dokuments.

Modul 4: Ableitung eines Proofs

1. Schritt 1: Eine frische, protokollgebundene Nonce wird in den Ableitungsprozess aufgenommen.
2. Schritt 2: Die Wallet erzeugt aus Basisproof, vollständiger Aussagemenge und Offenlegungsauswahl einen abgeleiteten Proof.
3. Schritt 3: Das resultierende Dokument enthält nur die offengelegten Aussagen und die für die Prüfung notwendigen Daten.
4. Schritt 4: Die Wallet validiert den abgeleiteten Nachweis vor der Übermittlung selbst.

Modul 5: Verifikation des abgeleiteten Nachweises

1. Schritt 1: Der Verifier prüft Struktur, Kontext, Kryptosuite und erwartete Nonce.
2. Schritt 2: Die offengelegten Aussagen werden kanonisiert und mit dem abgeleiteten Proof verifiziert.
3. Schritt 3: Issuer, Credential-Typ, zeitliche Gültigkeit und Status werden nach den normalen Trust-Regeln geprüft.
4. Schritt 4: Die fachliche Entscheidung verwendet ausschließlich die tatsächlich offengelegten und verifizierten Aussagen.

Modul 6: Unlinkability und Korrelationsgrenzen

1. Schritt 1: Wiederholte Ableitungen mit frischen Nonces werden auf kryptografische Verknüpfbarkeit untersucht.
2. Schritt 2: Stabile Identifikatoren, seltene Claim-Kombinationen, Zeitstempel und Netzwerkmetadaten werden als verbleibende Korrelationsquellen bewertet.
3. Schritt 3: Datenmodell und Präsentationsprotokoll werden angepasst, damit die kryptografische Eigenschaft nicht durch Metadaten aufgehoben wird.
4. Schritt 4: Datenschutzversprechen werden präzise formuliert und nicht mit vollständiger Anonymität gleichgesetzt.

Modul 7: Holder Binding und Replay-Schutz

1. Schritt 1: Es wird entschieden, ob der Besitz eines Wallet- oder Holder-Schlüssels zusätzlich nachgewiesen werden muss.
2. Schritt 2: Challenge, Domain und gegebenenfalls Audience werden an die Präsentation gebunden.
3. Schritt 3: Holder-Nachweis und abgeleiteter Issuer-Nachweis werden getrennt geprüft.
4. Schritt 4: Der Verifier verhindert Wiederverwendung durch Nonce-Verbrauch und kurze Akzeptanzfenster.

Modul 8: Statusprüfung und Lifecycle

1. Schritt 1: Die für die Statusprüfung erforderliche Referenz bleibt in der abgeleiteten Darstellung verfügbar.
2. Schritt 2: Der Verifier prüft Statusliste, Aktualität und Statuszweck unabhängig vom Disclosure-Proof.
3. Schritt 3: Es wird bewertet, ob Statusindex oder Listenpartitionierung zusätzliche Korrelation erzeugen.
4. Schritt 4: Erneuerung und Neuausstellung erhalten klare Regeln für bestehende Basis- und abgeleitete Nachweise.

Modul 9: Interoperabilität und Grenzen

1. Schritt 1: Basisproof, Disclosure-Auswahl, Nonce und erwartete Offenlegung werden als Testvektor dokumentiert.
2. Schritt 2: Unabhängige Implementierungen vergleichen die offengelegten kanonischen Aussagen und Verifikationsergebnisse.
3. Schritt 3: Nicht unterstützte Strukturen und Erweiterungen werden früh erkannt und eindeutig abgelehnt.
4. Schritt 4: Prädikatsnachweise, Bereichsnachweise und versteckte Statusprüfung werden als separate Anforderungen behandelt.

Praktische Übungen

• Erzeugung eines Basisproofs über ein mehrteiliges Credential
• Ableitung zweier unterschiedlicher Offenlegungsvarianten
• Verifikation mit richtiger und falscher Nonce
• Analyse verbleibender Korrelationsmerkmale
• Entwurf einer Präsentation mit zusätzlichem Holder Binding

Methodik

Fachliche Einordnung, strukturierte Demonstrationen, gemeinsame Modellierung, angeleitete Implementierungs- und Prüfaufgaben, Negativtests sowie Auswertung typischer Fehlersituationen. Die Übungen verwenden synthetische Beispieldaten und werden schrittweise von einem kontrollierten Normalfall zu Manipulations-, Grenz- und Ausfallszenarien erweitert.

Einordnung im Seminarprogramm

Fortgeschrittene Vertiefung nach Data Integrity, JSON-LD und Privacy Engineering. Nicht als Einstiegskurs geeignet.