Zusammenfassung

  • RFC 9901 ist eine IETF-Standards-Track-Spezifikation für selektive Offenlegung einzelner JSON-Elemente in JWS-Objekten; JWTs sind der primäre Anwendungsfall.
  • Der Aussteller signiert Digests statt Klartext, gibt dem Holder getrennte Disclosures und der Prüfer rekonstruiert nur anhand der vorgelegten, geprüften Disclosures.
  • SD-JWT ist weder Verschlüsselung noch Zero-Knowledge-Technik noch ein anonymes Credential und garantiert keine automatische Unverknüpfbarkeit.

Für eine Objekt-Eigenschaft enthält eine Disclosure Salt, Claim-Namen und Claim-Wert. Für ein Array-Element enthält sie Salt und Wert. Das JSON-Array wird vor dem Hashing UTF-8-kodiert und Base64url-kodiert. Jedes Salt muss kryptografisch zufällig, unabhängig und je selektiv offengelegtem Claim eindeutig sein; bis zur Offenlegung darf es nur dem Holder bekannt sein. Empfohlen sind mindestens 128 zufällige Bits. Das oberste _sd_alg bestimmt den Disclosure-Hash; verschachteltes _sd_alg ist verboten. Fehlt es, gilt sha-256, und Implementierungen müssen sha-256 unterstützen.

Das issuer-signierte JWT muss signiert sein; none ist unzulässig. Der Prüfer validiert die Aussteller-Signatur und jeden Digest jeder präsentierten Disclosure, bevor er die verarbeitete Payload rekonstruiert. Rekursive Offenlegung ist möglich: Eine verborgene Kind-Struktur kann die Disclosure ihres Elternknotens voraussetzen. Eine Präsentation mit fehlender oder ungültiger Abhängigkeitskette ist zurückzuweisen. Decoy-Digests können die ursprüngliche Anzahl oder Existenz verborgener Claims verschleiern. Sie vergrößern jedoch das Token und mindern nur einen Seitenkanal; sie verhindern keine Korrelation.

Key Binding ist optional, sofern nicht ein Profil oder eine Einsatzregel es verlangt. Wenn es verlangt wird, enthält das SD-JWT den öffentlichen Holder-Schlüssel oder einen Verweis darauf. Der Holder signiert ein KB-JWT mit typ kb+jwt sowie iat, aud, nonce und sd_hash. Dieser sd_hash bindet das KB-JWT an genau das issuer-signierte JWT und die ausgewählten Disclosures. Der Prüfer kontrolliert Holder-Schlüssel, Signatur, Algorithmus, typ, Zeitfenster, Audience, Nonce und sd_hash.

Profile müssen festlegen, welche Gültigkeits-Claims notwendig sind. Wird etwa exp selektiv offengelegt, kann dem Prüfer die Information fehlen, die er für eine Ablehnung braucht; das Profil muss dann die Disclosure verlangen und ihr Fehlen zurückweisen. RFC 9901 überlässt Vertraulichkeit dem Transport und definiert keine Verschlüsselung. Bei Risiken durch passive Beobachtung oder Korrelation ist vertraulicher Transport daher erforderlich; JWE kann ein SD-JWT auf leckageanfälligen Kanälen kapseln. Speicherung sollte auf den betrieblich erforderlichen Umfang beschränkt bleiben.

Konkrete Konformitätsprüfungen

  1. JWS nach RFC 7515 und JWT-Grundlagen nach RFC 7519 prüfen; none ablehnen.
  2. _sd_alg prüfen, bei Abwesenheit sha-256 verwenden und für jedes Salt Zufälligkeit, Unabhängigkeit und Eindeutigkeit kontrollieren; empfohlen sind 128 Bits.
  3. Jeden Disclosure-Digest aus der korrekten Kodierung neu berechnen und ungültige Werte oder fehlende Eltern-Disclosures ablehnen.
  4. Pflicht-Claims, vertraulichen Transport und – falls gefordert – alle KB-JWT-Felder einschließlich sd_hash prüfen.

Betreiber-Entscheidungspfad

Zuerst den minimalen Nachweis pro Zweck festlegen. Claims, die für Gültigkeit nötig sind, dürfen nicht durch eine optionale Offenlegung unprüfbar werden. Danach Schema, eindeutige Salts und Hash auswählen, Key Binding nur bei passender Policy verlangen und Nonce, Audience, Zeitfenster sowie den Lebenszyklus des Holder-Schlüssels verwalten. Anschließend vertraulichen Transport, begrenzte Speicherung, Audit-Regeln und gegebenenfalls Revocation-Callbacks definieren, ohne eine bestimmte RFC-seitige Widerrufsmethode zu behaupten.

Quellen