Seminar Status, Sperrung und Lebenszyklus datensparsamer Credentials

Seminarprofil

Das Seminar behandelt Gültigkeit und Widerruf als eigenständige Privacy- und Betriebsaufgabe. Verglichen werden Ablauf, kurzlebige Credentials, Statuslisten, AnonCreds-Revocation, Re-Issuance und risikobasierte Online-Prüfung einschließlich Cache, Offline-Betrieb und Ausfallstrategien.

Lernziele

• Statusbedarf aus fachlichem Risiko statt aus Gewohnheit ableiten
• Ablauf, Sperrung, Suspendierung, Re-Issuance und Schlüsselkompromittierung unterscheiden
• Statusmechanismen nach Aktualität, Datenschutz, Verfügbarkeit und Skalierung auswählen
• Caching, Zeitquellen, Offline-Prüfung und Failover sicher planen
• Lebenszyklusereignisse mit Wallet UX, Support und Incident Response verbinden

Inhaltsübersicht

1. Lebenszyklus und Ereignisse
2. Risikobasierte Aktualität
3. Kurzlebige Credentials
4. Statuslisten
5. AnonCreds-Revocation
6. Re-Issuance und Ersetzung
7. Offline- und Cache-Strategie
8. Ausfall- und Angriffsmodelle
9. Privacy und Beobachtbarkeit
10. Wallet UX und Support
11. Runbooks und Testfälle

Seminarinhalte

Schritt 1: Lebenszyklus und Ereignisse

Ausstellung, Aktivierung, Ablauf, Suspendierung, Widerruf, Ersetzung und Archivierung werden fachlich getrennt. Jedes Ereignis erhält Auslöser, Verantwortlichkeit und erwartete Verifier-Reaktion.

Schritt 2: Risikobasierte Aktualität

Nicht jeder Nachweis benötigt sekundengenaue Sperrprüfung. Schadenshöhe, Transaktionswert, Offline-Bedarf und Wiederholbarkeit bestimmen das akzeptierte Aktualitätsfenster.

Schritt 3: Kurzlebige Credentials

Kurze Gültigkeit kann zentrale Sperrinfrastruktur reduzieren, erhöht aber Re-Issuance und Abhängigkeit vom Issuer. Grace Period, Uhrabweichung und Wallet-Erneuerung werden berücksichtigt.

Schritt 4: Statuslisten

Komprimierte Statusinformationen ermöglichen datensparsame Verteilung. Indexvergabe, Listenrotation, Cache, Aktualisierungsfrequenz und die Vermeidung gezielter Einzelabfragen werden entworfen.

Schritt 5: AnonCreds-Revocation

Revocation Registry, Akkumulator, Tails-Daten, Witness und Nicht-Widerrufsintervalle werden als Betriebsprozess betrachtet. Aktualisierungs- und Verfügbarkeitsanforderungen werden dokumentiert.

Schritt 6: Re-Issuance und Ersetzung

Bei Datenänderung, Schlüsselrotation oder Migration kann Neu-Ausstellung sicherer sein als komplexe Statuslogik. Alte und neue Credentials dürfen keine widersprüchlichen Berechtigungen erzeugen.

Schritt 7: Offline- und Cache-Strategie

Verifier speichern Statusdaten kontrolliert und prüfen Alter, Herkunft und Integrität. Offline-Entscheidungen erhalten ein begrenztes Risikoprofil und nachvollziehbare Nachprüfung.

Schritt 8: Ausfall- und Angriffsmodelle

Nicht erreichbare Dienste, Cache Poisoning, Rollback auf alte Listen, falsche Zeit und gezielte DoS-Angriffe werden simuliert. Fail-open und Fail-closed werden pro Geschäftsvorgang entschieden.

Schritt 9: Privacy und Beobachtbarkeit

Einzelne Statusabfragen können Nutzung offenlegen. Verteilte Listen, anonyme Abrufe, Proxies, Vorladen und reduzierte Telemetrie werden nach Wirksamkeit bewertet.

Schritt 10: Wallet UX und Support

Nutzer benötigen verständliche Hinweise bei Ablauf, Sperrung oder erforderlicher Aktualisierung. Support darf keine Umgehung sicherheitsrelevanter Kontrollen schaffen.

Schritt 11: Runbooks und Testfälle

Status-Publishing, Rotation, Incident, Recovery und Monitoring werden in Runbooks überführt. Tests decken frisch, veraltet, widerrufen, unbekannt, offline und inkonsistent ab.

Praxisanteil

• Statusanforderungen für mehrere Risikoklassen festlegen
• Statuslisten- und Cache-Konzept mit Privacy-Kontrollen entwerfen
• AnonCreds-Nicht-Widerrufsfall und Ausfallstrategie modellieren
• Status-Testmatrix und Betriebs-Runbook erstellen

Zielgruppe

Architekten, Plattform- und Betriebsteams, Wallet- und Verifier-Entwickler, Security und Governance-Verantwortliche

Voraussetzungen

Grundkenntnisse von Credential-Systemen, APIs und Public-Key-Kryptografie