Seminar Intensivseminar Europäische DID/VC-Plattformen – Gesamtprogramm

Das fünftägige Gesamtprogramm verdichtet sämtliche Produkt- und Querschnittslabore zu einer integrierten Vergleichs-, Implementierungs- und Entscheidungsstrecke. Öffentliche Vertrauensinfrastrukturen, vollständige Produktstapel, Wallets, Connectoren, Business-Wallets, Privacy-Ansätze, Interoperabilität und Enterprise-Betrieb werden gemeinsam behandelt.

Inhaltsübersicht

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

Zielsetzung

Ziel ist ein belastbarer Gesamtüberblick mit praktischer Tiefe. Am Ende liegen eine neutrale Referenzarchitektur, Laborbefunde zu allen Plattformfamilien, Cross-Vendor-Tests, Shortlist, Betriebs- und Exit-Modell sowie eine stufenweise Pilot- und Beschaffungsroadmap vor.

Zielgruppe

Enterprise- und Lösungsarchitektur, technische Programm- und Produktleitung, IAM, Informationssicherheit, Plattformbetrieb, Datenschutz, Beschaffung sowie Entscheidungsgremien für umfassende EUDI-, Wallet- und Verifiable-Credential-Programme.

Voraussetzungen

Sichere Kenntnisse zu HTTP, REST, JSON, OAuth 2.0, OpenID Connect und Public-Key-Kryptografie. Grundverständnis von DIDs, Verifiable Credentials und containerisierten Anwendungen wird vorausgesetzt. Praktische Erfahrung mit API-Integration, IAM oder PKI wird vorausgesetzt.

Laborumgebung

1. Isolierte Laborinstanz für europäische DID/VC-Plattformen im Multi-Vendor-Betrieb 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. Mehrere repräsentative Produktstapel, vorbereitete Testmandanten und eine neutrale Integrationsschicht.
6. Testprofile für SD-JWT VC, mobile Dokumente, klassische VC-Profile, Trust-Registries und Zero-Knowledge-Prädikate.

Seminarinhalte

Modul 1: Gesamtlandschaft und Einsatzklassen

Alle behandelten Plattformen werden nach vollständigem Stack, Wallet, Connector, Trust, Register, Business Wallet, Datenschutz und Spezialinfrastruktur geordnet. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: EUDI-Wallet, EBSI und swiyu als öffentliche beziehungsweise staatsnahe Vertrauens- und Referenzräume einordnen.
2. Schritt 2: Procivis One, Sphereon und walt.id als umfassende Produktstapel vergleichen.
3. Schritt 3: Lissi, esatus SOWL, Gataca, Validated ID und iGrant.io nach Integrations- und Enterprise-Fokus gruppieren.
4. Schritt 4: Altme/Talao, Yivi, Truvera, BLOOCK und Privado ID nach Wallet-, Wiederverwendungs-, API- und Privacy-Schwerpunkten bewerten.
5. Schritt 5: Danube Tech und Spherity als Infrastruktur- beziehungsweise Lieferketten-Spezialisten ergänzen.

Kontrollpunkt: Jede Plattform ist einer begründeten Einsatzklasse mit typischen Stärken und Grenzen zugeordnet.

Modul 2: Referenzarchitektur, Rollen und Standards

Ein herstellerneutrales Modell verbindet Issuer, Wallet, Verifier, Trust, Status, Registry und Fachsysteme mit den relevanten Credential- und Protokollprofilen. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Rollen, Datenflüsse und Verantwortlichkeiten für einen Referenzfall definieren.
2. Schritt 2: OpenID-basierte Ausgabe und Präsentation im Sequenzmodell erfassen.
3. Schritt 3: SD-JWT VC, mobile Dokumente und weitere VC-Profile abgrenzen.
4. Schritt 4: DID-, Trusted-List- und Registry-Ansätze in die Vertrauensarchitektur einordnen.
5. Schritt 5: Gemeinsamen minimalen Integrationsvertrag für Produktwechsel festlegen.

Kontrollpunkt: Fachliches Datenmodell und Prozess bleiben von einer einzelnen Produkt-API entkoppelt.

Modul 3: Neutrale Multi-Vendor-Laborbasis

Eine austauschbare Issuer-Wallet-Verifier-Strecke bildet die Vergleichsbasis für alle folgenden Produktstationen. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Test-Credential, Vertrauensregel, Statusverfahren und Negativfälle festlegen.
2. Schritt 2: Issuer-, Wallet-, Verifier- und Trust-Dienste getrennt bereitstellen.
3. Schritt 3: Metadaten, Schlüssel, Callback und Protokollierung konfigurieren.
4. Schritt 4: Automatisierte Baseline- und Gesundheitstests erstellen.
5. Schritt 5: Adaptergrenzen für den Austausch einzelner Komponenten definieren.

Kontrollpunkt: Eine Komponente kann ausgetauscht werden, ohne den fachlichen Referenzfall neu zu entwerfen.

Modul 4: EUDI-Wallet Referenzstrecke

EUDI-nahe Issuance-, Wallet- und Verification-Flows werden mit mehreren Credential-Formaten, Trust und Produktisierungsgrenzen aufgebaut. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: PID-nahes und zusätzliches Attributprofil definieren.
2. Schritt 2: Issuer-Angebot und Wallet-Übernahme über OpenID-basierte Flows durchführen.
3. Schritt 3: SD-JWT-VC-Offenlegung und mobile Dokumentpräsentation vergleichen.
4. Schritt 4: Trust-, Status-, Replay- und Client-Bindungsfehler testen.
5. Schritt 5: Lücke zwischen Referenzcode und produktionsfähiger Absicherung dokumentieren.

Kontrollpunkt: Referenzfunktion und Produktionsanforderung sind in der Abnahmeakte getrennt ausgewiesen.

Modul 5: EBSI, swiyu und Trust-Registries

Europäische und schweizerische Vertrauensregister werden mit Akkreditierung, Organisationsrollen, Registry-Zuständen und Verifier-Policies verbunden. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: EBSI-Akkreditierung und Trusted-Issuer-Prüfung modellieren.
2. Schritt 2: swiyu-Organisations- und Registry-Vertrauen abbilden.
3. Schritt 3: EUDI-nahe Trust-Informationen in ein internes Modell überführen.
4. Schritt 4: Entzug, Registerausfall, Cache und widersprüchliche Quellen testen.
5. Schritt 5: Governance-Grenzen von Cross-Registry-Mappings dokumentieren.

Kontrollpunkt: Kein technisches Mapping erweitert stillschweigend die Ausstellerberechtigung.

Modul 6: DACH-Produktstationen

walt.id, Lissi, esatus SOWL, Spherity und Danube Tech werden anhand ihrer Stack-, Connector-, IAM-, Business-Wallet- und DID-Infrastruktur-Schwerpunkte geprüft. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: walt.id Issuer-, Wallet- und Verifier-APIs als vollständige Strecke testen.
2. Schritt 2: Lissi Connector als Entkopplungsschicht für ein Fachsystem einsetzen.
3. Schritt 3: esatus SOWL mit einem IAM- beziehungsweise KYC-Prozess verbinden.
4. Schritt 4: Spherity Business Wallet und Digital Product Passport in einem B2B-Fall bewerten.
5. Schritt 5: Danube Tech Resolver und Registrar als methodenneutrale Infrastruktur integrieren.

Kontrollpunkt: Für jede Station liegt ein klarer Eignungsbereich und ein technischer Integrationsbefund vor.

Modul 7: Schweizer Produktstationen

Procivis One und swiyu werden hinsichtlich vollständigem Stack, Trust Layer, Credential-Formaten, öffentlicher Infrastruktur und Betriebsmodell verglichen. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Procivis-One-Issuer, Wallet, Verifier und Trust Layer konfigurieren.
2. Schritt 2: Zwei Credential-Formate und mehrere Trust-Policies testen.
3. Schritt 3: swiyu-Registry- und Organisationsvertrauen gegenüberstellen.
4. Schritt 4: Herstellerübergreifenden Issuance- oder Presentation-Flow durchführen.
5. Schritt 5: Open-Source-, Governance- und Betriebsgrenzen dokumentieren.

Kontrollpunkt: Produkt- und Infrastrukturrolle werden nicht miteinander verwechselt.

Modul 8: Benelux-Produktstationen

Sphereon und Yivi werden als modularer EUDI-/Datenaustauschstack beziehungsweise datenschutzorientierte Attribut-Wallet untersucht. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Sphereon IDK, EDK und VDX in einer Komponentenstrecke verbinden.
2. Schritt 2: Policy- und Eventverarbeitung mit einem Fachworkflow testen.
3. Schritt 3: Yivi-Attributausgabe und minimale Offenlegung durchführen.
4. Schritt 4: Korrelationsschutz und EUDI-Koexistenz bewerten.
5. Schritt 5: Einsatzgrenzen zwischen universellem Stack und spezialisiertem Privacy-Modell dokumentieren.

Kontrollpunkt: Datenschutzstärke und Standardanschluss werden getrennt bewertet.

Modul 9: Iberische Produktstationen

Gataca Studio, Validated ID und BLOOCK werden nach Studio-/Vorlagenansatz, modularer Wallet-Kette, API-Integration und Integritätsnachweisen verglichen. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Gataca-Projekt sowie Credential- und Verifikationsvorlage konfigurieren.
2. Schritt 2: Validated-ID-Kette aus VIDcredentials, VIDwallet und VIDconnect testen.
3. Schritt 3: BLOOCK-Credential per API ausstellen und verifizieren.
4. Schritt 4: Optionalen Integritätsnachweis mit Manipulationstest ergänzen.
5. Schritt 5: Vorlagen-, API-, Wallet- und Betriebsbefunde in einer gemeinsamen Matrix bewerten.

Kontrollpunkt: Produktauswahl folgt dem benötigten Betriebs- und Integrationsmodell, nicht nur der UI-Wirkung.

Modul 10: Französische, nordische und britische Produktstationen

Altme/Talao, iGrant.io und Truvera werden nach mobiler Wallet, Organisation Wallet, B2B-Datenaustausch und wiederverwendbaren Identitäten untersucht. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Altme/Talao-Wallet-Profil und selektive Offenlegung konfigurieren.
2. Schritt 2: iGrant.io Organisation Wallet mit Delegations- und B2B-Regeln testen.
3. Schritt 3: Truvera-Credential in mehreren Prüfdiensten wiederverwenden.
4. Schritt 4: Governance, Rollenwechsel und Zweckbindung vergleichen.
5. Schritt 5: Integrations-, Datenschutz- und Exit-Artefakte dokumentieren.

Kontrollpunkt: Wiederverwendung erfolgt nur mit eigenem Zweck- und Trust-Profil je Prüfdienst.

Modul 11: Zero-Knowledge- und Privacy-Station

Privado ID und ergänzende selektive Offenlegungsansätze werden auf Prädikate, Proof-Zustände, Datenminimierung und Betriebsabhängigkeiten geprüft. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Credential und Zero-Knowledge-Prädikat definieren.
2. Schritt 2: Proof in der Wallet erzeugen und ohne Ausgangswert verifizieren.
3. Schritt 3: State-, Status- und Synchronisationsabhängigkeiten testen.
4. Schritt 4: SD-JWT-VC- und attributbasierte Offenlegung gegenüberstellen.
5. Schritt 5: Geeignete und ungeeignete Einsatzfälle dokumentieren.

Kontrollpunkt: Privacy-Technik wird nur eingesetzt, wenn Proof-Semantik und Betriebsabhängigkeiten verstanden sind.

Modul 12: Herstellerübergreifende Interoperabilität

Ausgewählte Komponenten werden über OpenID-basierte Flows, SD-JWT VC und mobile Dokumentprofile in einer Cross-Matrix kombiniert. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Capability-Matrix für vier ausgewählte Produkte erstellen.
2. Schritt 2: Mindestens zwei Cross-Vendor-Issuance-Flows durchführen.
3. Schritt 3: Mindestens vier Wallet-/Verifier-Kombinationen prüfen.
4. Schritt 4: Metadaten-, Status-, Trust-, Replay- und Redirect-Fehler testen.
5. Schritt 5: Freigegebenes Minimalprofil und Abweichungsregister abschließen.

Kontrollpunkt: Interoperabilität ist durch konkrete Kombinationen und reproduzierbare Tests belegt.

Modul 13: Enterprise-Integration und Betrieb

Fachsysteme, IAM, Events, Mandanten, Schlüssel, Monitoring, Backup und Incident Response werden produktübergreifend bewertet. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Neutralen Issuer- und Verifier-Adapter an ein Testfachsystem anbinden.
2. Schritt 2: Anmeldung, Identitätsnachweis und Berechtigung getrennt in IAM abbilden.
3. Schritt 3: Asynchrone Events, Idempotenz und Teilfehler testen.
4. Schritt 4: Betriebs- und Sicherheitsanforderungen je Produktklasse vergleichen.
5. Schritt 5: Exit-Artefakte, Update- und Migrationsverfahren festlegen.

Kontrollpunkt: Eine Pilotintegration kann ohne proprietäre Datenkopien und unkontrollierte Prozesszustände betrieben werden.

Modul 14: Auswahl, Beschaffung und Roadmap

Alle Befunde werden in eine gewichtete Shortlist, eine Beschaffungsstrategie und eine stufenweise Architekturroadmap überführt. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Muss-, Soll- und Kann-Kriterien anhand der Laborbelege bewerten.
2. Schritt 2: Kandidaten je Einsatzklasse priorisieren und Ausschlussgründe dokumentieren.
3. Schritt 3: Lizenz, Betrieb, Support, Integrationsaufwand und Exit als Gesamtkostenrahmen erfassen.
4. Schritt 4: Pilot-, Koexistenz-, Migration- und Rückbaupfad planen.
5. Schritt 5: Entscheidungsakte mit Risiken, Unsicherheiten und nächsten Freigabepunkten abschließen.

Kontrollpunkt: Die Roadmap besitzt messbare Freigabe- und Abbruchkriterien.

Modul 15: Integriertes Gesamtabschlusslabor

Eine repräsentative Plattformkombination wird von Trust und Issuing bis zu Wallet, Verification, Fachsystem, Statusänderung und Betrieb vollständig durchgespielt. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Zielarchitektur und Produktkombination aus der Shortlist auswählen.
2. Schritt 2: Umgebung automatisiert aus der Baseline neu aufbauen.
3. Schritt 3: Credential ausstellen, übernehmen, selektiv präsentieren und fachlich prüfen.
4. Schritt 4: Trust-, Status-, Infrastruktur- und Integrationsfehler kontrolliert ausführen.
5. Schritt 5: Testbelege, Produktmatrix, Betriebsmodell und Roadmap in einer Gesamtakte zusammenführen.

Kontrollpunkt: Die Gesamtakte belegt Funktion, Interoperabilität, Sicherheit, Datenschutz, Betrieb und Exit der gewählten Pilotkombination.

Praxisaufgaben

1. Gesamte Plattformlandschaft nach Einsatzklassen und Muss-Kriterien strukturieren.
2. Neutrale Multi-Vendor-Laborbasis und gemeinsame Credential-Profile aufbauen.
3. EUDI-, EBSI- und swiyu-nahe Trust- und Credential-Strecken testen.
4. Produktstationen aus DACH, Schweiz, Benelux, Iberien, Frankreich, Norden und Großbritannien durchführen.
5. Zero-Knowledge-, selektive Offenlegungs- und Business-Wallet-Fälle vergleichen.
6. Cross-Vendor-Interoperabilität mit mehreren Produktkombinationen belegen.
7. Enterprise-Integration, Betrieb, Sicherheit, Datenschutz und Exit bewerten.
8. Shortlist, Pilotkombination, Beschaffungsstrategie und Roadmap in einer Gesamtakte abschließen.

Laborartefakte

• Gesamtlandkarte europäischer DID/VC-Plattformen.
• Herstellerneutrale Referenzarchitektur und Integrationsverträge.
• Multi-Vendor-Laborbaseline und Test-Credentials.
• Produktstations- und Interoperabilitätsbefunde.
• Trust-, Status-, Sicherheits- und Datenschutzmatrix.
• Shortlist, Gesamtkosten-, Betriebs- und Exit-Bewertung.
• Pilot-, Beschaffungs- und Architekturroadmap.

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.

• Alle Produktstationen verwenden denselben fachlichen Referenzfall und vergleichbare Testkriterien.
• Nicht praktisch geprüfte Aussagen werden als Annahme gekennzeichnet.
• Trust, Format, Protokoll, fachliche Policy und Betrieb werden getrennt bewertet.
• Interoperabilität wird nur für tatsächlich getestete Produkt- und Profilkombinationen freigegeben.
• Pilot- und Beschaffungsentscheidung berücksichtigt Sicherheits-, Datenschutz-, Betriebs- und Exit-Mindestschwellen.
• Laborartefakte enthalten keine Produktivdaten oder realen Identitätsnachweise.

Praxisnutzen

Das Gesamtprogramm eignet sich für Vorhaben, die in kurzer Zeit eine breite, aber praktisch belastbare Entscheidungsbasis benötigen. Alle spezialisierten Seminarthemen werden in einem gemeinsamen Modell zusammengeführt; dadurch werden Produktstärken, Integrationsgrenzen und Wechselwirkungen sichtbar, ohne jedes Einzelprodukt in maximaler Tiefe behandeln zu müssen.