Seminar Interoperabilität und Migration zwischen SD-JWT VC, AnonCreds und BBS

Seminarprofil

Das Seminar entwickelt Interoperabilitäts- und Migrationsstrategien für heterogene Credential-Landschaften. Es trennt fachliche Semantik, Credential-Format, kryptografischen Proof, Austauschprotokoll, Status und Governance und zeigt sichere Koexistenz statt verlustbehafteter Formatkonvertierung.

Lernziele

• Interoperabilität auf Daten-, Protokoll-, Trust- und Policy-Ebene unterscheiden
• Gemeinsame Fachmodelle und kontrollierte Vokabulare formatübergreifend definieren
• Gateway-, Dual-Issuance- und Re-Issuance-Strategien mit ihren Risiken bewerten
• Migrationswellen mit Rückwärtskompatibilität und nachvollziehbarer Vertrauenskette planen
• Konformitäts- und Cross-Stack-Tests für Issuer, Wallet und Verifier aufbauen

Inhaltsübersicht

1. Interoperabilitätsebenen
2. Fachliches Claim-Modell
3. Vertrauens- und Issuer-Mapping
4. Proof-Eigenschaften vergleichen
5. Protokolle und Wallet-Fähigkeiten
6. Status und Lebenszyklus
7. Migrationsmuster
8. Gateway- und Übersetzungsrisiken
9. Cross-Format-Verifier
10. Testmatrix und Conformance
11. Migrationsroadmap

Seminarinhalte

Schritt 1: Interoperabilitätsebenen

Syntaxkompatibilität, semantische Gleichheit, kryptografische Prüfbarkeit, Protokollkompatibilität und gemeinsame Governance werden getrennt. Ein erfolgreiches JSON-Parsing gilt ausdrücklich nicht als Ende-zu-Ende-Interoperabilität.

Schritt 2: Fachliches Claim-Modell

Attribute, Datentypen, Kardinalitäten und zulässige Werte werden unabhängig vom Credential-Format beschrieben. Mapping-Regeln dokumentieren Informationsverlust, Rundung, Normalisierung und unterschiedliche Null-Semantik.

Schritt 3: Vertrauens- und Issuer-Mapping

Issuer-Identifier, Schlüsselmodelle, Registries und Trust Lists unterscheiden sich. Die Migration definiert, wann Identitäten übernommen, neu geprüft oder durch einen Bridge-Issuer attestiert werden dürfen.

Schritt 4: Proof-Eigenschaften vergleichen

Hash-basierte Disclosures, CL-basierte Prädikate und BBS-derived Proofs bieten unterschiedliche Aussagen. Eine Konvertierung darf keine stärkere Privacy- oder Security-Eigenschaft vortäuschen, als die Quelle tatsächlich besitzt.

Schritt 5: Protokolle und Wallet-Fähigkeiten

Issuance und Presentation werden von Credential-Formaten getrennt. Capability Negotiation, Format-Metadaten, Wallet-Auswahl und klare Fehlermeldungen ermöglichen parallele Unterstützung.

Schritt 6: Status und Lebenszyklus

Statuslisten, Revocation Registries, Ablauf und Re-Issuance werden auf gemeinsame Geschäftsregeln abgebildet. Unterschiede bei Aktualität und Offline-Verifikation werden in der Policy sichtbar gehalten.

Schritt 7: Migrationsmuster

Big Bang, Parallelbetrieb, Dual Issuance, Re-Issuance und Verifier-first-Migration werden verglichen. Für jedes Muster werden Vertrauensrisiko, Nutzerbelastung, Rollback und Betriebsdauer bewertet.

Schritt 8: Gateway- und Übersetzungsrisiken

Ein Gateway, das Credentials liest und neu ausstellt, wird faktisch zu einem zusätzlichen Issuer und Datenschutzakteur. Schlüssel, Audit, Haftung und Datenminimierung müssen entsprechend behandelt werden.

Schritt 9: Cross-Format-Verifier

Ein Verifier normalisiert nur nach erfolgreicher formatspezifischer Prüfung in ein internes Entscheidungsmodell. Herkunft, Proof-Typ, Assurance und Offenlegungsumfang bleiben als Sicherheitskontext erhalten.

Schritt 10: Testmatrix und Conformance

Testfälle decken Formatverhandlung, Claim-Mapping, Status, Holder Binding, Fehlercodes und Downgrade-Angriffe ab. Referenzartefakte werden versioniert und zwischen Implementierungen ausgetauscht.

Schritt 11: Migrationsroadmap

Abhängigkeiten, Pilotgruppen, Datenbereinigung, Re-Issuance, Abschaltung alter Verifier und Support werden zeitlich geordnet. Messpunkte zeigen, wann die nächste Welle freigegeben werden kann.

Praxisanteil

• Formatübergreifendes Claim- und Trust-Mapping erstellen
• Dual-Issuance- oder Re-Issuance-Migrationsmuster bewerten
• Cross-Stack-Testmatrix für Wallet und Verifier entwickeln
• Downgrade- und Gateway-Risiken in einem Threat Model prüfen

Zielgruppe

Enterprise-Architekten, Integrations- und Plattformteams, Programmleitungen, Governance-Verantwortliche und technische Product Owner

Voraussetzungen

Gute Kenntnisse mindestens eines Credential-Stacks und Erfahrung mit Schnittstellen- oder Migrationsprojekten