Seminar EBSI – Issuer-, Wallet- und Verifier-Integration

Eine Ende-zu-Ende-Lösung muss Issuance, Speicherung, Presentation und Verifikation über mehrere Systemgrenzen hinweg konsistent beherrschen. Das Seminar verbindet Protokollprofile, Metadaten, Credential-Verarbeitung, Trust-Prüfung und Fehlerszenarien zu einer integrierten Referenzstrecke.

Inhaltsübersicht

• Zielsetzung
• Zielgruppe
• Voraussetzungen
• Seminarinhalte
• Praxisübungen
• Methodik

Zielsetzung

• Issuer-, Wallet- und Verifier-Verantwortlichkeiten sauber trennen und verbinden
• OpenID4VCI- und OpenID4VP-Abläufe einschließlich Metadaten und Sicherheitsparametern implementieren
• Credential-, Schema-, Status- und Trust-Prüfungen in eine feste Validierungsreihenfolge überführen
• Ende-zu-Ende-Tests, Fehlerbehandlung und Betriebsbeobachtung für die Integrationsstrecke aufbauen

Zielgruppe

Backend- und Integrationsentwickler, Wallet-Teams, Verifier-Entwickler, technische Architekten, QA-Verantwortliche und Plattformingenieure.

Voraussetzungen

Gute Kenntnisse zu OAuth 2.0, OpenID Connect, JWT, REST, JSON und Public-Key-Kryptografie. EBSI-Grundlagen und ein vorbereiteter Entwicklungsarbeitsplatz sind erforderlich.

Seminarinhalte

1. Schritt 1: Integrationskontext und Verträge definieren

   Geschäftssystem, Issuer, Wallet, Verifier, Registries und externe Identitätsquellen werden mit Endpunkten, Verantwortlichkeiten, Datenklassifikation und Fehlergrenzen beschrieben.

2. Schritt 2: Issuer-Metadaten und Credential-Angebot aufbauen

   Unterstützte Credential-Konfigurationen, Formate, Algorithmen, Endpunkte, Autorisierungsvarianten und Gültigkeiten werden als maschinenlesbarer Vertrag bereitgestellt und gegen Testfälle geprüft.

3. Schritt 3: Autorisierte und vorautorisierte Issuance umsetzen

   Authorization-Code- und Pre-Authorized-Code-Abläufe werden mit Nonce, Token, PKCE oder vergleichbaren Schutzmechanismen, Credential Request und kontrollierter Ausgabe durchgespielt.

4. Schritt 4: Credential erzeugen und signieren

   Claims werden aus dem Fachsystem übernommen, gegen das Schema validiert, mit Issuer-, Zeit-, Status- und Trust-Metadaten ergänzt und mit dem vorgesehenen Schlüssel signiert.

5. Schritt 5: Wallet-Verarbeitung integrieren

   Angebotsannahme, Metadatenauflösung, Token-Austausch, Credential-Speicherung, Holder-Bezug und sichere Fehlerdarstellung werden aus Sicht eines interoperablen Wallets geprüft.

6. Schritt 6: Presentation Request erstellen

   Der Verifier beschreibt benötigte Credential-Typen, Claims, Zwecke und Einschränkungen. Request Object, Nonce, State, Response Mode und Rückkanal werden gegen Replay und Verwechslung abgesichert.

7. Schritt 7: Verifiable Presentation verarbeiten

   Wallet-Auswahl, Präsentation, Holder-Nachweis, Token-Validierung und die Bindung an Request, Client und Sitzung werden Schritt für Schritt nachvollzogen.

8. Schritt 8: Trust und Status vollständig prüfen

   DID, Signatur, Schema, Issuer-Akkreditierung, Trust Chain, Credential-Status, Zeitbedingungen und fachliche Policy werden in definierter Reihenfolge validiert und mit eindeutigen Fehlercodes versehen.

9. Schritt 9: Fehler- und Wiederholungslogik entwickeln

   Abbruch, Time-out, doppelte Antwort, ungültige Metadaten, nicht verfügbare Registries, Statuskonflikte und Schlüsselwechsel werden mit Retry-, Cache- und Benutzerflussregeln behandelt.

10. Schritt 10: Ende-zu-Ende-Abnahme automatisieren

    Positive, negative und Grenztests werden mit Referenzdaten, Protokollmitschnitten und maschinenlesbaren Prüfergebnissen zu einer wiederholbaren Integrationspipeline verbunden.

Praxisübungen

• Credential-Angebot und Issuance-Flow für einen vorgegebenen Credential-Typ konfigurieren
• Presentation Request und Verifier-Policy mit positiven und negativen Fällen entwickeln
• Eine fehlerhafte Trust- oder Statusprüfung anhand technischer Spuren lokalisieren
• Eine Ende-zu-Ende-Testmatrix für Issuer, Wallet, Verifier und Registries erstellen

Methodik

Fachvortrag, Sequenzdiagramme, Live-Konfiguration, API-Labor, Debugging und automatisierte Integrationstests. Vier Tage sind erforderlich, weil Issuance und Presentation jeweils eigene Sicherheits- und Metadatenprofile besitzen und erst am vierten Tag in stabilen Ende-zu-Ende- und Fehlerfalltests zusammengeführt werden.