Zusammenfassung

  • Am 1. September eröffnete die IESG die IETF-weite Last Call für SD-JWT VC -19. Die OAuth Working Group beantragt eine Veröffentlichung als Proposed Standard; Stellungnahmen sind bis 15. September möglich, eine Entscheidung gibt es noch nicht.
  • vct bezeichnet den Haupttyp. Mit aka_vcts kann der Aussteller weitere Typen behaupten, während extends in Type Metadata eine Vererbungskette bildet.
  • Diese Mechanismen erleichtern Typabgleich und Wiederverwendung. Der Entwurf untersagt, daraus die Befugnis des Ausstellers abzuleiten.
  • Auch der Publisher der Type Metadata braucht eine eigene Autoritätsgrundlage. Erreichbarkeit und Integrität des Dokuments belegen nicht, dass der Publisher diesen Typ definieren darf.
  • Ein vom jeweiligen Ökosystem geführter Autoritätsbeleg kann beide Mandatsquellen sichtbar machen, ohne der IETF ein weltweites Vertrauensregister zu übertragen.

Ein Prüfverfahren ist noch keine Billigung

Die IETF-Mitteilung vom 1. September meldet keinen fertigen Standard. Sie eröffnet die gemeinschaftsweite Last Call zu draft-ietf-oauth-sd-jwt-vc-19. Die OAuth Working Group möchte den Text als Proposed Standard veröffentlichen lassen. Die Frist endet am 15. September. Zum Redaktionsschluss zeigte der Datatracker weiterhin „In Last Call“, keinen Telechat-Termin und eine noch erforderliche IANA-Prüfung.

Die IESG bezeichnet die Last Call im Regelfall als letzte offene Phase der gemeinschaftlichen Prüfung. Genau deshalb darf ihr Beginn nicht wie ein Ergebnis behandelt werden. Der Text kann sich ändern; Genehmigung, Ablehnung oder weitere Bearbeitung sind offen.

Technisch baut SD-JWT VC auf RFC 9901 auf. Ein Aussteller signiert eine JSON-Nutzlast. Manche Angaben bleiben im Klartext, andere werden durch Hashwerte vertreten, damit der Inhaber bei der Präsentation nur ausgewählte Angaben offenlegen kann. Der Prüfer validiert Ausstellersignatur und Offenlegungen und verlangt, soweit seine Richtlinie dies vorsieht, zusätzlich eine kryptografische Bindung an den Inhaber.

Der neue Entwurf gibt diesem Verfahren die Gestalt eines digitalen Nachweises. Jeder Nachweis enthält einen verpflichtenden, groß-/kleinschreibungssensitiven und kollisionsresistenten Typbezeichner vct. Konkrete Werte legt der Entwurf bewusst nicht fest. Bedeutung, Claim-Regeln und zusätzliche Ausstellungs- und Prüfpolitik entstehen in den jeweiligen Ökosystemen.

Diese Arbeitsteilung ist notwendig. Ein Internetformat kann nicht bestimmen, wer in einem Staat Ausweise, in einem Berufsstand Zulassungen oder in einer Organisation Mitgliedsnachweise ausstellen darf. Es kann nur verhindern, dass seine eigenen Mechanismen als Ersatz für diese Bestimmung missverstanden werden.

Typverwandtschaft ist keine institutionelle Abstammung

In Type Metadata kann extends einen abgeleiteten Typ mit einem Basistyp verbinden. Der Consumer verarbeitet den Basistyp zuerst. Geerbte Claim-Regeln bleiben bestehen. Ein Kindtyp darf eine geerbte Pflichtangabe nicht abschwächen und eine festgelegte Regel zur selektiven Offenlegung nicht umkehren. So lassen sich gemeinsame Anforderungen wiederverwenden, ohne sie in jedem Untertyp zu kopieren.

aka_vcts arbeitet auf einer anderen Ebene. Der Aussteller fügt dem Nachweis optional eine Liste weiterer Typen hinzu. Ein Prüfer, der einen allgemeinen Typ angefordert hat, kann damit einen spezielleren Nachweis zuordnen. Das funktioniert auch ohne Type Metadata; die Reihenfolge der Liste bedeutet nichts, und die genannten Typen müssen nicht über extends verbunden sein.

Die Funktion ist praktisch, aber ihr Beweiswert bleibt begrenzt. Abschnitt 7.7 warnt vor einem Angreifer, der einen legitimen Typ nachahmt oder erweitert. Ein vertraut aussehender Stammbaum reicht nicht zur Annahme. Identität, Vertrauensstatus sowie einschlägige Akkreditierung oder Registrierung des Ausstellers müssen eigenständig geprüft werden.

Das gilt ausdrücklich auch für aka_vcts: Die Behauptung stammt vom Aussteller und ist nur so vertrauenswürdig wie er selbst. Ein Alias kann den gewünschten Typ treffen, aber er kann den Aussteller nicht akkreditieren.

Für Produkte folgt daraus eine klare Darstellungsregel. „Typ passt“ und „Aussteller ist befugt“ sind zwei verschiedene Zustände. Ein gemeinsames grünes Symbol würde aus einer semantischen Beziehung eine institutionelle Vollmacht machen.

Hinter den Metadaten steht ein weiterer Akteur

Der Entwurf nennt außerdem einen Publisher. Er veröffentlicht Type Metadata oder andere referenzierte Ressourcen und muss nicht mit dem Aussteller identisch sein. Ein Standardisierungsgremium, eine Gemeinschaft oder eine Ökosystem-Autorität kann diese Rolle übernehmen.

Das Dokument kann Namen, Claims, Darstellung und Vererbung beschreiben. HTTPS schützt den Abrufweg; ein Integritätswert kann die verwendete Fassung fixieren. Beides beantwortet jedoch nur, welches Dokument abgerufen wurde und ob es unverändert blieb. Es beantwortet nicht, warum dieser Publisher den Typ beschreiben darf.

Abschnitt 7.8 verlangt deshalb, Type Metadata nicht als richtig oder bedeutsam vorauszusetzen, wenn der Publisher nicht als maßgebliche Stelle für den Typ anerkannt ist. Ökosysteme sollen Governance- oder Akkreditierungsverfahren festlegen, die autorisierte Publisher und Verlässlichkeitsbedingungen benennen.

Damit sind zwei Mandatskanten zu dokumentieren: die Befugnis des Ausstellers, Nachweise dieses Typs auszugeben, und die Befugnis des Publishers, die Typmetadaten zu definieren. Selbst wenn dieselbe Organisation beide Rollen ausübt, können Reichweite, Laufzeit und Widerruf auseinanderfallen.

Schlüsselbesitz ist kein Amtsnachweis

Der Entwurf verlangt eine belastbare Signaturprüfung. Nach einem von der anwendbaren Richtlinie zugelassenen Verfahren muss der Prüfer feststellen, dass der Signaturschlüssel zum behaupteten Aussteller gehört. Gelingt dies nicht, ist der Nachweis zurückzuweisen.

Diese Prüfung ist unverzichtbar, aber eng. Eine Organisation kann ihren Schlüssel vollständig beherrschen und dennoch keine staatliche Lizenz ausstellen dürfen. Ein nicht anerkannter Publisher kann konsistente Metadaten bereitstellen. Eine korrekte Prüfsumme kann einen unautorisierten Inhalt unverändert konservieren.

Heng Lus Begriff der Mandatswäsche beschreibt den Übergang: Eine technische oder institutionelle Hülle tritt an die Stelle der Autorität, auf die sie allenfalls verweisen dürfte. Im Wallet genügen dafür oft ein bekannter Typ, eine gültige Signatur und das Wort „verifiziert“. Fehlt die Aufschlüsselung, liest der Nutzer den Schlüsselnachweis als Befugnisnachweis.

Die Revision -19 unterbindet diese Abkürzung im normativen Text. Ob sie auch in der Praxis unterbleibt, hängt von Protokollen, Richtlinien und Oberflächen ab.

Ein Autoritätsbeleg für die externe Entscheidung

Die Lösung muss kein zentrales IETF-Verzeichnis sein. Jedes Ökosystem kann für akzeptierte Kombinationen aus Aussteller und Typ einen kleinen, versionierten Autoritätsbeleg führen.

Der Beleg nennt den genauen vct, akzeptierte aka_vcts und die verarbeitete extends-Kette. Er dokumentiert Ausstellerkennung, Methode der Schlüsselermittlung und -validierung sowie die externe Befugnisquelle: Registereintrag, Akkreditierung, Gesetz, Vertrag oder Trust List.

Ein getrenntes Feld nennt den Type-Metadata-Publisher, Dokumentversion und Integritätsreferenz sowie die Grundlage seiner Autorität für diesen Typ. Geltungsgebiet, Laufzeit, Version der Prüfrichtlinie und Entscheidungszeitpunkt machen den Eintrag reproduzierbar. Eine ausdrückliche Nichtaussage hält fest, dass Signatur, Typabgleich, Alias, Vererbung und erfolgreicher Abruf jeweils allein kein institutionelles Mandat belegen.

Auch Fehlerzustände müssen präzise bleiben. „Nicht geprüft“, „nicht gefunden“, „abgelaufen“, „außerhalb des Geltungsbereichs“ und „nicht autorisiert“ sind keine Synonyme. Fehlende öffentliche Evidenz beweist keine fehlende Befugnis.

Dieser Beleg ist ein redaktioneller Vorschlag dieses Artikels, kein Bestandteil von -19. Er protokolliert lediglich jene externe Entscheidung, die das Format zu Recht nicht selbst trifft.

Die Zuständigkeit bleibt bei den Ökosystemen

Staatliche Identität, Berufsrecht, Bildungsnachweise und private Mitgliedschaft beruhen auf unterschiedlichen Rechts- und Vertragsordnungen. Würde die IETF sie in ein Schema pressen, entstünde eine neue globale Kontrollstelle, und jede lokale Zuständigkeitsänderung ließe das gemeinsame Format altern.

Der Autoritätsbeleg gehört daher in Ökosystemprofile, Prüfrichtlinien, Wallet-Vertrauenskonfigurationen oder Programmregister. Die IETF hält die technische Grenze sauber und definiert die Verarbeitungsbausteine. Sie entscheidet nicht, wer weltweit welche Urkunde ausstellen darf.

Auch der Datenschutz setzt Grenzen. vct und aka_vcts sind nicht selektiv verbergbar und können bereits den Nutzungskontext verraten. Der Entwurf warnt zudem davor, dass inhaberspezifische Ausstellerkennungen zusammen mit Online-Metadatenabrufen ein Phone-home-Signal erzeugen können. Der Beleg sollte deshalb stabile Aussteller-Typ-Kombinationen verwenden, Caching oder Pinning ermöglichen und keine Abfrage beim Aussteller für jede Präsentation erzwingen.

Quellen

  1. IETF — Last Call zu SD-JWT VC -19
  2. IETF Datatracker — SD-JWT-VC-Dokumentstatus
  3. IETF — SD-JWT VC, Revision -19
  4. RFC 9901 — Selective Disclosure for JSON Web Tokens
  5. IESG — Last Call Guidance to the Community
  6. IETF — Charter der OAuth Working Group
  7. Heng Lu — Mandate Laundering