Seminar Interoperabilitätslabor – OpenID4VC, SD-JWT VC und mdoc

Das viertägige Labor prüft die herstellerübergreifende Zusammenarbeit von Issuer-, Wallet- und Verifier-Produkten. OpenID-basierte Ausgabe und Präsentation, SD-JWT VC, mobile Dokumentprofile, Trust, Status, Redirect-Flows und Konformitätsabweichungen werden in einer Cross-Matrix getestet.

Inhaltsübersicht

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

Zielsetzung

Ziel ist ein begrenztes, technisch belegtes Interoperabilitätsprofil für mindestens zwei unabhängige Implementierungen. Am Ende liegen Capability-Matrix, automatisierte Positiv- und Negativtests, Abweichungsregister sowie Freigabekriterien für Pilot und Beschaffung vor.

Zielgruppe

Softwarearchitektur, Entwicklung, Plattformbetrieb, IAM, PKI, Informationssicherheit, technische Produktverantwortung sowie Projektleitungen für digitale Identitäten, Wallets und verifizierbare Nachweise. Besonders geeignet für Architektur-, Integrations-, Test- und Abnahmeteams in Multi-Vendor-Wallet-Projekten.

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 mindestens einem Issuer-, Wallet- oder Verifier-Produkt ist erforderlich.

Laborumgebung

1. Isolierte Laborinstanz für OpenID4VC-, SD-JWT-VC- und mdoc-Interoperabilität 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 unabhängige Issuer-/Wallet-/Verifier-Implementierungen mit getrennten Testmandanten.
6. Testprofile für SD-JWT VC und mobile Dokumente sowie kontrollierbare Trust- und Statusdienste.

Seminarinhalte

Modul 1: Interoperabilitätsziel und Rollenmodell

Ein gemeinsames Referenzszenario für zwei unabhängige Issuer-, Wallet- und Verifier-Implementierungen wird fachlich und technisch festgelegt. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Geschäftsfall, Nachweisarten, Rollen und Vertrauensniveau definieren.
2. Schritt 2: Implementierung A und B den Rollen Issuer, Wallet und Verifier in wechselnden Kombinationen zuordnen.
3. Schritt 3: Remote-, Same-Device-, Cross-Device- und gerätenahe Abläufe abgrenzen.
4. Schritt 4: Erwartete Positiv- und Negativergebnisse je Kombination festlegen.
5. Schritt 5: Testdaten, personenbezogene Daten und Protokollmetadaten getrennt klassifizieren.

Kontrollpunkt: Die Testmatrix enthält klare Erfolgskriterien für jede Herstellerkombination.

Modul 2: Capability- und Profilmatrix

Unterstützte Formate, Algorithmen, Bindungen, Protokolloptionen und Metadaten werden vor der Implementierung systematisch verglichen. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Issuer-, Wallet- und Verifier-Metadaten beider Implementierungen erfassen.
2. Schritt 2: Unterstützte Credential-Formate, Signaturalgorithmen und Holder-Bindungen gegenüberstellen.
3. Schritt 3: Autorisierungs-, Response- und Präsentationsmodi in einer Matrix dokumentieren.
4. Schritt 4: Trust-, Status- und Registrierungsabhängigkeiten ergänzen.
5. Schritt 5: Kleinsten gemeinsamen interoperablen Profilumfang festlegen.

Kontrollpunkt: Der gemeinsame Profilumfang ist explizit und enthält keine stillschweigenden Herstellerannahmen.

Modul 3: Metadaten, Discovery und Client-Bindung

Metadaten und Client- beziehungsweise Verifier-Bindungen werden auf Konsistenz, Authentizität und Laufzeitverhalten geprüft. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Issuer-, Authorization- und Verifier-Metadaten veröffentlichen beziehungsweise einlesen.
2. Schritt 2: Endpunkte, unterstützte Optionen und Schlüsselreferenzen validieren.
3. Schritt 3: Statische und dynamische Client-Bindung im Labor vergleichen.
4. Schritt 4: Veraltete, widersprüchliche und manipulierte Metadaten testen.
5. Schritt 5: Caching, Aktualisierung und Fehlerreaktion mit maximalem Alter festlegen.

Kontrollpunkt: Protokollentscheidungen werden aus authentischen und zum Zeitpunkt der Sitzung gültigen Metadaten abgeleitet.

Modul 4: OpenID-basierte Credential-Ausgabe

Credential-Angebot, Autorisierung, Token, Nonce, Proof und Credential-Antwort werden über Implementierungsgrenzen hinweg geprüft. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Credential-Konfiguration und Angebot beim Issuer A anlegen.
2. Schritt 2: Angebot mit Wallet B im Same-Device- und Cross-Device-Verfahren öffnen.
3. Schritt 3: Autorisierung, Token- und Proof-Schritte einzeln protokollieren.
4. Schritt 4: Credential übernehmen und Signatur, Bindung, Claims und Zeiten analysieren.
5. Schritt 5: Falsche Konfiguration, abgelaufene Nonce, doppelten Abruf und ungültigen Proof testen.

Kontrollpunkt: Wallet B übernimmt ein von Issuer A ausgestelltes Credential ohne herstellerspezifische Sonderanpassung.

Modul 5: Autorisierungsvarianten und Transaktionsbindung

Unterschiedliche Autorisierungsmodelle werden auf Sicherheit, Benutzerführung und Interoperabilität verglichen. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Vorab autorisierten und interaktiv autorisierten Testfluss konfigurieren.
2. Schritt 2: Transaktionscode, Sitzung, Wallet-Schlüssel und Identitätsprüfung voneinander abgrenzen.
3. Schritt 3: Bindung an Credential-Konfiguration und Ziel-Wallet prüfen.
4. Schritt 4: Abbruch, Wiederaufnahme, falschen Code und parallele Sitzung testen.
5. Schritt 5: Geeignete Variante für niedriges und erhöhtes Risiko begründen.

Kontrollpunkt: Autorisierungsstärke und Credential-Risiko sind nachvollziehbar aufeinander abgestimmt.

Modul 6: SD-JWT VC und selektive Offenlegung

SD-JWT-VC-Profile werden auf Claim-Disclosures, Holder-Bindung, Status und unterschiedliche Parser- beziehungsweise Verifier-Verhalten geprüft. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Gemeinsames Claim-Modell und offenlegbare Claim-Gruppen definieren.
2. Schritt 2: Credential mit Disclosures erzeugen und in beiden Wallets analysieren.
3. Schritt 3: Minimale Offenlegung für zwei Prüfzwecke erstellen.
4. Schritt 4: Präsentation mit Verifier A und B prüfen.
5. Schritt 5: Fehlende, fremde, doppelte und manipulierte Disclosures testen.

Kontrollpunkt: Beide Verifier akzeptieren nur profilkonforme Disclosures und liefern erklärbare Fehler.

Modul 7: Mobile Dokumentprofile

Mobile Dokumente werden hinsichtlich Namespace, Issuer- und Device-Authentisierung, Session-Bindung und Transportvarianten untersucht. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Gemeinsames Testprofil mit Datenelementen und Gültigkeitsregeln erstellen.
2. Schritt 2: Dokument ausstellen und in mindestens einer mobilen Wallet speichern.
3. Schritt 3: Remote- und gerätenahe Präsentationssitzung aufbauen.
4. Schritt 4: Issuer- und Device-Authentisierung getrennt validieren.
5. Schritt 5: Replay, fremdes Gerät, abgelaufene Sitzung und unzulässiges Datenelement testen.

Kontrollpunkt: Transport- und Sitzungsvariante verändert nicht unbemerkt die fachliche Aussage des Dokuments.

Modul 8: OpenID-basierte Präsentation

Presentation Request und Response werden mit wechselnden Wallet- und Verifier-Produkten sowie minimalen Datenanforderungen umgesetzt. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Verifier-Anforderung mit Client-Bindung, Nonce, Zielgruppe und Rückgabeweg erzeugen.
2. Schritt 2: Credential- beziehungsweise Claim-Abfrage profilkonform formulieren.
3. Schritt 3: Anfrage in Wallet A und B verarbeiten.
4. Schritt 4: Präsentationsantwort bei Verifier A und B validieren.
5. Schritt 5: Fehlerhafte Zielgruppe, abgelaufene Nonce, Replay und nicht unterstützte Anforderung testen.

Kontrollpunkt: Vier Wallet-/Verifier-Kombinationen liefern konsistente Positiv- und Negativergebnisse.

Modul 9: Abfragesprache, Claim-Auswahl und Policy

Technische Abfrage, Wallet-Auswahl und fachliche Verifier-Policy werden getrennt modelliert, damit Datenminimierung und Erklärung erhalten bleiben. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Pflicht-, optionale und alternative Nachweise definieren.
2. Schritt 2: Mehrere geeignete Credentials in der Wallet bereitstellen.
3. Schritt 3: Auswahl- und Prioritätsregeln ohne versteckte Mehrdatenanforderung testen.
4. Schritt 4: Technische Validität und fachliche Policy als getrennte Ergebnisobjekte ausgeben.
5. Schritt 5: Nicht erfüllbare, mehrdeutige und überbreite Anfragen kontrolliert behandeln.

Kontrollpunkt: Eine fachliche Ablehnung wird nicht fälschlich als kryptografischer Fehler dargestellt.

Modul 10: Trust, Status und Prüfzeitpunkt

Ausstellervertrauen, Credential-Status, Schlüsselzustand und Prüfzeitpunkt werden implementierungsübergreifend vereinheitlicht. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Vertrauensquelle und zulässige Aussteller je Credential-Typ definieren.
2. Schritt 2: Statusmechanismus und Aktualisierungsintervall festlegen.
3. Schritt 3: Credential mit aktuellem und veraltetem Status prüfen.
4. Schritt 4: Ausstellerentzug, Schlüsselwechsel und Statusdienst-Ausfall testen.
5. Schritt 5: Prüfbeleg mit verwendeten Trust- und Statusständen erzeugen.

Kontrollpunkt: Jedes Ergebnis nennt den maßgeblichen Prüfzeitpunkt und die verwendeten Vertrauensinformationen.

Modul 11: Same-Device-, Cross-Device- und Redirect-Flows

Übergänge zwischen Browser, Wallet, QR-Code, Deep Link und Callback werden auf Sicherheit und robuste Zustandsführung getestet. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Same-Device- und Cross-Device-Sequenzen als Zustandsautomaten modellieren.
2. Schritt 2: Redirects, Deep Links und QR-Codes an Sitzung und Zielanwendung binden.
3. Schritt 3: App-Wechsel, Browser-Rückkehr und parallele Sitzungen testen.
4. Schritt 4: Manipulierten Link, fremde Sitzung und verspäteten Callback ablehnen.
5. Schritt 5: Barrierefreiheit und verständliche Abbruchwege prüfen.

Kontrollpunkt: Kein Übergabekanal erlaubt die Übernahme einer fremden oder abgelaufenen Sitzung.

Modul 12: Fehlercodes, Konformität und Abweichungsmanagement

Abweichungen werden reproduzierbar erfasst und nach Profilfehler, Implementierungsfehler, optionale Variante oder unklare Spezifikation klassifiziert. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Gemeinsamen Katalog erwarteter Fehler und Statuscodes erstellen.
2. Schritt 2: Gezielte Protokoll-, Format-, Zeit- und Metadatenfehler injizieren.
3. Schritt 3: Verhalten aller Implementierungskombinationen erfassen.
4. Schritt 4: Abweichung mit Ursache, Auswirkung, Workaround und Verantwortlichkeit dokumentieren.
5. Schritt 5: Regressionstests für behobene oder begrenzte Abweichungen automatisieren.

Kontrollpunkt: Interoperabilitätsprobleme bleiben als testbare Befunde erhalten und werden nicht durch nicht dokumentierte Sonderfälle verdeckt.

Modul 13: Sicherheit, Datenschutz und Korrelationsrisiken

Protokoll- und Formatinteroperabilität wird um Bedrohungen durch Replay, Redirect-Manipulation, Tracking, überbreite Claims und Metadatenlecks ergänzt. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Bedrohungsmodell über Issuer, Wallet, Verifier, Browser und Vertrauensdienste erstellen.
2. Schritt 2: Nonce, Zielgruppe, Client-Bindung und Transportabsicherung prüfen.
3. Schritt 3: Credential-, Wallet- und Sitzungskennungen auf Korrelationspotenzial untersuchen.
4. Schritt 4: Logs und Telemetrie auf unnötige Claims und dauerhafte Identifikatoren prüfen.
5. Schritt 5: Schutzmaßnahmen und verbleibende Einschränkungen je Profil dokumentieren.

Kontrollpunkt: Interoperabilität wird nicht auf Kosten von Datenminimierung und Sitzungssicherheit erreicht.

Modul 14: Herstellerübergreifendes Abschlusslabor

Zwei Issuer, zwei Wallets und zwei Verifier werden in einer vollständigen Cross-Matrix mit Status- und Trust-Änderung getestet. Die Konfiguration wird als reproduzierbare Laborstrecke aufgebaut, dokumentiert und mit Positiv- sowie Negativtests geprüft.

1. Schritt 1: Labor aus Baseline neu aufbauen und Capability-Matrix verifizieren.
2. Schritt 2: Je Format mindestens zwei herstellerübergreifende Issuance-Flows ausführen.
3. Schritt 3: Je Format mindestens vier Wallet-/Verifier-Kombinationen prüfen.
4. Schritt 4: Status-, Trust-, Replay-, Metadaten- und Redirect-Fehler wiederholen.
5. Schritt 5: Interoperabilitätsprofil, Abweichungsmatrix und Freigabegrenzen abschließen.

Kontrollpunkt: Das freigegebene Profil ist durch automatisierte Cross-Tests und dokumentierte Einschränkungen belegt.

Praxisaufgaben

1. Capability-Matrix für zwei vollständige Produktstapel erstellen.
2. Herstellerübergreifende Credential-Ausgabe in Same-Device- und Cross-Device-Flows testen.
3. SD-JWT-VC-Disclosures und mobile Dokumentpräsentationen mit wechselnden Verifiern prüfen.
4. Trust-, Status-, Metadaten-, Replay-, Redirect- und Zeitfehler gezielt injizieren.
5. Abweichungen klassifizieren und Regressionstests automatisieren.
6. Begrenztes Interoperabilitätsprofil mit Freigabe- und Ausschlusskriterien dokumentieren.

Laborartefakte

• Capability- und Profilmatrix.
• Cross-Vendor-Issuance- und Presentation-Testautomatisierung.
• SD-JWT-VC- und mdoc-Testvektoren.
• Fehler-, Konformitäts- und Abweichungsregister.
• Sicherheits- und Datenschutzbewertung der Übergabeflüsse.
• Freigegebenes Interoperabilitätsprofil mit klaren Grenzen.

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 Interoperabilitätslabor 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.
• Testbelege enthalten Produkt-, Versions-, Profil- und Konfigurationsstand, damit Befunde reproduzierbar bleiben.
• Erfolgreiche Demonstrationen werden nicht als allgemeine Standardkonformität verallgemeinert.

Praxisnutzen

Das Seminar schafft belastbare Fakten für Multi-Vendor-Projekte. Statt sich auf Produktangaben zu verlassen, werden konkrete Kombinationen, Profile und Fehlerfälle geprüft. Das reduziert Integrationsrisiken und liefert verwertbare Kriterien für Architektur, Beschaffung, Abnahme und Regressionstests.