Seminar Kompaktseminar Europäische DID/VC-Plattformen – Auswahl und Pilotierung

Das dreitägige Kompaktseminar vermittelt einen strukturierten Überblick über europäische DID/VC-, Wallet-, Trust- und Credential-Plattformen. Eine neutrale Laborstrecke, eine gewichtete Bewertungsmatrix und fokussierte Produktstationen führen von den Anforderungen zu einer belastbaren Shortlist und einem begrenzten Pilotdesign.

Inhaltsübersicht

• Zielsetzung
• Zielgruppe
• Voraussetzungen
• Laborumgebung
• Seminarinhalte
• Praxisaufgaben
• Laborartefakte
• Betrieb und Qualitätssicherung
• Praxisnutzen

Zielsetzung

Ziel ist keine oberflächliche Marktübersicht, sondern eine prüfbare Vorauswahl. Am Ende liegen Rollen- und Standardmodell, Vergleichslabor, Produktbewertung, Shortlist, Betriebs- und Exit-Betrachtung sowie eine konkrete Pilot- und Entscheidungsakte vor.

Zielgruppe

IT- und Enterprise-Architektur, Produktmanagement, technische Projektleitung, IAM, Informationssicherheit, Datenschutz, Beschaffung sowie Fachverantwortliche, die innerhalb kurzer Zeit eine DID/VC-Plattformauswahl vorbereiten müssen.

Voraussetzungen

Grundkenntnisse digitaler Identitäten, Webanwendungen und API-Integration sind erforderlich. Tiefe Programmierkenntnisse werden nicht vorausgesetzt; technische Laborübungen werden mit vorbereiteten Konfigurationen und Testwerkzeugen durchgeführt.

Laborumgebung

1. Isolierte Laborinstanz für europäische DID/VC-Plattformen mit getrennten Rollen für Aussteller, Wallet beziehungsweise Holder und Prüfstelle.
2. Arbeitsplatz mit aktuellem Browser, Kommandozeile, Git, Container-Laufzeit und Werkzeugen für HTTP-, JSON- und Token-Analyse.
3. Lokale Test-PKI beziehungsweise verwaltete Schlüsselablage, Testidentitäten sowie synthetische Credential-Daten ohne Produktivdaten.
4. Protokollierungs- und Testumgebung für erfolgreiche Abläufe, Fehlerszenarien, Wiederholungen und Audit-Nachweise.
5. Zwei repräsentative Produktstapel sowie vorbereitete Testzugänge für weitere Produktstationen.
6. Gewichtete Bewertungsmatrix, standardisiertes Test-Credential und identische Positiv- sowie Negativtestfälle.

Seminarinhalte

Modul 1: Marktbild und Einsatzklassen

Europäische DID/VC-Plattformen werden nach Wallet, Issuer, Verifier, Trust, Organisation Wallet, Datenschutz und Integrationsschwerpunkt geordnet. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Anwendungsfälle aus Identifizierung, Berechtigung, Nachweis, Vertretung und Produktdaten unterscheiden.
2. Schritt 2: Plattformen nach vollständigem Stack, Spezialkomponente, öffentlicher Infrastruktur und Integrationsschicht gruppieren.
3. Schritt 3: Pflicht- und Kann-Funktionen für den eigenen Pilotumfang festlegen.
4. Schritt 4: Cloud-, On-Premises-, Open-Source- und verwaltete Betriebsmodelle vergleichen.
5. Schritt 5: Erste Ausschlusskriterien für Datenschutz, Trust, Format und Betrieb definieren.

Kontrollpunkt: Die Vorauswahl basiert auf Einsatzklasse und Muss-Kriterien, nicht auf Funktionslisten allein.

Modul 2: Rollen, Standards und Vertrauensmodell

Issuer, Holder beziehungsweise Wallet, Verifier, Registry und Governance werden mit den zentralen Protokoll- und Formatentscheidungen verbunden. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Rollen und Verantwortlichkeiten für einen Referenzanwendungsfall festlegen.
2. Schritt 2: OpenID-basierte Ausgabe und Präsentation im Sequenzdiagramm abbilden.
3. Schritt 3: SD-JWT VC, mobile Dokumente und klassische VC-Profile nach Einsatzgebiet vergleichen.
4. Schritt 4: DID-, Register- und Trusted-List-Ansätze voneinander abgrenzen.
5. Schritt 5: Credential-Gültigkeit, Ausstellervertrauen und fachliche Policy getrennt modellieren.

Kontrollpunkt: Technische Signaturgültigkeit wird nicht mit organisatorischem Vertrauen gleichgesetzt.

Modul 3: Bewertungsmatrix und Auswahlkriterien

Eine gewichtete Bewertungsmatrix verbindet Architektur, Interoperabilität, Sicherheit, Datenschutz, Betrieb, Lizenzierung und Exit-Fähigkeit. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Muss-, Soll- und Kann-Kriterien mit messbaren Nachweisen formulieren.
2. Schritt 2: Gewichte für Fachlichkeit, Technik, Betrieb und Governance festlegen.
3. Schritt 3: Bewertungsskala und Mindestschwellen definieren.
4. Schritt 4: Nachweisanforderungen für Produktangaben, Labortests und Referenzimplementierungen festlegen.
5. Schritt 5: Ausschluss- und Eskalationsregeln für nicht erfüllte Muss-Kriterien dokumentieren.

Kontrollpunkt: Jede Punktzahl verweist auf einen prüfbaren Befund oder eine klar gekennzeichnete Annahme.

Modul 4: Repräsentative Laborumgebung

Eine neutrale Ende-zu-Ende-Umgebung mit austauschbarem Issuer, Wallet und Verifier wird als Vergleichsbasis aufgebaut. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Testdaten, Credential-Profil und Vertrauensregeln festlegen.
2. Schritt 2: Issuer-, Wallet- und Verifier-Rollen in getrennten Diensten bereitstellen.
3. Schritt 3: Metadaten, Schlüssel, Status und Callback-Endpunkte konfigurieren.
4. Schritt 4: Baseline und automatisierten Gesundheitscheck erstellen.
5. Schritt 5: Schnittstellen so abstrahieren, dass Komponenten ausgetauscht werden können.

Kontrollpunkt: Der Austausch einer Komponente erfordert keine Änderung des fachlichen Credential-Profils.

Modul 5: Credential-Ausgabe im Vergleich

Ausgabeangebote, Autorisierung, Proof, Token und Credential-Antwort werden mit zwei Plattformansätzen umgesetzt und verglichen. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Credential-Konfiguration und minimale Claims erstellen.
2. Schritt 2: Ausgabeangebot in Plattform A konfigurieren.
3. Schritt 3: Denselben fachlichen Fall in Plattform B abbilden.
4. Schritt 4: Wallet-Übernahme, Fehlercodes und Protokollmetadaten vergleichen.
5. Schritt 5: Abhängigkeiten von proprietären APIs und portablen Standards kennzeichnen.

Kontrollpunkt: Beide Produkte werden mit demselben fachlichen Testfall und denselben Abnahmekriterien bewertet.

Modul 6: Wallet, Nutzerführung und Datenschutz

Wallets werden auf Schlüsselmodell, Credential-Anzeige, Einwilligung, selektive Offenlegung, Wiederherstellung und Korrelationsrisiken geprüft. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Credential in zwei Wallet-Ansätzen übernehmen.
2. Schritt 2: Aussteller-, Gültigkeits-, Status- und Zweckinformationen vergleichen.
3. Schritt 3: Minimale und überbreite Datenanforderung gegenüberstellen.
4. Schritt 4: Ablehnung, Abbruch, Gerätewechsel und Wiederherstellung testen.
5. Schritt 5: Datenschutz- und Nutzerführungsbefunde in der Bewertungsmatrix dokumentieren.

Kontrollpunkt: Wallet-Bewertung umfasst Sicherheit und verständliche Entscheidungsfähigkeit, nicht nur Protokollunterstützung.

Modul 7: Verification, Policy und Fachsystemübergabe

Verifier-Produkte werden auf technische Prüfung, fachliche Policy, Ergebnisobjekt und Integration in ein Fachverfahren verglichen. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Präsentationsanforderung mit minimalen Claims erstellen.
2. Schritt 2: Signatur, Holder-Bindung, Status und Trust getrennt prüfen.
3. Schritt 3: Fachliche Policy für Zulassung, Ablehnung und manuelle Nachprüfung definieren.
4. Schritt 4: Ergebnis datensparsam an ein simuliertes Fachsystem übergeben.
5. Schritt 5: Replay, falschen Empfänger, unbekannten Aussteller und Registerausfall testen.

Kontrollpunkt: Das Fachsystem erhält eine erklärbare Entscheidung und keine unnötige Kopie des vollständigen Credentials.

Modul 8: Trust, Status und Register

EUDI-nahe Trust-Modelle, EBSI, swiyu und produktinterne Vertrauenskonfigurationen werden in einer gemeinsamen Vergleichsstruktur geprüft. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Ausstellerrolle, Credential-Typ, Gültigkeit und Status als gemeinsame Kerndaten definieren.
2. Schritt 2: Trust-Information aus mindestens zwei Modellen auflösen.
3. Schritt 3: Credential- und Ausstellerstatus getrennt ändern.
4. Schritt 4: Cache, Aktualisierungsfrist und Ausfallverhalten testen.
5. Schritt 5: Nicht verlustfrei abbildbare Governance-Unterschiede kennzeichnen.

Kontrollpunkt: Kein Trust-Mapping erweitert stillschweigend die fachliche Ausstellerberechtigung.

Modul 9: Produktstationen und Shortlist

Die europäischen Plattformen werden in fokussierten Stationen nach ihren besonderen Stärken, Grenzen und Integrationsmustern bewertet. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Wallet- und Nutzerfokus mit Altme/Talao, Yivi und Validated ID vergleichen.
2. Schritt 2: Enterprise- und Connector-Fokus mit Lissi, esatus SOWL, iGrant.io und Gataca untersuchen.
3. Schritt 3: Vollständige Stacks mit Procivis One, Sphereon und walt.id gegenüberstellen.
4. Schritt 4: Trust-, Infrastruktur- und Lieferkettenfokus mit EBSI, swiyu, Danube Tech und Spherity bewerten.
5. Schritt 5: API-, Wiederverwendungs- und Datenschutzansätze mit BLOOCK, Truvera und Privado ID ergänzen.

Kontrollpunkt: Die Shortlist enthält je Einsatzklasse höchstens drei begründete Kandidaten.

Modul 10: Betriebs-, Kosten- und Exit-Bewertung

Technischer Betrieb, Personalbedarf, Schlüssel, Updates, Mandanten, Support, Lizenzierung und Exit-Artefakte werden vor dem Pilotstart bewertet. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Betriebsverantwortung und notwendige Plattformkompetenzen je Kandidat erfassen.
2. Schritt 2: Schlüssel-, Secret-, Backup-, Monitoring- und Incident-Anforderungen vergleichen.
3. Schritt 3: Lizenz-, Hosting-, Transaktions- und Integrationskosten als Bandbreiten dokumentieren.
4. Schritt 4: Exportierbare Schemas, Schlüssel, Credentials, Testvektoren und Konfigurationen bestimmen.
5. Schritt 5: Lock-in-, Abkündigungs- und Migrationsrisiken in der Bewertungsmatrix ergänzen.

Kontrollpunkt: Ein technisch guter Kandidat wird bei nicht beherrschbarem Betrieb oder fehlendem Exit nicht freigegeben.

Modul 11: Pilotdesign und Entscheidungsakte

Die Ergebnisse werden in einen begrenzten, messbaren Pilot mit klarer Abbruch- und Freigabelogik überführt. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Pilotziel, Nutzergruppe, Nachweistyp, Trust-Domäne und Integrationsgrenzen festlegen.
2. Schritt 2: Erfolgskriterien für Funktion, Interoperabilität, Sicherheit, Datenschutz und Betrieb definieren.
3. Schritt 3: Testfälle, Verantwortlichkeiten, Zeitfenster und Entscheidungszeitpunkte planen.
4. Schritt 4: Abbruchkriterien und Rückbau des Piloten festlegen.
5. Schritt 5: Shortlist, Risiken, offene Fragen und nächste Beschaffungsschritte in einer Entscheidungsakte zusammenführen.

Kontrollpunkt: Der Pilot beantwortet konkrete Auswahlfragen und wird nicht zum unbefristeten Parallelbetrieb.

Praxisaufgaben

1. Muss-, Soll- und Kann-Kriterien für einen konkreten DID/VC-Anwendungsfall formulieren.
2. Neutrale Issuer-Wallet-Verifier-Baseline aufbauen.
3. Zwei Plattformen mit identischem Credential- und Trust-Fall vergleichen.
4. Wallet-Nutzerführung, Verifier-Policy, Status und Registerausfall testen.
5. Alle Plattformfamilien in einer gewichteten Shortlist bewerten.
6. Pilotumfang, Erfolgskriterien, Abbruchlogik, Betrieb und Exit dokumentieren.

Laborartefakte

• Rollen-, Standard- und Trust-Übersicht.
• Gewichtete Produktbewertungsmatrix.
• Neutrale Vergleichs-Laborstrecke.
• Plattform-Shortlist nach Einsatzklassen.
• Betriebs-, Kosten-, Lock-in- und Exit-Bewertung.
• Pilot- und Entscheidungsakte mit messbaren Kriterien.

Betrieb und Qualitätssicherung

Die technische Umsetzung wird nicht auf den erfolgreichen Demonstrationsfall beschränkt. Fehlerbilder, Datenschutz, Schlüsselverwaltung, Protokollierung, Wiederanlauf und nachvollziehbare Abnahmekriterien werden in die Laborarbeit einbezogen.

• Vergleichsbedingungen, Testdaten und Abnahmekriterien bleiben für alle Kandidaten identisch.
• Produktangaben ohne Laborbeleg werden als Annahme und nicht als erfülltes Kriterium bewertet.
• Datenschutz, Trust, Interoperabilität, Betrieb und Exit besitzen eigene Mindestschwellen.
• Der Pilot verwendet keine Produktividentitäten oder realen personenbezogenen Nachweise.
• Shortlist und Entscheidung enthalten dokumentierte Unsicherheiten und offene Prüfpunkte.

Praxisnutzen

Das Kompaktseminar eignet sich für frühe Projektphasen, in denen eine belastbare Richtung benötigt wird, ohne bereits ein vollständiges fünftägiges Intensivprogramm durchzuführen. Es reduziert die Kandidatenzahl, macht Annahmen sichtbar und verhindert, dass ein Pilot allein nach einer gelungenen Herstellerdemonstration ausgewählt wird.