Seminar esatus SOWL Produktlabor – EUDI-Wallet für IAM und KYC

Das Labor untersucht esatus SOWL als unternehmensnaher Wallet- und Connector-Ansatz für EUDI, IAM, KYC und digitale Nachweise. Im Mittelpunkt steht eine nachvollziehbare Ende-zu-Ende-Strecke von der Architekturentscheidung über Ausstellung, Wallet-Verarbeitung und Prüfung bis zu Statusverwaltung, Unternehmensintegration und technischem Betrieb.

Inhaltsübersicht

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

Zielsetzung

Ziel ist die eigenständige Bewertung und prototypische Umsetzung eines belastbaren Einsatzszenarios mit esatus SOWL. Nach dem Labor liegen eine dokumentierte Zielarchitektur, ein geprüftes Credential-Profil, wiederholbare Issuance- und Presentation-Flows, eine Abweichungsmatrix sowie ein konkreter Pilot- und Betriebsrahmen vor.

Zielgruppe

Softwarearchitektur, Entwicklung, IAM- und PKI-Fachkräfte, Informationssicherheit, Produktverantwortung, technische Projektleitung sowie Fachbereiche für digitale Identitäten und Nachweise.

Voraussetzungen

Grundkenntnisse zu HTTP, REST, JSON, OAuth 2.0 beziehungsweise OpenID Connect sowie zu Public-Key-Kryptografie. Für die praktischen Übungen werden sichere Bedienung der Kommandozeile und Grundlagen containerisierter Anwendungen vorausgesetzt.

Laborumgebung

1. Isolierte Laborinstanz für esatus SOWL 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.

Seminarinhalte

Modul 1: Rollenmodell und Zielarchitektur

Das Rollenmodell von esatus SOWL wird ausgehend von unternehmensnaher Wallet- und Connector-Ansatz für EUDI, IAM, KYC und digitale Nachweise in fachliche und technische Verantwortungsbereiche zerlegt. Berücksichtigt werden insbesondere Wallet- beziehungsweise Connector-Schicht, Issuer- und Verifier-Anbindung, IAM-Brücke, Mandanten- und Policy-Konfiguration. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Geschäftsfall, Rechtsrollen und technische Akteure voneinander abgrenzen.
2. Schritt 2: Komponenten, Datenflüsse, Vertrauensgrenzen und externe Abhängigkeiten in einem Architekturdiagramm erfassen.
3. Schritt 3: Issuer-, Holder-, Verifier- und gegebenenfalls Registry-Aufgaben den Plattformkomponenten zuordnen.
4. Schritt 4: Personenbezogene Daten, Metadaten, Protokolldaten und kryptografische Schlüssel getrennt klassifizieren.
5. Schritt 5: Architekturentscheidungen, Annahmen und offene Risiken in einem Entscheidungsprotokoll festhalten.

Kontrollpunkt: Alle Rollen besitzen eine eindeutige Verantwortung; kein personenbezogener Datenfluss bleibt ohne Zweck und Schutzmaßnahme.

Modul 2: Laboraufbau und Grundkonfiguration

Die für das Produktlabor erforderlichen Dienste von esatus SOWL werden in einer isolierten Umgebung installiert beziehungsweise als Testmandant eingerichtet. Ziel ist eine kontrollierte Ausgangslage, die jederzeit neu aufgebaut werden kann. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Systemvoraussetzungen, Ports, Zertifikate, DNS-Namen und lokale Namensauflösung prüfen.
2. Schritt 2: Benötigte Dienste, Container oder Projektbereiche anlegen und Versionsstände dokumentieren.
3. Schritt 3: Mandanten, Rollen, API-Zugänge und technische Konten mit minimalen Berechtigungen konfigurieren.
4. Schritt 4: Metadaten, Callback-Adressen und Protokollendpunkte konsistent eintragen.
5. Schritt 5: Health-Checks ausführen und einen unveränderten Ausgangszustand als Baseline sichern.

Kontrollpunkt: Ein vollständiger Neuaufbau liefert dieselben Dienstzustände und dieselben geprüften Endpunkte.

Modul 3: Identitäten, Schlüssel und Vertrauensanker

Die Identitäts- und Schlüsselbasis wird für Unternehmens-, Beschäftigten- und Nutzeridentitäten mit verwalteten Vertrauens- und Schlüsselbeziehungen aufgebaut. Dabei werden Erzeugung, Ablage, Nutzung, Wechsel und Wiederherstellung als zusammenhängender Lebenszyklus behandelt. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Geeignete Identifikatoren und Schlüsseltypen für Aussteller, Wallet und Prüfstelle auswählen.
2. Schritt 2: Schlüssel in getrennten Kontexten erzeugen und Zugriffsrechte nach dem Prinzip der geringsten Berechtigung vergeben.
3. Schritt 3: Öffentliche Schlüssel, Metadaten und erforderliche Vertrauensinformationen veröffentlichen oder registrieren.
4. Schritt 4: Schlüsselwechsel, Verlust, Sperrung und Wiederherstellung als Testfälle vorbereiten.
5. Schritt 5: Manipulierte, abgelaufene und unbekannte Schlüssel gegen die Prüflogik testen.

Kontrollpunkt: Jeder Signatur- und Verifikationsvorgang lässt sich auf einen dokumentierten Schlüssel- und Vertrauenszustand zurückführen.

Modul 4: Credential-Datenmodell und Profilierung

Für die Formate EUDI-nahe Credentials, SD-JWT VC, OIDC-kompatible Identitäts- und Berechtigungsinformationen wird ein fachlich sparsames und technisch interoperables Credential-Profil entworfen. Semantik, Pflichtangaben, optionale Angaben, Darstellung und Prüfbarkeit werden gemeinsam betrachtet. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Geschäftliche Nachweise in minimale, zweckgebundene Claims zerlegen.
2. Schritt 2: Datentypen, Kardinalitäten, Bezeichner, Gültigkeiten und sprachabhängige Anzeigen festlegen.
3. Schritt 3: Das passende Format aus EUDI-nahe Credentials, SD-JWT VC, OIDC-kompatible Identitäts- und Berechtigungsinformationen anhand von Nutzungsszenario, Wallet-Unterstützung und Offenlegungsbedarf auswählen.
4. Schritt 4: Ausstellerbindung, Holder-Bindung, Statusverfahren und Vertrauensanforderungen in einem Profil dokumentieren.
5. Schritt 5: Gültige, unvollständige, widersprüchliche und übermäßig umfangreiche Test-Credentials erzeugen.

Kontrollpunkt: Das Profil ist maschinenlesbar testbar und enthält keine Claims ohne nachgewiesenen Verwendungszweck.

Modul 5: Ausstellung und Credential-Übernahme

Der Ausstellungsprozess wird mit unternehmensbezogenen Issuer-Prozessen und angebundenen Identitätsquellen umgesetzt. Neben dem Normalfall werden Autorisierung, Proof-Bindung, Wiederholung, Abbruch und kontrollierte Fehlerantworten untersucht. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Issuer-Konfiguration, Credential-Angebot und zulässige Konfigurationen festlegen.
2. Schritt 2: Autorisierungs- und Identitätsprüfung für die Testperson beziehungsweise Testorganisation durchführen.
3. Schritt 3: Credential-Angebot erzeugen und die Bindung an Wallet, Schlüssel oder Sitzung prüfen.
4. Schritt 4: Credential ausstellen, kryptografische Nachweise analysieren und die Übernahme quittieren.
5. Schritt 5: Abgebrochene, doppelte, abgelaufene und manipulierte Angebote mit definierten Fehlererwartungen testen.

Kontrollpunkt: Ein Credential wird nur nach erfolgreicher Autorisierung, korrekter Bindung und nachvollziehbarer Protokollierung ausgegeben.

Modul 6: Wallet- und Holder-Prozesse

Die Holder-Seite wird mit Wallet- beziehungsweise Connector-Prozessen für Beschäftigte, Kunden und Organisationen eingerichtet. Im Mittelpunkt stehen kontrollierte Übernahme, verständliche Anzeige, sichere Ablage und datensparsame Auswahl. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Wallet beziehungsweise Holder-Komponente registrieren und Geräte- oder Instanzbindung konfigurieren.
2. Schritt 2: Ausstellerinformationen und Vertrauensstatus vor der Annahme eines Angebots bewerten.
3. Schritt 3: Credential übernehmen, Claims und Gültigkeit anzeigen und kryptografische Metadaten untersuchen.
4. Schritt 4: Mehrere Credentials nach Typ, Aussteller, Zweck und Gültigkeit verwalten.
5. Schritt 5: Sicherungs-, Wiederherstellungs-, Lösch- und Gerätewechselszenarien ohne Produktivdaten erproben.

Kontrollpunkt: Die Wallet zeigt Herkunft, Zweck, Gültigkeit und Offenlegungsumfang nachvollziehbar an.

Modul 7: Präsentation und Verification

Die Prüfstelle wird mit Policy-gesteuerter Credential-Prüfung und Übergabe an IAM- oder KYC-Prozesse aufgebaut. Anfrage, Auswahl, Einwilligung, Präsentation und technische beziehungsweise fachliche Policy-Prüfung werden getrennt nachvollzogen. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Prüfzweck, zulässige Credential-Typen und minimale Claim-Anforderung definieren.
2. Schritt 2: Präsentationsanfrage mit eindeutigem Kontext, Nonce, Zielgruppe und Rückgabeweg erzeugen.
3. Schritt 3: Credential-Auswahl und gegebenenfalls selektive Offenlegung in der Wallet durchführen.
4. Schritt 4: Signatur, Holder-Bindung, Gültigkeit, Status, Ausstellervertrauen und fachliche Regeln prüfen.
5. Schritt 5: Replay, falsche Zielgruppe, unbekannter Aussteller, abgelaufener Nachweis und unzulässige Mehrdaten testen.

Kontrollpunkt: Technische Gültigkeit und fachliche Berechtigung werden als getrennte Prüfergebnisse protokolliert.

Modul 8: Status und Credential-Lebenszyklus

Status- und Änderungsprozesse werden mit organisationsbezogenen Vertrauensregeln, Statuswechseln und rollenabhängiger Neuausstellung umgesetzt. Das Labor umfasst Ausgabe, Nutzung, Erneuerung, Suspendierung, Widerruf, Ablauf und Ersatz. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Statusmechanismus und Aktualisierungsfrequenz für den Geschäftsfall festlegen.
2. Schritt 2: Credential aktivieren, suspendieren beziehungsweise widerrufen und die Zustandsänderung veröffentlichen.
3. Schritt 3: Verifier-Verhalten bei aktuellem, veraltetem, nicht erreichbarem und widersprüchlichem Status prüfen.
4. Schritt 4: Erneuerung, Ersatz und Ablauf mit klaren Beziehungen zum Vorgängernachweis umsetzen.
5. Schritt 5: Audit-Ereignisse erzeugen und Aufbewahrungsfristen ohne unnötige Nutzungsprofile definieren.

Kontrollpunkt: Statusentscheidungen bleiben auch bei Netzstörung, Cache-Nutzung und Schlüsselwechsel nachvollziehbar.

Modul 9: IAM-Brücke und attributbasierter Zugriff

Verifizierte Claims werden in kurzlebige Anmeldesitzungen und fachliche Berechtigungen überführt, ohne das Credential dauerhaft in das Zielsystem zu kopieren. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Anmelde- und Berechtigungsclaims getrennt modellieren.
2. Schritt 2: Credential-Prüfung mit einem simulierten Identity Provider beziehungsweise Access Gateway verbinden.
3. Schritt 3: Claim-Mapping auf Rollen, Gruppen und kontextabhängige Regeln konfigurieren.
4. Schritt 4: Entzug, Rollenwechsel und veraltete Berechtigungsinformationen testen.
5. Schritt 5: Protokollierung so begrenzen, dass keine vollständigen Credentials in IAM-Logs gelangen.

Kontrollpunkt: Anmeldung, Identitätsnachweis und Berechtigungsentscheidung bleiben technisch und fachlich getrennt.

Modul 10: KYC- und Organisationsprozesse

KYC- und organisationsbezogene Nachweise werden als wiederverwendbare, statusfähige Credentials in einen kontrollierten Prüfprozess eingebunden. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: KYC- beziehungsweise Organisationsattribute nach Notwendigkeit und Aktualitätsbedarf klassifizieren.
2. Schritt 2: Ausstellerquellen und zulässige Vertrauensniveaus je Claim festlegen.
3. Schritt 3: Nachweise für natürliche Person, Vertretung und Organisation kombinieren.
4. Schritt 4: Änderung von Vertretungsmacht, Beschäftigung oder Kundenstatus als Lebenszyklusereignis testen.
5. Schritt 5: Manuelle Nachprüfung und Ausnahmebehandlung mit klaren Eskalationskriterien integrieren.

Kontrollpunkt: Vertretung und Organisationszugehörigkeit werden nicht aus statischen Profildaten, sondern aus prüfbaren Nachweisen abgeleitet.

Modul 11: Unternehmensintegration und Automatisierung

Die Plattform wird über IAM-, OIDC-, KYC-, HR- und Fachanwendungsadaptern in ein simuliertes Unternehmenssystem eingebunden. Die Laborstrecke verbindet fachliche Prozesse, technische APIs und betrieblich belastbare Fehlerbehandlung. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: API-Authentisierung, Rollen, Rate Limits und Mandantenzuordnung konfigurieren.
2. Schritt 2: Ein Fachsystem mit anonymisierten Testdaten an Issuer- oder Verifier-Prozesse anbinden.
3. Schritt 3: Callbacks, Events und Statusänderungen idempotent verarbeiten und korrelierbar protokollieren.
4. Schritt 4: Portal-, IAM- oder Workflow-Integration mit klarer Trennung zwischen Identifizierung und Berechtigung umsetzen.
5. Schritt 5: Lastspitzen, Wiederholungen, Zeitüberschreitungen und Teilfehler mit definierten Rückfallverfahren testen.

Kontrollpunkt: Die Integration kann wiederholt ausgeführt werden, ohne doppelte Ausgaben, widersprüchliche Statusstände oder unklare Berechtigungen zu erzeugen.

Modul 12: Interoperabilität und Konformitätsprüfung

Die mit esatus SOWL erzeugten Artefakte werden gegen eine zweite Implementierung beziehungsweise einen unabhängigen Prüfdienst getestet. Abweichungen werden nicht durch manuelle Sonderbehandlung verdeckt, sondern systematisch klassifiziert. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Metadaten, unterstützte Algorithmen, Formate und Protokolloptionen beider Seiten vergleichen.
2. Schritt 2: Credential-Ausstellung und -Übernahme über Implementierungsgrenzen hinweg ausführen.
3. Schritt 3: Präsentation und Verifikation mit wechselnden Rollenbesetzungen wiederholen.
4. Schritt 4: Fehlercodes, optionale Parameter, Zeitangaben, Kodierungen und Redirect-Verhalten protokollieren.
5. Schritt 5: Abweichungsmatrix mit Ursache, Auswirkung, Workaround und erforderlicher Produktentscheidung erstellen.

Kontrollpunkt: Mindestens ein vollständiger herstellerübergreifender Ablauf sowie definierte Negativtests sind reproduzierbar.

Modul 13: Sicherheit, Betrieb und technische Abnahme

Für esatus SOWL wird aus den Laborergebnissen ein belastbares Betriebs- und Abnahmemodell abgeleitet. Schwerpunkt sind Schlüssel, Geheimnisse, Datenschutz, Überwachung, Aktualisierung und Störungsbehandlung. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Bedrohungsmodell für Issuer, Wallet, Verifier, APIs, Administratorzugänge und Vertrauensdienste erstellen.
2. Schritt 2: Schlüssel- und Secret-Verwaltung einschließlich Rotation, Notfallzugriff und Protokollierung prüfen.
3. Schritt 3: Logging so konfigurieren, dass technische Ursachen sichtbar bleiben, ohne vollständige Credential-Inhalte zu speichern.
4. Schritt 4: Sicherung, Wiederherstellung, Update, Rollback und Abhängigkeitenausfall als Betriebsproben durchführen.
5. Schritt 5: Abnahmekatalog mit Funktions-, Sicherheits-, Datenschutz-, Interoperabilitäts- und Betriebsanforderungen abschließen.

Kontrollpunkt: Die Freigabe basiert auf messbaren Kriterien, dokumentierten Restrisiken und einem erprobten Wiederanlaufverfahren.

Modul 14: Integriertes Abschlusslabor

Alle Komponenten von esatus SOWL werden in einem durchgängigen Geschäftsszenario verbunden. Das Abschlusslabor dient als technische Generalprobe für einen begrenzten Pilotbetrieb. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Ein fachliches Szenario mit Aussteller, Holder, Prüfstelle, Vertrauensregel und Statusänderung auswählen.
2. Schritt 2: Umgebung aus der gesicherten Baseline automatisiert neu aufbauen.
3. Schritt 3: Credential ausstellen, übernehmen, präsentieren, prüfen, ändern und erneut prüfen.
4. Schritt 4: Mindestens fünf Negativtests und einen Infrastrukturfehler kontrolliert ausführen.
5. Schritt 5: Architektur, Testnachweise, Betriebscheckliste und offene Entscheidungen in einer Pilotakte zusammenführen.

Kontrollpunkt: Die Pilotakte enthält alle Nachweise, um Umfang, Risiken und nächste technische Schritte sachlich zu entscheiden.

Praxisaufgaben

1. Eine isolierte esatus SOWL-Laborumgebung aus einer dokumentierten Baseline neu aufbauen.
2. Ein minimiertes Credential-Profil mit fachlichen Regeln, Statusverfahren und Vertrauensanforderungen erstellen.
3. Ausstellung, Wallet-Übernahme und Prüfung als automatisierbare Ende-zu-Ende-Strecke umsetzen.
4. Manipulation, Ablauf, unbekannten Aussteller, Replay und nicht erreichbaren Statusdienst kontrolliert testen.
5. Eine reale Unternehmensschnittstelle durch einen Testadapter anbinden und Idempotenz sowie Fehlerbehandlung prüfen.
6. Pilotentscheidung anhand von Architektur, Interoperabilität, Datenschutz, Betrieb und Herstellerabhängigkeit dokumentieren.

Laborartefakte

• Dokumentierte Zielarchitektur und Rollenmatrix für esatus SOWL.
• Bereinigte Labor-Konfigurationen, Testdaten und wiederholbare Startanweisungen.
• Credential-Profil mit Claims, Format, Vertrauensregeln und Statusverfahren.
• Sammlung positiver und negativer Testfälle einschließlich erwarteter Prüfergebnisse.
• Integrations- und Betriebscheckliste für Pilotierung, Abnahme und Übergang in eine verwaltete Umgebung.

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 esatus SOWL 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.

Praxisnutzen

Das Seminar liefert eine belastbare Entscheidungsgrundlage für den Einsatz von esatus SOWL. Statt einer reinen Produktdemonstration entstehen wiederverwendbare Konfigurationen, Testfälle und Betriebsanforderungen. Damit lassen sich PoC, Ausschreibung, Architekturreview und Pilotbetrieb mit nachvollziehbaren Kriterien vorbereiten.