Seminar Intensivseminar EUDI, EBSI und Vertrauensinfrastrukturen

Das fünftägige Intensivseminar verbindet EUDI-Wallet-Referenzstrecken, EBSI-Akkreditierung, swiyu-Registry-Strukturen und ein herstellerneutrales Trust-Gateway. Credential-Formate, Wallet-Flows, Ausstellervertrauen, Entzug, Interoperabilität, Governance, Sicherheit und Betrieb werden als grenzüberschreitendes Gesamtsystem behandelt.

Inhaltsübersicht

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

Zielsetzung

Ziel ist eine belastbare Architektur- und Laborgrundlage für Wallet-Projekte mit mehreren Vertrauensräumen. Am Ende liegen EUDI-nahe Credential-Flows, EBSI- und swiyu-Trust-Pfade, Cross-Vendor-Tests, ein neutrales Trust-Modell sowie eine vollständige Governance-, Sicherheits- und Betriebsakte vor.

Zielgruppe

Architektur, Entwicklung, Wallet- und Trust-Plattformteams, IAM, PKI, Informationssicherheit, Registry- und Governance-Verantwortliche sowie technische Programmleitungen grenzüberschreitender EUDI-, EBSI- und Digitalnachweis-Vorhaben.

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. Erfahrung mit Credential-Ausgabe oder -Verifikation sowie Grundkenntnisse von Trust- und Registry-Modellen sind erforderlich.

Laborumgebung

1. Isolierte Laborinstanz für EUDI-, EBSI- und swiyu-Vertrauensinfrastrukturen 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. EUDI-nahe Referenzkomponenten, EBSI- und swiyu-Testzugänge sowie zwei Wallet-/Verifier-Implementierungen.
6. Neutrales Trust-Gateway mit Quelladaptern, Cache, Policy Engine und kontrollierbarer Ereignisverarbeitung.

Seminarinhalte

Modul 1: Gesamtarchitektur für EUDI, EBSI und swiyu

Wallet-, Issuer-, Verifier-, Registry-, Akkreditierungs- und Governance-Rollen werden in ein gemeinsames, aber nicht vereinheitlichendes Architekturmodell eingeordnet. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Anwendungsfall und beteiligte Rechtsräume festlegen.
2. Schritt 2: PID-, Attribut-, Organisations- und sektorspezifische Nachweise voneinander abgrenzen.
3. Schritt 3: EUDI-, EBSI- und swiyu-Rollen mit Verantwortlichkeiten zuordnen.
4. Schritt 4: Gemeinsame und systemspezifische Trust- und Registerpfade modellieren.
5. Schritt 5: Governance-Entscheidungen markieren, die nicht technisch substituiert werden können.

Kontrollpunkt: Das Gesamtmodell zeigt Gemeinsamkeiten und Unterschiede, ohne Rechts- oder Vertrauensrollen gleichzusetzen.

Modul 2: Referenzumgebung und sichere Baseline

Eine mehrteilige Testumgebung für Wallet, Issuer, Verifier und drei Trust-Modelle wird reproduzierbar aufgebaut. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Netzsegmente, Zertifikate, Schlüsselablagen und technische Konten vorbereiten.
2. Schritt 2: EUDI-nahe Referenzkomponenten sowie EBSI- und swiyu-Testzugänge einrichten.
3. Schritt 3: Trust-Resolver, Cache und Policy Engine als neutrale Schicht bereitstellen.
4. Schritt 4: Test-Wallets und Verifier mit getrennten Mandanten konfigurieren.
5. Schritt 5: Health-Checks, Baseline und Wiederaufbau automatisieren.

Kontrollpunkt: Alle Komponenten können aus dokumentierter Baseline ohne manuelle Sonderkorrekturen neu bereitgestellt werden.

Modul 3: EUDI-Credential- und Wallet-Profile

PID-nahe und zusätzliche Attributnachweise werden mit Format-, Trust-, Status- und Offenlegungsanforderungen profiliert. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Minimalen Claim-Satz und fachliche Semantik definieren.
2. Schritt 2: SD-JWT-VC- und mobiles Dokumentprofil für denselben Geschäftsfall vergleichen.
3. Schritt 3: Ausstellerklasse, Trust-Quelle, Gültigkeit und Statusregeln festlegen.
4. Schritt 4: Wallet-Anzeige, Einwilligung und selektive Offenlegung konfigurieren.
5. Schritt 5: Überbreite und widersprüchliche Profile als Negativfälle erzeugen.

Kontrollpunkt: Credential-Profil, Format und Vertrauensanforderung sind getrennt dokumentiert.

Modul 4: EUDI-Issuance und Wallet-Bindung

OpenID-basierte Credential-Ausgabe wird mit Autorisierung, Proof, Nonce, Wallet-Schlüssel und kontrollierter Fehlerbehandlung aufgebaut. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Issuer- und Authorization-Metadaten bereitstellen.
2. Schritt 2: Credential-Angebot und geeignete Autorisierungsvariante konfigurieren.
3. Schritt 3: Wallet-Bindung und Proof-Schritt analysieren.
4. Schritt 4: Credential übernehmen und Claims, Signatur und Zeiten prüfen.
5. Schritt 5: Falsche Bindung, Replay, abgelaufene Nonce und doppelten Abruf testen.

Kontrollpunkt: Ausgabe ist an berechtigte Sitzung, Wallet-Schlüssel und Credential-Konfiguration gebunden.

Modul 5: EUDI-Präsentation, SD-JWT VC und mdoc

Remote- und gerätenahe Präsentation werden mit minimalen Datenanforderungen und getrennten kryptografischen Prüfungen umgesetzt. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Verifier-Anfrage mit Empfängerbindung, Nonce und minimalen Claims erzeugen.
2. Schritt 2: SD-JWT-VC-Disclosures für zwei Prüfzwecke erstellen.
3. Schritt 3: Mobiles Dokument in Remote- und gerätenaher Sitzung präsentieren.
4. Schritt 4: Issuer-, Holder- beziehungsweise Device-Bindung und Status getrennt prüfen.
5. Schritt 5: Replay, fremden Empfänger, abgelaufene Sitzung und unzulässige Datenelemente testen.

Kontrollpunkt: Offenlegungs- und Transportvariante ändert nicht unbemerkt das fachliche Prüfergebnis.

Modul 6: EBSI-DID- und Ausstelleridentität

DID-Registry-Informationen, Schlüsselzustände und Organisationsidentitäten werden in die Ausstellerprüfung eingebunden. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Ausstelleridentität und Schlüsselstrategie festlegen.
2. Schritt 2: DID- beziehungsweise Identitätsinformation registrieren und auflösen.
3. Schritt 3: Verification Methods und Service-Metadaten prüfen.
4. Schritt 4: Schlüsselwechsel und aktualisierte Auflösung testen.
5. Schritt 5: Unbekannte, deaktivierte und manipulierte Identitäten ablehnen.

Kontrollpunkt: Die Prüfung verwendet den zum Prüfzeitpunkt gültigen Ausstellerschlüsselzustand.

Modul 7: EBSI-Akkreditierung und Trusted Issuer Registry

Akkreditierung, Delegation und Ausstellerberechtigung werden als mehrstufige Vertrauenskette umgesetzt. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Akkreditierungsrolle und Credential-Typ zuordnen.
2. Schritt 2: Akkreditierung, Zulassung und Registry-Eintrag getrennt konfigurieren.
3. Schritt 3: Berechtigungsumfang und Gültigkeitszeitraum festlegen.
4. Schritt 4: Verifier-Auflösung der gesamten Kette implementieren.
5. Schritt 5: Entzug, Ablauf und fachlich unzuständigen Aussteller testen.

Kontrollpunkt: Technische Signaturgültigkeit genügt ohne passende Ausstellerberechtigung nicht.

Modul 8: swiyu-Organisations- und Registry-Vertrauen

Schweizer Organisationsrollen und Vertrauensinformationen werden in einem eigenständigen Registry-Pfad umgesetzt und mit dem Gesamtmodell verbunden. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Organisation, Ausstellerrolle, Schlüssel und Registry-Eintrag anlegen.
2. Schritt 2: Credential-Typ und zulässigen Vertrauensumfang festlegen.
3. Schritt 3: Trust-Auflösung in den Verifier integrieren.
4. Schritt 4: Rollenänderung, Ablauf und Registry-Ausfall testen.
5. Schritt 5: Grenzüberschreitende Anerkennungs- und Mappingfragen dokumentieren.

Kontrollpunkt: swiyu-Vertrauen bleibt als eigenständige Governance-Quelle erkennbar.

Modul 9: Neutrales Trust-Gateway und Normalisierung

EUDI-nahe Listen, EBSI-Akkreditierung und swiyu-Registry-Daten werden in ein internes Trust-Modell überführt, ohne semantische Verluste zu verbergen. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Gemeinsame Felder für Rolle, Identifikator, Schlüssel, Umfang, Gültigkeit, Status und Quelle definieren.
2. Schritt 2: Quelladapter für drei Trust-Modelle implementieren.
3. Schritt 3: Normalisierung mit Herkunfts- und Prüfzeitstempel versehen.
4. Schritt 4: Nicht abbildbare oder verlustbehaftete Informationen markieren.
5. Schritt 5: Verifier-Policy gegen das neutrale Modell ausführen.

Kontrollpunkt: Jede normalisierte Aussage verweist auf ihre Ursprungsquelle und Mapping-Regel.

Modul 10: Trust-Entzug, Cache und Ausfallverhalten

Änderung und Entzug werden vom Ursprungsregister bis zum geänderten Verifier-Ergebnis verfolgt. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Ausstellerrolle beziehungsweise Akkreditierung entziehen.
2. Schritt 2: Cache-Aktualisierung und Invalidierung auslösen.
3. Schritt 3: Neue, bereits begonnene und wiederholte Prüfsitzungen vergleichen.
4. Schritt 4: Registry-Timeout, stale cache und widersprüchliche Quellen testen.
5. Schritt 5: Risikobasierte Fallback- und Sperrregeln mit maximaler Dauer definieren.

Kontrollpunkt: Trust-Änderungen werden innerhalb einer messbaren Frist wirksam; Ausnahmen sind begründet und zeitlich begrenzt.

Modul 11: Wallet- und Verifier-Interoperabilität

Credential- und Trust-Artefakte werden mit mindestens zwei Wallet- beziehungsweise Verifier-Implementierungen geprüft. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Capability-Matrix für Formate, Algorithmen, Metadaten und Trust-Anbindung erstellen.
2. Schritt 2: EUDI-nahes Credential in einer zweiten Wallet übernehmen.
3. Schritt 3: Präsentation gegen zwei Verifier-Produkte durchführen.
4. Schritt 4: EBSI- und swiyu-Vertrauenspfade in beiden Verifiern vergleichen.
5. Schritt 5: Abweichungen, Workarounds und Profilbegrenzungen dokumentieren.

Kontrollpunkt: Freigegeben werden nur konkret getestete Produkt-, Format- und Trust-Kombinationen.

Modul 12: Konformität, Fehler und Audit-Nachweise

Protokoll-, Format-, Trust- und Governance-Fehler werden systematisch injiziert und in erklärbare Prüfergebnisse überführt. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Katalog für kryptografische, Protokoll-, Status-, Trust- und Policy-Fehler erstellen.
2. Schritt 2: Manipulierte Metadaten, Credentials, Disclosures und Registry-Einträge testen.
3. Schritt 3: Fehlercodes und Audit-Daten implementierungsübergreifend vergleichen.
4. Schritt 4: Technische Ablehnung und manuelle Governance-Prüfung unterscheiden.
5. Schritt 5: Regressionstests und evidenzfähige Prüfprotokolle erstellen.

Kontrollpunkt: Audit-Nachweise belegen Ursache, verwendeten Trust-Stand und fachliche Entscheidung.

Modul 13: Sicherheit, Datenschutz und Governance-Betrieb

Schlüssel, Wallet-Schutz, Registry-Administration, Protokollierung, Rollenfreigaben und Incident Response werden als gemeinsames Betriebsmodell behandelt. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Bedrohungsmodell für Wallet, Issuer, Verifier, Trust-Gateway und Register erstellen.
2. Schritt 2: Schlüsselrotation, Notfallzugriff und Vier-Augen-Verfahren testen.
3. Schritt 3: Logs auf unnötige Claims, dauerhafte Identifikatoren und Korrelationsrisiken prüfen.
4. Schritt 4: Backup, Wiederherstellung, Update, Rollback und Ausfall mehrerer Trust-Dienste erproben.
5. Schritt 5: Technische und Governance-Eskalationen mit Verantwortlichkeiten dokumentieren.

Kontrollpunkt: Sicherheits- und Governance-Prozesse besitzen abgestimmte Freigabe-, Sperr- und Wiederanlaufregeln.

Modul 14: Grenzüberschreitendes Abschlusslabor

Ein vollständiger Fall verbindet EUDI-nahe Wallet-Flows, EBSI-Akkreditierung und swiyu-Vertrauen über das neutrale Trust-Gateway. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Zwei Rechtsräume, Ausstellerrollen und einen gemeinsamen Prüfzweck festlegen.
2. Schritt 2: Credentials über unterschiedliche Trust-Pfade ausstellen und übernehmen.
3. Schritt 3: Beide Nachweise in einer Wallet- beziehungsweise Verifier-Cross-Matrix präsentieren.
4. Schritt 4: Entzug, Statusänderung, Registry-Ausfall und Mapping-Konflikt auslösen.
5. Schritt 5: Architektur, Testbelege, Governance, Risiken und Betriebsgrenzen in einer Gesamtakte abschließen.

Kontrollpunkt: Die Gesamtakte belegt Positivpfade, Negativfälle, Trust-Herkunft, Mapping-Grenzen und Betriebsentscheidungen.

Praxisaufgaben

1. Gemeinsames Rollen-, Architektur- und Governance-Modell für drei Vertrauensräume erstellen.
2. EUDI-nahe Credentials in SD-JWT VC und mobilem Dokumentprofil ausstellen und präsentieren.
3. EBSI-DID-, Akkreditierungs- und Trusted-Issuer-Kette aufbauen.
4. swiyu-Organisations- und Registry-Vertrauen integrieren.
5. Neutrales Trust-Gateway mit Herkunft, Cache und Policy implementieren.
6. Entzug, Registerausfall, Mapping-Konflikt und veralteten Trust-Stand testen.
7. Wallet- und Verifier-Interoperabilität über Produkt- und Trust-Grenzen prüfen.
8. Governance-, Sicherheits-, Audit- und Betriebsakte abschließen.

Laborartefakte

• Gesamtarchitektur für EUDI, EBSI und swiyu.
• EUDI-Credential- und Wallet-Testprofile.
• EBSI-Akkreditierungs- und Trusted-Issuer-Strecke.
• swiyu-Registry- und Organisations-Trust-Strecke.
• Herstellerneutrales Trust-Gateway und Datenmodell.
• Cross-Vendor- und Negativtestautomatisierung.
• Governance-, Sicherheits-, Audit- und Betriebsakte.

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.

• Rechts- und Governance-Rollen werden nicht durch technische Mappings ersetzt.
• Jede Trust-Entscheidung enthält Quelle, Prüfzeitpunkt, Gültigkeit und Berechtigungsumfang.
• Cross-Vendor-Freigaben gelten nur für die konkret getesteten Profile und Versionen.
• Wallet- und Trust-Protokolle speichern keine unnötigen vollständigen Credential-Inhalte.
• Entzug, Cache und Ausfall besitzen messbare Wirksamkeits- und Eskalationsfristen.
• Referenzimplementierung und produktionsnotwendige Härtung werden getrennt ausgewiesen.

Praxisnutzen

Das Intensivseminar eignet sich für Projekte, bei denen Wallet-Funktion allein nicht genügt. Es verbindet die technische Credential-Verarbeitung mit Akkreditierung, Organisationsvertrauen, Registerzuständen, Entzug, grenzüberschreitender Interoperabilität und realistischen Betriebsentscheidungen.