Seminar Spherity Produktlabor – EIDA Business Wallet und VERA DPP

Das Labor untersucht Spherity als Business-Wallet- und Digital-Product-Passport-Plattform für Organisationen, Produkte und Lieferketten. 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 Spherity. 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 Spherity 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 Spherity wird ausgehend von Business-Wallet- und Digital-Product-Passport-Plattform für Organisationen, Produkte und Lieferketten in fachliche und technische Verantwortungsbereiche zerlegt. Berücksichtigt werden insbesondere EIDA Business Wallet, VERA DPP, Issuer- und Verifier-Dienste, Trust- und Lieferkettenintegration. 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 Spherity 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 Organisations-, Rollen-, Maschinen- und Produktidentitäten mit delegierten Schlüsseln und Vertrauensbeziehungen 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 Verifiable Credentials, Organisations- und Produktnachweise, Digital-Product-Passport-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 Verifiable Credentials, Organisations- und Produktnachweise, Digital-Product-Passport-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 organisations- und produktbezogenen Issuer-Prozessen mit kontrollierter Datenherkunft 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 Business-Wallet-Verarbeitung für Organisationen, Dienste und berechtigte Rollen 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 B2B- und Lieferkettenprüfung mit fachlichen und regulatorischen Policies 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 Organisationsstatus, Lieferantenvertrauen, Produktstatus und aktualisierbaren Passport-Daten 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: Business Wallet und Maschinenidentitäten

Die Wallet wird als Organisations- und Dienstkomponente mit delegierten Rollen, automatisierten Transaktionen und technischen Identitäten aufgebaut. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Organisation, Standort, Dienst, Maschine und handelnde Person getrennt modellieren.
2. Schritt 2: Delegations- und Freigaberegeln für automatische sowie manuelle Transaktionen definieren.
3. Schritt 3: Schlüssel und Credentials je Rolle beziehungsweise technischer Einheit zuordnen.
4. Schritt 4: Maschinelle Präsentation mit Empfängerbindung und begrenzter Gültigkeit testen.
5. Schritt 5: Rollenwechsel, Wartung, Außerbetriebnahme und Notfallzugriff kontrolliert abbilden.

Kontrollpunkt: Automatisierte Transaktionen bleiben einer gültigen Organisation, Rolle und technischen Einheit zuordenbar.

Modul 10: Digital Product Passport mit VERA DPP

Produkt-, Herkunfts- und Konformitätsinformationen werden als versionierbare, verifizierbare Passport-Struktur modelliert. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Produktidentität, Chargen- beziehungsweise Serienbezug und Datenverantwortung definieren.
2. Schritt 2: Pflicht-, optionale und vertrauliche Passport-Daten trennen.
3. Schritt 3: Nachweise verschiedener Lieferkettenstufen in ein konsistentes Produktprofil einbinden.
4. Schritt 4: Aktualisierung, Korrektur, Rückruf und Ende des Produktlebenszyklus testen.
5. Schritt 5: Öffentliche, geschützte und nur selektiv offengelegte Ansichten prüfen.

Kontrollpunkt: Jede Passport-Angabe besitzt Herkunft, Verantwortlichkeit, Version und nachvollziehbare Gültigkeit.

Modul 11: Unternehmensintegration und Automatisierung

Die Plattform wird über Business Wallet, VERA DPP, APIs, Lieferketten- und Produktdatenadaptern 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 Spherity 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 Spherity 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 Spherity 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 Spherity-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 Spherity.
• 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 Spherity 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 Spherity. Statt einer reinen Produktdemonstration entstehen wiederverwendbare Konfigurationen, Testfälle und Betriebsanforderungen. Damit lassen sich PoC, Ausschreibung, Architekturreview und Pilotbetrieb mit nachvollziehbaren Kriterien vorbereiten.