Seminar EUDI-Wallet Produktlabor – Referenzimplementierung und Launchpad

Das viertägige Labor baut eine EUDI-nahe Referenzstrecke aus Issuer, Wallet, Verifier, Vertrauensinformationen und mehreren Credential-Formaten auf. Referenzimplementierung, OpenID-basierte Flows, SD-JWT VC, mobile Dokumentprofile, Interoperabilität und Produktisierungsgrenzen werden praktisch geprüft.

Inhaltsübersicht

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

Zielsetzung

Ziel ist eine reproduzierbare und sicher bewertete Ende-zu-Ende-Implementierung für EUDI-Wallet-Anwendungsfälle. Die Laborakte dokumentiert Rollen, Komponenten, Credential-Profile, Trust, Issuance, Presentation, Konformität, Negativtests und die Lücke zwischen Referenzcode und produktionsfähigem Betrieb.

Zielgruppe

Softwarearchitektur, Entwicklung, Plattformbetrieb, IAM, PKI, Informationssicherheit, technische Produktverantwortung sowie Projektleitungen für digitale Identitäten, Wallets und verifizierbare Nachweise. Zusätzlich geeignet für Architektur- und Sicherheitsverantwortliche in Wallet-, PID-, EAA- und Verifier-Projekten.

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 mobilen Anwendungen oder Wallet-Backends ist hilfreich.

Laborumgebung

1. Isolierte Laborinstanz für EUDI-Wallet Referenzimplementierung 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. Mobile Testumgebung oder Emulator, Referenz-Issuer und Referenz-Verifier sowie eine zweite Implementierung für Interoperabilitätstests.
6. Testprofile für SD-JWT VC und mobile Dokumente einschließlich Trust- und Statusdaten.

Seminarinhalte

Modul 1: Rollen, Anwendungsfälle und Architekturrahmen

PID, elektronische Attributsbescheinigungen, qualifizierte Nachweise, Wallet-Anbieter, Aussteller, Prüfstelle und Vertrauensdienste werden fachlich und technisch abgegrenzt. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Anwendungsfall in Identifizierung, Attributnachweis, Berechtigung und Signaturbedarf zerlegen.
2. Schritt 2: Rollen und Verantwortlichkeiten für Wallet, Aussteller, Prüfstelle, Register und Vertrauensdienste zuordnen.
3. Schritt 3: Remote-, gerätenahe und gegebenenfalls beaufsichtigte Abläufe voneinander trennen.
4. Schritt 4: Datenflüsse, Vertrauensgrenzen und personenbezogene Metadaten erfassen.
5. Schritt 5: Nicht benötigte Funktionen aus dem Laborumfang begründet ausschließen.

Kontrollpunkt: Der Laborumfang besitzt einen eindeutigen Rechts-, Rollen- und Datenflussbezug.

Modul 2: Referenzimplementierung und Komponentenmodell

Die Referenzimplementierung wird in Holder-, Issuer-, Verifier- und gemeinsame Infrastrukturbausteine zerlegt. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Repositories, Build-Artefakte, Dienste und Konfigurationsbereiche inventarisieren.
2. Schritt 2: Komponenten nach Rolle, Laufzeit, Schlüsselzugriff und Datenhaltung klassifizieren.
3. Schritt 3: Schnittstellen und Metadaten zwischen Wallet, Issuer und Verifier dokumentieren.
4. Schritt 4: Abhängigkeiten zu Trust-, Status- und Registrierungsdiensten erfassen.
5. Schritt 5: Zielarchitektur mit lokalen, gehosteten und mobilen Komponenten erstellen.

Kontrollpunkt: Jede Komponente besitzt eine dokumentierte Rolle, Schnittstelle und Betriebsverantwortung.

Modul 3: Laboraufbau, Build und Baseline

Die ausgewählten Referenzkomponenten werden reproduzierbar gebaut, konfiguriert und als gesicherte Ausgangslage betrieben. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Entwicklungswerkzeuge, Container, mobile Testumgebung und Zertifikate vorbereiten.
2. Schritt 2: Quellstände und Abhängigkeiten auf einen dokumentierten Laborstand festlegen.
3. Schritt 3: Issuer-, Verifier- und erforderliche Backend-Dienste starten.
4. Schritt 4: Wallet-Anwendung beziehungsweise Emulator konfigurieren und mit Testschlüsseln initialisieren.
5. Schritt 5: Health-Checks, Metadatenzugriffe und Basisdialoge prüfen und die Baseline sichern.

Kontrollpunkt: Der gesamte Laborstand kann aus dokumentierten Quellen ohne manuelle Einzelkorrekturen neu aufgebaut werden.

Modul 4: Wallet-Instanz, Geräteschutz und Schlüssel

Wallet-Schlüssel, Gerätebindung, lokale Datenspeicherung und Wiederherstellung werden als zusammenhängendes Sicherheitsmodell untersucht. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Wallet-Instanz und Testprofil mit getrennten Geräte- und Anwendungsschlüsseln einrichten.
2. Schritt 2: Schlüsselablage, Entsperrung und zulässige kryptografische Operationen dokumentieren.
3. Schritt 3: Gerätewechsel, Verlust, Wiederherstellung und Löschung als Laborfälle modellieren.
4. Schritt 4: Nicht autorisierte Schlüsselverwendung und manipulierte Wallet-Metadaten testen.
5. Schritt 5: Grenzen zwischen Referenzimplementierung, Plattformschutz und produktionsreifer Absicherung festhalten.

Kontrollpunkt: Die Laborakte unterscheidet klar zwischen Demonstrationsschlüsseln und erforderlichem Produktionsschutz.

Modul 5: PID-, EAA- und QEAA-nahe Credential-Profile

Unterschiedliche Nachweisarten werden mit minimalen Claims, Vertrauensniveaus, Gültigkeiten und Ausstelleranforderungen profiliert. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Identitätsdaten und zusätzliche Attribute fachlich getrennt modellieren.
2. Schritt 2: Für jeden Nachweistyp Pflichtclaims, optionale Claims und Offenlegungsregeln definieren.
3. Schritt 3: Ausstellerklasse, Vertrauensquelle, Gültigkeitsdauer und Statusanforderung festlegen.
4. Schritt 4: Darstellungs- und Sprachinformationen für die Wallet ergänzen.
5. Schritt 5: Gültige, überbreite, widersprüchliche und unvollständige Testprofile erzeugen.

Kontrollpunkt: Jeder Nachweistyp besitzt eine eigene Semantik, Vertrauensregel und Datenminimierung.

Modul 6: OpenID-basierte Credential-Ausgabe

Issuer-Metadaten, Autorisierung, Credential-Angebot, Proof und Tokenverarbeitung werden als vollständige Ausgabestrecke aufgebaut. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Issuer- und Authorization-Metadaten mit unterstützten Credential-Konfigurationen bereitstellen.
2. Schritt 2: Pre-authorized beziehungsweise autorisierten Laborfluss passend zum Testfall auswählen.
3. Schritt 3: Credential-Angebot erzeugen und durch die Wallet einlesen.
4. Schritt 4: Proof, Access Token, Nonce, Bindung und Credential-Antwort analysieren.
5. Schritt 5: Abgelaufene, doppelte, falsch gebundene und manipulierte Anfragen testen.

Kontrollpunkt: Ausgabe erfolgt nur bei gültiger Autorisierung, Wallet-Bindung und profilkonformer Konfiguration.

Modul 7: Wallet-Anzeige, Einwilligung und Datenminimierung

Die Wallet verarbeitet Nachweise so, dass Herkunft, Verwendungszweck, angeforderte Daten und Freigabeentscheidung verständlich bleiben. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Credential mit Aussteller-, Gültigkeits- und Vertrauensinformationen anzeigen.
2. Schritt 2: Mehrere geeignete Nachweise für denselben Prüfzweck verwalten.
3. Schritt 3: Angeforderte und tatsächlich offengelegte Claims gegenüberstellen.
4. Schritt 4: Ablehnung, Teilfreigabe und Abbruch ohne inkonsistenten Sitzungszustand testen.
5. Schritt 5: Barrierefreiheit, Mehrsprachigkeit und verständliche Risikohinweise bewerten.

Kontrollpunkt: Vor jeder Übermittlung sind Empfänger, Zweck und Datenumfang erkennbar.

Modul 8: OpenID-basierte Präsentation und Verification

Presentation Request, Wallet-Auswahl, Response, kryptografische Prüfung und fachliche Policy werden getrennt aufgebaut. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Verifier-Metadaten, Client-Bindung, Nonce und Rückgabekanal konfigurieren.
2. Schritt 2: Minimale Credential- und Claim-Anforderung formulieren.
3. Schritt 3: Präsentation in der Wallet erzeugen und an den Verifier übermitteln.
4. Schritt 4: Signatur, Holder-Bindung, Gültigkeit, Status, Trust und fachliche Regeln prüfen.
5. Schritt 5: Replay, falschen Client, falsche Zielgruppe, abgelaufene Nonce und überbreite Anfrage testen.

Kontrollpunkt: Technische Validität und fachliche Zulässigkeit werden getrennt protokolliert.

Modul 9: SD-JWT VC und selektive Offenlegung

Selektiv offenlegbare Claims, Disclosures, Hash-Bindungen und Holder-Bindung werden praktisch analysiert. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Credential mit offenlegbaren und stets sichtbaren Claims modellieren.
2. Schritt 2: Disclosures erzeugen und die Bindung an das signierte Credential nachvollziehen.
3. Schritt 3: Minimale Auswahl für zwei unterschiedliche Prüfzwecke erstellen.
4. Schritt 4: Nicht passende, fehlende und manipulierte Disclosures testen.
5. Schritt 5: Korrelations- und Metadatenrisiken trotz reduzierter Claim-Offenlegung bewerten.

Kontrollpunkt: Der Verifier kann nur zulässige Disclosures akzeptieren und erhält keine unnötigen Claims.

Modul 10: Mobile Dokumentprofile und gerätenahe Prüfung

Mobile Dokumentprofile werden hinsichtlich Datenmodell, Geräteschlüssel, Session-Bindung und gerätenaher beziehungsweise Remote-Präsentation geprüft. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Namespace, Datenelemente, Aussteller- und Geräteauthentisierung im Testprofil erfassen.
2. Schritt 2: Credential beziehungsweise Dokument in die Wallet übernehmen.
3. Schritt 3: Gerätenahe Session mit kontrolliertem Verbindungsaufbau durchführen.
4. Schritt 4: Issuer- und Device-Authentisierung getrennt prüfen.
5. Schritt 5: Replay, fremdes Gerät, abgelaufene Session und unzulässige Datenelemente testen.

Kontrollpunkt: Geräte- und Ausstellerauthentisierung sind getrennt nachvollziehbar und an die konkrete Sitzung gebunden.

Modul 11: Trust, Registrierungen und Status

Aussteller-, Wallet- und Verifier-Vertrauen wird mit Registrierungs- beziehungsweise Listeninformationen und Credential-Status verbunden. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Vertrauensrollen und erforderliche Registrierungsinformationen je Nachweistyp definieren.
2. Schritt 2: Aussteller- und Verifier-Metadaten in die Prüfung einbeziehen.
3. Schritt 3: Credential-Status, Ablauf und Neuausstellung testen.
4. Schritt 4: Entzug einer Vertrauensrolle und Auswirkungen auf bestehende Credentials prüfen.
5. Schritt 5: Cache, Aktualisierungsintervall und Verhalten bei nicht erreichbarer Vertrauensquelle festlegen.

Kontrollpunkt: Ein positives Ergebnis nennt den verwendeten Trust- und Statusstand mit Prüfzeitpunkt.

Modul 12: Launchpad-, Konformitäts- und Interoperabilitätstests

Referenzkomponenten werden mit einer unabhängigen Implementierung und strukturierten Testfällen auf Protokoll- und Profilkonformität geprüft. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Unterstützte Funktionen, Formate, Algorithmen und Metadaten in einer Capability-Matrix erfassen.
2. Schritt 2: Issuer- und Wallet-Fluss implementierungsübergreifend ausführen.
3. Schritt 3: Wallet- und Verifier-Fluss mit vertauschten Produkten wiederholen.
4. Schritt 4: Fehlercodes, optionale Parameter und Abweichungen gegen erwartete Profile dokumentieren.
5. Schritt 5: Nicht interoperable Varianten begrenzen und als explizite Produktentscheidung festhalten.

Kontrollpunkt: Mindestens zwei vollständige herstellerübergreifende Flüsse und definierte Negativtests sind reproduzierbar.

Modul 13: Sicherheit, Datenschutz und Betriebsgrenzen

Die Referenzimplementierung wird gegen produktionsnahe Anforderungen an Schlüssel, Geräte, Protokollierung, Datenschutz, Update und Incident Response abgegrenzt. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Bedrohungsmodell für Wallet, Issuer, Verifier, Redirects, QR-Codes, Schlüssel und Vertrauensdienste erstellen.
2. Schritt 2: Geheimnisse, Zertifikate, Schlüsselrotation und Administratorzugänge absichern.
3. Schritt 3: Protokollierung auf technische Korrelation begrenzen und Credential-Inhalte aus Logs entfernen.
4. Schritt 4: Update, Rollback, Backup, Wiederherstellung und Abhängigkeitenausfall testen.
5. Schritt 5: Offene Sicherheits- und Produktisierungsanforderungen in einem Risikoregister festhalten.

Kontrollpunkt: Die Pilotfreigabe verwechselt eine funktionierende Referenzstrecke nicht mit einer vollständig gehärteten Produktionslösung.

Modul 14: Integriertes EUDI-Abschlusslabor

PID-naher Nachweis und zusätzlicher Attributnachweis werden in einem vollständigen Issuer-Wallet-Verifier-Szenario verbunden. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Prüfzweck, Rollen, Trust, Nachweistypen und minimale Claims festlegen.
2. Schritt 2: Wallet aus Baseline neu initialisieren und beide Nachweise ausstellen.
3. Schritt 3: Remote-Präsentation mit selektiver Offenlegung durchführen.
4. Schritt 4: Status- beziehungsweise Vertrauensänderung auslösen und erneut prüfen.
5. Schritt 5: Architektur, Testbelege, Interoperabilitätsmatrix, Risiken und Pilotgrenzen in einer Abnahmeakte zusammenführen.

Kontrollpunkt: Die Abnahmeakte enthält den vollständigen positiven Pfad, mindestens zehn Negativtests und dokumentierte Betriebsgrenzen.

Praxisaufgaben

1. EUDI-Rollen- und Komponentenmodell für einen konkreten Anwendungsfall erstellen.
2. Referenzkomponenten reproduzierbar bauen und als Baseline sichern.
3. PID-nahes und zusätzliches Credential-Profil in zwei Formaten konfigurieren.
4. OpenID-basierte Ausgabe und Präsentation mit Wallet-Bindung umsetzen.
5. Selektive Offenlegung und gerätenahe Prüfung technisch analysieren.
6. Trust-, Status-, Replay-, Client- und Metadatenfehler systematisch testen.
7. Zwei herstellerübergreifende Flüsse gegen eine Capability-Matrix prüfen.
8. Produktisierungs-, Datenschutz- und Betriebsanforderungen als Abnahmeakte dokumentieren.

Laborartefakte

• EUDI-Rollen-, Datenfluss- und Komponentenarchitektur.
• Reproduzierbarer Build- und Baseline-Stand der Laborumgebung.
• Credential-Profile für SD-JWT VC und mobile Dokumente.
• Issuance-, Wallet- und Verification-Testautomatisierung.
• Trust-, Status-, Sicherheits- und Negativtestmatrix.
• Interoperabilitäts- und Launchpad-Prüfprotokoll.
• Produktisierungs- und Pilotabnahmeakte.

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.

• Schutzbedarfsanalyse und Datenminimierung für die mit EUDI-Wallet Referenzimplementierung verarbeiteten Claims.
• Trennung von Entwicklungs-, Test- und Produktionskonfiguration einschließlich Geheimnissen und Schlüsseln.
• Nachvollziehbare Prüfung von Signaturen, Statusinformationen, Vertrauensankern und Protokollparametern.
• Messbare Abnahmekriterien für Interoperabilität, Fehlertoleranz, Antwortzeiten und Protokollierung.
• Betriebshandbuch für Sicherung, Wiederherstellung, Schlüsselwechsel, Aktualisierung und Störungsbearbeitung.
• Referenzcode, Testkonfiguration und produktionsnotwendige Sicherheitsmaßnahmen werden ausdrücklich getrennt ausgewiesen.
• Wallet-Nutzerführung wird auf Zwecktransparenz, Datenminimierung, Ablehnung und Barrierefreiheit geprüft.

Praxisnutzen

Das Seminar liefert mehr als eine lauffähige Demo. Es zeigt, welche Teile einer EUDI-Referenzimplementierung unmittelbar nutzbar sind, wo Profile und Trust-Regeln festgelegt werden müssen und welche Sicherheits-, Datenschutz- und Betriebsarbeiten vor einem Pilot- oder Produktionsbetrieb verbleiben.