Seminar EBSI und swiyu – Protokoll-, Wallet- und Verifier-Interoperabilität

Gemeinsame Standardnamen garantieren noch keine austauschbaren Implementierungen. Unterschiedliche Profilversionen, Metadaten, Credential-Formate, Request Objects, Abfragesprachen, Verschlüsselung und Trust-Prüfungen müssen systematisch getestet und gegebenenfalls über Adapter verbunden werden.

Inhaltsübersicht

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

Zielsetzung

• OID4VCI- und OID4VP-Profile von EBSI und swiyu auf Nachrichten- und Parameterfolge vergleichen
• Wallet-, Issuer- und Verifier-Fähigkeiten in einer maschinenlesbaren Kompatibilitätsmatrix erfassen
• Adapter- und Routingmuster für unterschiedliche Credential- und Trust-Profile entwerfen
• Positive, negative und versionsübergreifende Ende-zu-Ende-Tests automatisieren

Zielgruppe

Wallet-Entwickler, Issuer- und Verifier-Teams, Integrationsarchitekten, Protokollspezialisten, Testautomatisierer und technische Product Owner.

Voraussetzungen

Sichere Kenntnisse zu OAuth 2.0, OpenID Connect, JWT, JWE, REST und Public-Key-Kryptografie. Grundlagen beider Trust-Infrastrukturen sind erforderlich.

Seminarinhalte

1. Schritt 1: Fähigkeiten und Profilstände inventarisieren

   Unterstützte Credential-Formate, Algorithmen, DID-Methoden, Issuance-Flows, Response Modes, Wallet-Bindung, Abfragesprachen, Verschlüsselung und Statusmethoden werden pro Komponente und Version erfasst.

2. Schritt 2: Issuer-Metadaten vergleichen

   Authorization Server, Credential Issuer Metadata, Credential-Konfigurationen, Formatangaben, Schlüsselbindung, Deferred Issuance und profilbezogene Erweiterungen werden Feld für Feld bewertet.

3. Schritt 3: OID4VCI-Nachrichtenfolge prüfen

   Credential Offer, Authorization Request, Token Request, Nonce, Credential Request, Response, Deferred Flow und Fehlerantworten werden mit exakten Vorbedingungen und Sicherheitsprüfungen gegenübergestellt.

4. Schritt 4: Wallet-Verhalten vereinheitlichen

   Deep Links, Metadatenauflösung, Benutzerfreigabe, Credential-Auswahl, Holder- oder Device-Bindung, Speicherung, Offenlegung und verständliche Fehlermeldungen werden als Wallet-Fähigkeitsprofil beschrieben.

5. Schritt 5: Verifier-Metadaten und Request Objects vergleichen

   Client-Identität, signierte Request Objects, Nonce, State, Response URI, Verschlüsselung, erlaubte Algorithmen und Profilversionen werden auf kompatible und abweichende Erwartungen untersucht.

6. Schritt 6: Abfragesprachen und Claim-Auswahl behandeln

   DCQL, bestehende Presentation-Definition-Modelle und profilbezogene Credential-Anforderungen werden in ein neutrales Anforderungsmodell überführt. Nicht äquivalente Filter erhalten klare Grenzen.

7. Schritt 7: OID4VP und Presentation verarbeiten

   Wallet-Antwort, VP Token beziehungsweise formatbezogene Präsentation, Key Binding, Audience, Nonce, JWE und Session-Bindung werden in einer gemeinsamen Validierungsstrecke geprüft.

8. Schritt 8: Trust- und Statusadapter entwerfen

   EBSI Trust Chain, TIR und TSR werden swiyu Trust Statements, Base Registry, Trust Registry und Token Status List gegenübergestellt. Adapter liefern getrennte technische und fachliche Vertrauensaussagen.

9. Schritt 9: Routing und Dual-Stack-Architektur aufbauen

   Profilkennung, Credential-Typ, DID-Methode, Issuer-Metadaten und Wallet-Fähigkeiten steuern den passenden Verarbeitungspfad. Fallbacks bleiben explizit und dürfen keine Prüfungen überspringen.

10. Schritt 10: Interoperabilität automatisiert testen

    Pairwise-Tests, Golden Flows, Negativfälle, Versionswechsel, Schlüsselrotation, Statusänderung, Registry-Ausfall und Wiederholungen werden in einer nachvollziehbaren Testmatrix ausgeführt.

Praxisübungen

• Fähigkeitsmatrix für zwei Wallets, zwei Issuer und zwei Verifier erstellen
• OID4VCI- und OID4VP-Sequenzen mit abweichenden Profilparametern vergleichen
• Neutrales Claim-Anforderungsmodell für DCQL und alternative Abfragen entwerfen
• Routing- und Adapterarchitektur für Dual-Stack-Verifikation modellieren
• Interoperabilitätstest mit gezielten Negativfällen spezifizieren

Methodik

Fachvortrag, Protokollanalyse, Sequenzdiagramme, Metadaten- und Payload-Reviews, Adapterdesign und Testautomatisierung. Vier Tage sind erforderlich, weil Issuance, Wallet-Verhalten, Verification und Trust-Adapter jeweils eigenständige Interoperabilitätsdimensionen darstellen.