Seminar Intensivseminar Issuer, Wallet, Verifier und Enterprise-Integration

Das fünftägige Intensivseminar baut eine produktübergreifende Enterprise-Plattform für Issuer, Wallet, Verifier, Trust, IAM und Fachsystemintegration auf. Neutrale Adapter, Multi-Mandanten-Betrieb, Organisation Wallets, Events, Observability, Sicherheit, Migration und Beschaffung werden in einer vollständigen Unternehmensstrecke verbunden.

Inhaltsübersicht

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

Zielsetzung

Ziel ist eine produktionsnahe Referenzarchitektur, die einzelne DID/VC-Produkte austauschbar hält und dennoch robuste Geschäftsprozesse ermöglicht. Am Ende liegen Issuer Service, Verifier Gateway, Wallet-Enrollment, Trust-Integration, IAM-Brücke, Betriebsautomatisierung, Exit-Plan und eine technische Abnahmeakte vor.

Zielgruppe

Enterprise- und Lösungsarchitektur, Plattformentwicklung, IAM, API- und Integrationsmanagement, Informationssicherheit, Plattformbetrieb, technische Produktverantwortung sowie Beschaffung und Programmleitung für unternehmensweite Wallet- und Credential-Lösungen.

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 Enterprise-Integration, IAM, Event-Verarbeitung oder Plattformbetrieb wird vorausgesetzt.

Laborumgebung

1. Isolierte Laborinstanz für Issuer-, Wallet-, Verifier- und Enterprise-Integration 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. Mindestens zwei Issuer-/Verifier-Produkte, zwei Wallet-Ansätze, Trust-Gateway, IAM-Testsystem, Event-Bus und simuliertes Fachsystem.
6. Multi-Mandanten-Konfiguration, zentrale Schlüssel- beziehungsweise Secret-Verwaltung sowie Monitoring- und Trace-Werkzeuge.

Seminarinhalte

Modul 1: Enterprise-Zielbild und Plattformrollen

Issuer, Wallet, Verifier, Trust, IAM, Fachsysteme, Integrationsplattform und Betrieb werden als entkoppelte Enterprise-Architektur modelliert. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Geschäftsprozesse nach Identifizierung, Nachweis, Berechtigung und Signaturbedarf zerlegen.
2. Schritt 2: Systemrollen, Datenverantwortung und technische Betreiber zuordnen.
3. Schritt 3: Synchronen und asynchronen Prozessanteil festlegen.
4. Schritt 4: Vertrauens-, Sicherheits- und Datenschutzgrenzen erfassen.
5. Schritt 5: Neutralen Integrationsvertrag zwischen Fachsystem und DID/VC-Plattform definieren.

Kontrollpunkt: Kein Fachsystem muss Credential- oder Wallet-Protokolle direkt implementieren.

Modul 2: Produktauswahl nach Enterprise-Muster

Vollständige Stacks, Connectoren, Organisation Wallets, APIs und Trust-Komponenten werden nach der Zielarchitektur verglichen. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Procivis One, Sphereon und walt.id als vollständige Stacks bewerten.
2. Schritt 2: Lissi, esatus SOWL und Gataca als Integrations- beziehungsweise Orchestrierungsansätze vergleichen.
3. Schritt 3: iGrant.io und Spherity für Organisation- und Business-Wallet-Fälle einordnen.
4. Schritt 4: Validated ID, Altme/Talao, Truvera, BLOOCK, Yivi und Privado ID nach speziellen Wallet-, API- und Privacy-Anforderungen prüfen.
5. Schritt 5: Danube Tech, EBSI und swiyu als Infrastruktur- und Trust-Bausteine ergänzen.

Kontrollpunkt: Die Shortlist folgt dem benötigten Architektur- und Betriebsmodell.

Modul 3: Sichere Multi-Mandanten-Laborbasis

Eine Enterprise-nahe Umgebung mit getrennten Mandanten, Schlüsseln, Rollen, Datenbanken, Netzsegmenten und Testfachsystemen wird aufgebaut. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Entwicklungs-, Abnahme- und Pilotmandanten definieren.
2. Schritt 2: Issuer-, Verifier-, Wallet- und Trust-Dienste getrennt bereitstellen.
3. Schritt 3: Schlüssel, Secrets, API-Clients und Administratorrollen mandantenspezifisch konfigurieren.
4. Schritt 4: Testfachsystem, IAM, Event-Bus und Monitoring anbinden.
5. Schritt 5: Baseline, automatisierten Neuaufbau und Bereinigung der Testdaten erstellen.

Kontrollpunkt: Mandantentrennung ist durch Schlüssel, Daten, Netzwerk und Berechtigungen nachgewiesen.

Modul 4: Issuer Service und Credential Factory

Ein neutraler Issuer Service übersetzt Fachereignisse in profilkonforme Credentials und kapselt Produkt- sowie Formatdetails. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Fachliches Credential-Modell und Versionierungsregeln definieren.
2. Schritt 2: Validierung, Datenminimierung und Freigabe vor der Ausgabe implementieren.
3. Schritt 3: Produktadapter für mindestens zwei Issuer-Plattformen anbinden.
4. Schritt 4: OpenID-basiertes Angebot, Autorisierung und Proof verarbeiten.
5. Schritt 5: Idempotenz, Doppelausgabe, Wiederholung und Teilfehler testen.

Kontrollpunkt: Dasselbe Fachereignis erzeugt unabhängig vom Produkt ein semantisch gleichwertiges Credential.

Modul 5: Identity Proofing und Ausgabeberechtigung

Die Berechtigung zur Credential-Ausgabe wird von der technischen Issuer-Funktion getrennt und mit nachvollziehbaren Nachweisen verbunden. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Identitäts-, Organisations- und Berechtigungsprüfung je Credential-Typ festlegen.
2. Schritt 2: Quellsysteme und Vertrauensniveau der Eingabedaten dokumentieren.
3. Schritt 3: Freigabe, Vier-Augen-Prüfung und Ausnahmeprozess konfigurieren.
4. Schritt 4: Rollenwechsel, unvollständige Daten und widersprüchliche Quellen testen.
5. Schritt 5: Ausgabebeleg mit minimalen Audit-Daten erzeugen.

Kontrollpunkt: Der Issuer stellt nur aus, wenn fachliche Berechtigung und Datenherkunft belegt sind.

Modul 6: Wallet-Integration und Enrollment

Wallets werden über Enrollment, Deep Links, QR-Codes, App-Wechsel, Schlüsselbindung und verständliche Credential-Anzeige in den Enterprise-Prozess eingebunden. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Unterstützte Wallet- und Credential-Profile in einer Capability-Matrix erfassen.
2. Schritt 2: Same-Device- und Cross-Device-Enrollment umsetzen.
3. Schritt 3: Wallet-Bindung, Ausstelleranzeige und Credential-Übernahme prüfen.
4. Schritt 4: Gerätewechsel, Wiederherstellung, Abbruch und nicht unterstützte Wallet testen.
5. Schritt 5: Enterprise-App und Wallet ohne gemeinsame dauerhafte Tracking-Kennung koppeln.

Kontrollpunkt: Wallet-Onboarding bleibt interoperabel, sicher und ohne unnötige Geräte- oder Nutzerkorrelation.

Modul 7: Verifier Gateway und Policy Engine

Ein neutrales Verifier Gateway kapselt Presentation Requests, kryptografische Prüfung, Trust, Status und fachliche Policies. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Prüfzweck und minimale Credential- beziehungsweise Claim-Anforderung definieren.
2. Schritt 2: Produktadapter für mindestens zwei Verifier-Plattformen einbinden.
3. Schritt 3: Technische Validität, Trust, Status und fachliche Policy getrennt auswerten.
4. Schritt 4: Ergebnisobjekt für gültig, ungültig und manuell zu prüfen erstellen.
5. Schritt 5: Replay, falschen Empfänger, unbekannten Aussteller und Registerausfall testen.

Kontrollpunkt: Fachsysteme erhalten erklärbare Prüfergebnisse statt vollständiger Credential-Kopien.

Modul 8: Trust-, Status- und Registry-Integration

EUDI-nahe Listen, EBSI, swiyu und produktinterne Trust-Modelle werden über ein kontrolliertes Gateway in die Enterprise-Policy eingebunden. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Trust-Quellen und Zuständigkeit je Credential-Typ festlegen.
2. Schritt 2: Adapter, Normalisierung und Herkunftsnachweis konfigurieren.
3. Schritt 3: Credential- und Ausstellerstatus getrennt verarbeiten.
4. Schritt 4: Cache, Aktualisierung, Entzug und Ausfall testen.
5. Schritt 5: Cross-Registry-Mappings mit expliziten Governance-Grenzen dokumentieren.

Kontrollpunkt: Ein positives Ergebnis ist auf eine gültige, zuständige und aktuelle Trust-Quelle zurückführbar.

Modul 9: IAM-, OIDC- und Zugriffsentscheidung

Verifizierte Claims werden in Anmeldesitzungen und kontextabhängige Berechtigungen überführt, ohne Nachweise dauerhaft im IAM zu replizieren. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Identitätsnachweis, Authentisierung und Autorisierung getrennt modellieren.
2. Schritt 2: Verifier-Ergebnis auf kurzlebige OIDC-Claims und Rollen abbilden.
3. Schritt 3: Step-up- und risikobasierte Nachweisanforderung konfigurieren.
4. Schritt 4: Rollenwechsel, Credential-Widerruf und Sitzungslaufzeit testen.
5. Schritt 5: IAM-Logs auf Datenminimierung und klare Entscheidungsbelege prüfen.

Kontrollpunkt: Berechtigungen beruhen auf aktuellem Prüfergebnis und nicht auf unkontrollierten Credential-Kopien.

Modul 10: Organisation Wallet, Delegation und B2B

Organisationen, handelnde Personen und technische Dienste werden mit delegierten Rollen und Business-Wallet-Prozessen verbunden. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Organisation, Vertretung, Fachrolle und Maschine getrennt modellieren.
2. Schritt 2: Delegations-, Freigabe- und Zeichnungsregeln definieren.
3. Schritt 3: Organisation-Credential ausstellen und in einer Business Wallet verwalten.
4. Schritt 4: B2B-Präsentation mit Empfängerbindung und Zweckbegrenzung durchführen.
5. Schritt 5: Rollenwechsel, Ausscheiden, Notfallvertretung und Entzug testen.

Kontrollpunkt: Transaktionen im Organisationsnamen besitzen eine prüfbare Delegations- und Freigabekette.

Modul 11: Events, Workflows und robuste Prozesszustände

Asynchrone Issuance- und Verification-Sitzungen werden über Events, Korrelation, Idempotenz und Wiederanlauf in Enterprise-Workflows integriert. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Zustandsautomaten für Angebot, Wallet-Interaktion, Prüfung und Abschluss definieren.
2. Schritt 2: Events und Callbacks mit Korrelationskennung und Signatur absichern.
3. Schritt 3: Doppelte, verspätete und außerhalb der Reihenfolge eintreffende Events testen.
4. Schritt 4: Timeout, Teilfehler und manuelle Wiederaufnahme implementieren.
5. Schritt 5: Endzustände und fachliche Kompensation dokumentieren.

Kontrollpunkt: Jeder Prozess endet eindeutig oder kann kontrolliert wiederaufgenommen beziehungsweise kompensiert werden.

Modul 12: Observability, Datenschutz und Audit

Metriken, Traces, Logs und Audit-Nachweise werden so gestaltet, dass technische Ursachen erkennbar bleiben, ohne vollständige Credentials zu speichern. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Korrelationskennungen ohne dauerhafte globale Nutzerkennung definieren.
2. Schritt 2: Metriken für Erfolg, Fehler, Latenz, Trust- und Statuszugriffe festlegen.
3. Schritt 3: Verteilte Traces über Adapter und Workflows konfigurieren.
4. Schritt 4: Claims, Tokens, Disclosures und personenbezogene Metadaten aus Logs entfernen.
5. Schritt 5: Audit-Belege mit Zweck, Entscheidung, Trust-Stand und minimalen Identifikatoren erzeugen.

Kontrollpunkt: Betriebsanalyse und Audit sind möglich, ohne ein paralleles Identitätsdatenarchiv aufzubauen.

Modul 13: Sicherheit, Schlüssel und Betriebsautomatisierung

Enterprise-Schlüsselverwaltung, Secrets, Härtung, Update, Backup, Wiederherstellung und Incident Response werden produktübergreifend umgesetzt. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Bedrohungsmodell für APIs, Wallet-Links, Redirects, Administratoren und Trust-Dienste erstellen.
2. Schritt 2: HSM- beziehungsweise KMS-Anbindung und Schlüsselrotation im Labor simulieren.
3. Schritt 3: Netzsegmentierung, minimale Rechte und Secret-Rotation konfigurieren.
4. Schritt 4: Update, Rollback, Backup, Wiederherstellung und Abhängigkeitenausfall testen.
5. Schritt 5: Runbooks, Alarmierung und technische Sperrverfahren abschließen.

Kontrollpunkt: Kritische Schlüssel- und Betriebsprozesse sind automatisiert, getestet und nicht an Einzelpersonen gebunden.

Modul 14: Migration, Exit und Beschaffung

Produktwechsel, Koexistenz und Beschaffung werden durch portable Profile, Adapter, Testvektoren und klare Exit-Artefakte vorbereitet. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Portierbare Credential-Schemas, Schlüsselreferenzen, Trust-Regeln und Testdaten bestimmen.
2. Schritt 2: Proprietäre APIs hinter neutralen Adaptern isolieren.
3. Schritt 3: Parallelbetrieb und schrittweise Migration eines Issuer- oder Verifier-Produkts testen.
4. Schritt 4: Lizenz, Hosting, Support, Betrieb und Migrationskosten bewerten.
5. Schritt 5: Muss-Kriterien, Abnahmetests, Datenrückgabe und Exit-Pflichten für Beschaffung formulieren.

Kontrollpunkt: Ein Anbieterwechsel ist technisch geplant und vertraglich durch prüfbare Artefakte abgesichert.

Modul 15: Enterprise-Abschlusslabor

Eine vollständige Unternehmensstrecke verbindet Fachsystem, Issuer Service, Wallet, Verifier Gateway, Trust, IAM, Events und Betrieb. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Pilotfall, Mandanten, Credential-Profil und Trust-Quellen festlegen.
2. Schritt 2: Credential aus einem Fachereignis heraus ausstellen und in eine Wallet übernehmen.
3. Schritt 3: Nachweis präsentieren, über das Verifier Gateway prüfen und in IAM-Berechtigung überführen.
4. Schritt 4: Status-, Trust-, Event-, Infrastruktur- und Schlüsselstörung kontrolliert ausführen.
5. Schritt 5: Architektur, Testbelege, Runbooks, Exit- und Beschaffungsanforderungen in einer Abnahmeakte zusammenführen.

Kontrollpunkt: Die Abnahmeakte belegt die vollständige Enterprise-Strecke einschließlich Fehlerbehandlung, Betrieb und Anbieterwechsel.

Praxisaufgaben

1. Herstellerneutrale Enterprise-Architektur und Integrationsverträge definieren.
2. Sichere Multi-Mandanten-Laborbasis mit mehreren Produkten aufbauen.
3. Neutralen Issuer Service mit zwei Produktadaptern implementieren.
4. Wallet-Enrollment und Verifier Gateway mit Trust- und Statusprüfung umsetzen.
5. Verifier-Ergebnis datensparsam in IAM und Fachverfahren integrieren.
6. Organisation-Wallet-, Delegations- und B2B-Fall testen.
7. Asynchrone Events, Idempotenz, Observability und Wiederanlauf absichern.
8. Schlüssel-, Betriebs-, Migrations-, Exit- und Beschaffungsanforderungen dokumentieren.
9. Enterprise-Abschlusslabor mit Störungen und technischer Abnahme durchführen.

Laborartefakte

• Enterprise-Zielarchitektur und produktneutrale Integrationsverträge.
• Multi-Mandanten-Laborbaseline.
• Issuer Service und Verifier Gateway mit Produktadaptern.
• Wallet-Enrollment-, Trust- und IAM-Integrationsstrecke.
• Event-, Observability-, Sicherheits- und Betriebsrunbooks.
• Organisation-Wallet- und B2B-Testfall.
• Migrations-, Exit-, Beschaffungs- und technische Abnahmeakte.

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.

• Fachsysteme bleiben von Credential-Format und produktspezifischen Protokolldetails entkoppelt.
• Mandantentrennung umfasst Schlüssel, Daten, Netzwerk, Rollen und Protokollierung.
• Logs, Traces und Audit-Belege enthalten keine unnötigen vollständigen Credentials.
• Trust-, Status- und IAM-Entscheidungen besitzen Prüfzeitpunkt und klare Gültigkeitsgrenzen.
• Asynchrone Prozesse sind idempotent und besitzen eindeutige End- sowie Kompensationszustände.
• Exit- und Migrationsfähigkeit werden praktisch getestet und nicht nur vertraglich behauptet.

Praxisnutzen

Das Seminar richtet sich an Vorhaben, die über einen isolierten Wallet-Pilot hinausgehen. Die Produktkomponenten werden in robuste Enterprise-Muster eingebettet, sodass Fachsysteme entkoppelt, Prozesse wiederanlauffähig, Entscheidungen erklärbar und Anbieterwechsel planbar bleiben.