Seminar Sphereon Produktlabor – IDK, EDK und VDX

Das Labor untersucht Sphereon als modularer Entwicklungs- und Austauschstack für digitale Identitäten, EUDI-nahe Credentials und verifizierbare Datentransaktionen. 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 Sphereon. 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 Sphereon 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 Sphereon wird ausgehend von modularer Entwicklungs- und Austauschstack für digitale Identitäten, EUDI-nahe Credentials und verifizierbare Datentransaktionen in fachliche und technische Verantwortungsbereiche zerlegt. Berücksichtigt werden insbesondere IDK, EDK, VDX, Issuer-, Wallet- und Verifier-Bausteine. 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 Sphereon 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 DID- beziehungsweise EUDI-nahe Identitäten, verwaltete Schlüssel und konfigurierbare Trust-Policies 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 SD-JWT VC, mobile Dokumentprofile, weitere W3C-Verifiable-Credential-Profile 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 SD-JWT VC, mobile Dokumentprofile, weitere W3C-Verifiable-Credential-Profile 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 SDK- und API-basierten Issuer-Flows mit mehreren Credential-Profilen 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- und Agentenbausteinen für Schlüssel, Credentials und Präsentationen 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 VDX- beziehungsweise Verifier-Prozessen mit Policy- und Eventauswertung 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 Trust-Policies, Credential-Status, Schlüsselwechsel und versionierten Metadaten 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: IDK-, EDK- und VDX-Komponentenkette

Die drei Bausteinfamilien werden als getrennte Verantwortungsbereiche aufgebaut und anschließend zu einer durchgängigen Austauschstrecke verbunden. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Funktionen und Abhängigkeiten von IDK, EDK und VDX in einer Komponentenmatrix erfassen.
2. Schritt 2: Identitäts- und Schlüsselkonfiguration im Entwicklungsbaustein anlegen.
3. Schritt 3: EUDI-nahe Credential- und Protokollprofile im entsprechenden Baustein konfigurieren.
4. Schritt 4: Austausch- und Verifikationsprozess in VDX modellieren.
5. Schritt 5: Events, Fehler und Korrelation über alle Komponenten hinweg nachverfolgen.

Kontrollpunkt: Jede Komponente besitzt eine klar abgegrenzte Aufgabe; Querschnittsdaten sind korrelierbar, aber datensparsam protokolliert.

Modul 10: Policy- und Eventverarbeitung

Technische Verifikation, fachliche Policy und Prozessereignisse werden zu einem kontrollierten Entscheidungsfluss zusammengeführt. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Technische Grundprüfungen und fachliche Zulassungsregeln getrennt definieren.
2. Schritt 2: Policy-Reihenfolge, Abbruchbedingungen und erklärbare Fehlercodes konfigurieren.
3. Schritt 3: Erfolgs-, Ablehnungs- und Nachprüfungsereignisse an einen Testworkflow übergeben.
4. Schritt 4: Doppelte, verspätete und außerhalb der Reihenfolge eintreffende Events testen.
5. Schritt 5: Audit- und Datenschutzanforderungen für Ereignisdaten festlegen.

Kontrollpunkt: Ein fachlicher Entscheid kann aus den zugrunde liegenden technischen Prüfungen und Policy-Regeln rekonstruiert werden.

Modul 11: Unternehmensintegration und Automatisierung

Die Plattform wird über IDK-, EDK- und VDX-Komponenten, SDKs, APIs und Event-Schnittstellen 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 Sphereon 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: Mandanten, Policies und erweiterte Protokollvarianten

Erweiterte Konfigurationen von Sphereon werden für mehrere Organisationen und unterschiedliche Vertrauensniveaus aufgebaut. Dabei wird geprüft, welche Varianten standardkonform, interoperabel und betrieblich beherrschbar sind. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Zwei Mandanten mit getrennten Schlüsseln, Profilen, Branding- und Vertrauensregeln einrichten.
2. Schritt 2: Unterschiedliche Credential-Formate und Präsentationsprofile in einer gemeinsamen Testmatrix abbilden.
3. Schritt 3: Policy-Sätze für niedriges, mittleres und erhöhtes Vertrauensniveau definieren.
4. Schritt 4: Konflikte zwischen globalen, mandantenspezifischen und fachlichen Regeln gezielt auslösen.
5. Schritt 5: Freigabe-, Vier-Augen- und Änderungsverfahren für produktionsnahe Konfigurationen dokumentieren.

Kontrollpunkt: Mandantentrennung, Policy-Prioritäten und unterstützte Varianten sind technisch nachgewiesen und revisionsfähig beschrieben.

Modul 14: Sicherheit, Betrieb und technische Abnahme

Für Sphereon 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 15: Integriertes Abschlusslabor

Alle Komponenten von Sphereon 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 Sphereon-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 Sphereon.
• 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 Sphereon 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 Sphereon. Statt einer reinen Produktdemonstration entstehen wiederverwendbare Konfigurationen, Testfälle und Betriebsanforderungen. Damit lassen sich PoC, Ausschreibung, Architekturreview und Pilotbetrieb mit nachvollziehbaren Kriterien vorbereiten.