Seminar EBSI und swiyu – Architektur- und Migrationsbriefing

Das Briefing schafft in kurzer Zeit eine belastbare Entscheidungsgrundlage für Organisationen, die EBSI, swiyu oder eine Koexistenz beider Ökosysteme bewerten. Technische Unterschiede werden mit Governance, Betriebsfolgen und Migrationsoptionen verbunden.

Inhaltsübersicht

• Zielsetzung
• Zielgruppe
• Voraussetzungen
• Seminarinhalte
• Praxisübungen
• Methodik

Zielsetzung

• EBSI und swiyu hinsichtlich Architektur, Credential-Format, DID, Trust und Protokollprofil vergleichen
• Direkte Interoperabilität, Adapter, Dual-Stack und Neu-Ausstellung realistisch voneinander abgrenzen
• Migrationsrisiken, Abhängigkeiten und Entscheidungsbedarf frühzeitig sichtbar machen
• Eine priorisierte Roadmap für Analyse, Pilot, Koexistenz und Umstellung ableiten

Zielgruppe

IT-Leitung, Enterprise-Architektur, Programm- und Projektleitung, Product Owner, Informationssicherheit, Beschaffung und fachliche Entscheidungsgremien.

Voraussetzungen

Grundverständnis digitaler Identitäten und Verifiable Credentials. Technische Implementierungskenntnisse sind nicht erforderlich.

Seminarinhalte

1. Schritt 1: Zielbild und Entscheidungsfrage klären

   Geschäftszweck, Nutzergruppen, nationale oder grenzüberschreitende Reichweite, Zeitrahmen und regulatorische Rahmenbedingungen werden in eine konkrete Bewertungsfrage übersetzt.

2. Schritt 2: Architekturen gegenüberstellen

   EBSI-Registries und Trust Chains werden den swiyu-Komponenten Base Registry, Trust Registry, Generic Issuer, Generic Verifier und Wallet gegenübergestellt. Zentralität, Governance und Betriebsverantwortung werden sichtbar.

3. Schritt 3: Profile und Credential-Formate vergleichen

   W3C-VCDM-basierte EBSI-Profile und SD-JWT-VC-basierte Swiss Profiles werden nach Claim-Struktur, selektiver Offenlegung, Metadaten, Status und Darstellung verglichen.

4. Schritt 4: DID- und Schlüsselmodelle bewerten

   did:ebsi, walletbezogene Identifikatoren und did:tdw beziehungsweise did:webvh werden hinsichtlich Auflösung, Hosting, Rotation, Datenschutz und Schlüsselbetrieb eingeordnet.

5. Schritt 5: Interoperabilitätsoptionen auswählen

   Native Verarbeitung, Profilübersetzung, Verifier-Adapter, parallele Credentials, Neu-Ausstellung und zeitlich begrenzte Koexistenz werden nach Nutzen, Risiko und Wartungsaufwand bewertet.

6. Schritt 6: Migrationspfad priorisieren

   Inventar, Pilot, Testmatrix, Dualbetrieb, Cutover, Rückfall und Abschaltung werden als grobe Roadmap mit Entscheidungen, Verantwortlichen und Abhängigkeiten festgehalten.

Praxisübungen

• Entscheidungsmatrix für EBSI, swiyu und Dual-Stack ausfüllen
• Hauptrisiken und offene Architekturentscheidungen eines Beispielvorhabens priorisieren
• Eine 90-Tage-Roadmap für Analyse und Pilot formulieren

Methodik

Kompakter Fachvortrag, Vergleichsmatrizen, moderierte Entscheidungsarbeit und Roadmap-Workshop. Ein Tag ist angemessen, weil das Briefing bewusst keine Implementierung vermittelt, sondern Architektur- und Migrationsentscheidungen für nachfolgende Vertiefungen vorbereitet.