Zusammenfassung

  • RFC 9901 lässt den Holder keine, einige oder alle ausgestellten Disclosures vorlegen. Für jeden vorgelegten Wert kann ein Verifier den Digest im vom Issuer signierten JWT prüfen.
  • Das beweist die Bindung des vorgelegten Werts an die Signaturstruktur, nicht die Vollständigkeit der Akte, die aktuelle Richtigkeit aller Tatsachen oder eine lokale Zugangsentscheidung.

Ein sauber verifizierter Claim verführt zu einer unsauberen Folgerung: Wenn der eine Wert stimmt, werde der Rest schon keine Rolle spielen. Selektive Offenlegung baut gerade darauf, dass der Rest nicht automatisch beim selben Verifier landet.

RFC 9901 definiert dafür den SD-JWT. Der Issuer signiert einen JWT; für selektiv offenlegbare Claims kann er einen Digest statt des Klartextes aufnehmen. Eine Disclosure enthält ein zufälliges Salt, gegebenenfalls einen Claim-Namen und den Wert. Der Holder erhält die Ausgabedaten und wählt bei jeder Präsentation, welche Disclosures er sendet. Der Verifier berechnet den Digest erneut und findet ihn im signierten JWT wieder.

Das Urteil lautet dann nur: Dieser vorgelegte Wert gehörte zu diesem signierten Versprechen. RFC 9901 erlaubt ausdrücklich jede Teilmenge, einschließlich einer leeren. Der Issuer kann offen sichtbare und selektive Claims mischen und Decoy Digests ergänzen. Ein fehlender Eintrag ist deshalb weder ein Gegenbeweis noch ein vollständiges Negativmerkmal; nicht einmal die Zahl der zurückgehaltenen Claims lässt sich daraus zuverlässig ableiten.

Die Eigentümerschaft der einzelnen Aussagen muss sichtbar bleiben. Der Issuer formuliert und signiert die Struktur und bestimmt die Offenlegbarkeit. Der Holder wählt die Präsentation. Der Verifier prüft Signaturen und Digests. Die Anwendung legt die Claim-Semantik aus, wendet ihre Regel an und führt gegebenenfalls einen Zustandswechsel aus. „Die Berechtigung wurde bewiesen“ vermischt diese verschiedenen Handlungen zu einem Urteil, das der Transport nicht geliefert hat.

Eine Issuer-Signatur schützt die Integrität seit Ausstellung. Sie sagt nicht, wie eine Tatsachenbehauptung gewonnen wurde, ob sie heute noch zutrifft oder welche Bedeutung sie in jedem System hat. RFC 7519 schafft den Claim-Rahmen, das IANA-Register koordiniert Namen. Ob ein Claim erforderlich, hinreichend oder abgelaufen ist, wird durch das jeweilige Profil und die lokale Prüfrichtlinie bestimmt. RFC 8725 empfiehlt für verschiedene JWT-Verwendungen ausdrücklich Typisierung und eigene Validierungsregeln.

Key Binding ist eine weitere, aber optionale Aussage. Verlangt die Verifier-Policy sie, signiert der Holder einen KB-JWT über den Hash des SD-JWT, einen Nonce und eine Audience. Damit kann die Schlüsselinnehabung für diese Präsentation nachgewiesen werden. Daraus folgen weder die Offenlegung aller entscheidungsrelevanten Claims noch ihre aktuelle Wahrheit noch eine Erlaubnis für die angefragte Wirkung. Wird Key Binding nicht verlangt, kann jeder Besitzer eines SD-JWT ihn an einen Dritten weiterreichen und Disclosures entfernen.

Das Protokoll hält kritische Grenzen fest. Inhalt, der für Authentizität oder Gültigkeit nötig ist, darf der Issuer nicht als selektiv offenlegbar behandeln; welche Inhalte kritisch sind, legt das Anwendungsprofil fest. Der Verifier muss die Issuer-Signatur und die Zuordnung jeder Disclosure zum Digest prüfen. Die Regel über Vollständigkeit bleibt bei der lokalen Instanz, die den Vorgang tatsächlich annehmen oder ablehnen kann.

Eine brauchbare Prüfkette enthält daher Issuer und Schlüsselpolitik, Typ und Profil, verlangte und vorgelegte Claims, Digest-Ergebnisse, Key-Binding-Anforderung, Nonce, Audience, Richtlinienversion und den abschließenden Effekt. Ein Logeintrag „Token gültig“ sagt nicht, welche dieser Entscheidungen wirklich gefallen sind.

Heng Lus Trennung von Darstellung, lokaler Entscheidung und ausgeführter Wirkung dient hier als redaktionelle Bremse. RFC 9901 macht ein begrenztes Versprechen transportierbar. Es erteilt weder dem sichtbaren Teil Vollständigkeitsautorität noch der Signatur die Macht, die Endentscheidung zu ersetzen.

Sources