Seminar SD-JWT VC – Architektur, Typen, Metadaten und Status

Seminarprofil

Das Seminar ordnet SD-JWT VC als Credential-Format in eine vollständige Issuer-Wallet-Verifier-Architektur ein. Behandelt werden Verifiable-Credential-Type, Typmetadaten, Claim-Semantik, Schlüsselbindung, Anzeigeinformationen, Status, Trust und sichere Verifier-Policies.

Lernziele

• SD-JWT und SD-JWT VC fachlich und technisch sauber unterscheiden
• Credential-Typen und Typmetadaten versionierbar und vertrauenswürdig gestalten
• Claim-Modelle, Pflichtangaben und Offenlegungsregeln datensparsam definieren
• Status, Ablauf, Re-Issuance und Schlüsselrotation in den Lebenszyklus einordnen
• Eine Architektur mit klaren Trust- und Policy-Grenzen dokumentieren

Inhaltsübersicht

1. Formatgrenzen und Rollen
2. Credential Type
3. Typmetadaten
4. Claim-Semantik
5. Offenlegungspolitik des Issuers
6. Holder Binding
7. Issuer Trust und Schlüsselauflösung
8. Status und Gültigkeit
9. Verifier Policy
10. Referenzarchitektur

Seminarinhalte

Schritt 1: Formatgrenzen und Rollen

Das Credential-Format wird von Issuance- und Presentation-Protokollen getrennt. Issuer, Wallet, Verifier, Type-Metadata-Provider und Statusdienst erhalten explizite Vertrauensgrenzen.

Schritt 2: Credential Type

Der Typ identifiziert Semantik und Verarbeitungsregeln eines Credentials. Namensvergabe, Versionierung, Delegation und die Vermeidung unkontrollierter Typüberschneidungen werden erarbeitet.

Schritt 3: Typmetadaten

Metadaten können Anzeige, Claim-Struktur, Integritätsinformationen und weitere Verarbeitungsangaben liefern. Herkunft, Cache, Version und Fehlerverhalten werden abgesichert, damit Metadaten nicht zur Code- oder Policy-Injektion werden.

Schritt 4: Claim-Semantik

Datentypen, Wertebereiche, Zeitangaben und optionale Claims werden eindeutig beschrieben. Der Verifier verlässt sich nicht auf bloße UI-Bezeichnungen, sondern auf versionierte maschinenlesbare Regeln.

Schritt 5: Offenlegungspolitik des Issuers

Der Issuer entscheidet, welche Claims immer sichtbar, selektiv offenlegbar oder gar nicht auszustellen sind. Abhängigkeiten verhindern widersprüchliche Teilpräsentationen.

Schritt 6: Holder Binding

Schlüsselbestätigung und Key-Binding-Präsentation werden in das Credential-Modell eingebettet. Mehrgerätebetrieb, Recovery und unverknüpfte Präsentationen werden gegen den Schutzbedarf abgewogen.

Schritt 7: Issuer Trust und Schlüsselauflösung

Issuer-Identifier, Schlüsselquellen und zulässige Algorithmen werden durch lokale Trust Policy begrenzt. Rotation, Kompromittierung und veraltete Schlüssel dürfen nicht allein durch Remote-Metadaten entschieden werden.

Schritt 8: Status und Gültigkeit

Ablaufdaten, Statuslisten, Re-Issuance und kurzlebige Credentials werden verglichen. Aktualität, Offline-Fähigkeit, Datenschutz und Ausfallverhalten bestimmen die passende Kombination.

Schritt 9: Verifier Policy

Formatvalidierung, Typprüfung, Offenlegungsumfang, Holder Binding, Status und fachliche Entscheidung werden getrennt. Unerwartete Claims erhöhen nicht automatisch das Vertrauen und werden nicht ungeprüft weitergereicht.

Schritt 10: Referenzarchitektur

Die Ergebnisse werden zu einem Komponenten- und Datenflussmodell zusammengeführt. Schnittstellen, Caches, Trust Stores, Statusdaten und Auditpunkte werden dokumentiert.

Praxisanteil

• Credential-Typ und Claim-Schema für einen eigenen Nachweis entwerfen
• Type-Metadata-Vertrauens- und Cache-Policy formulieren
• Status- und Re-Issuance-Optionen anhand eines Betriebsfalls bewerten
• Issuer-Wallet-Verifier-Referenzarchitektur zeichnen

Zielgruppe

Identity- und Solution-Architekten, Issuer- und Wallet-Teams, Produktverantwortliche, Security und Datenschutz

Voraussetzungen

Grundkenntnisse von JWT, Verifiable Credentials und digitalen Vertrauensmodellen