Zusammenfassung

  • draft-ietf-oauth-transaction-tokens-11 definiert ein kurzlebiges, signiertes JWT, das Identität und Transaktionskontext durch eine Call Chain innerhalb der von aud begrenzten Trust Domain trägt. Es ist ein aktiver Standards-Track-Internet-Draft im Zustand WG Consensus: Waiting for Write-Up, kein RFC und keine endgültige IETF-Genehmigung.
  • Der Empfänger muss JWS-Signatur, Audience und Ablauf prüfen. Diese Kontrollen belegen Integrität und Geltungsbereich des Containers. Sie zeigen allein nicht, ob jeder Wert in rctx oder tctx zugeliefert, beobachtet, abgeleitet oder unabhängig bestätigt wurde.
  • Daniel Kade schlägt für jede entscheidungsrelevante Aussage eine Herkunftshülle vor: Quelle, tatsächlich ausgeführte Prüfung, Beobachter, Zeit, Transformation, Richtlinienversion, Aktualität, erlaubte Nutzung, Widersprüche und Ergebnis. Sie kann Hashes oder Verweise statt vollständiger Tokens und unnötiger Personendaten speichern. Sie ist keine IETF-Vorgabe.

In der Zugriffsakte stand employee_status: active. Daneben zeigte die Oberfläche eine gültige Signatur. Für den Prüfer sah beides wie eine einzige Zusicherung aus. Erst bei der Nachfrage wurde klar, dass niemand mehr wusste, ob der Status aus dem Personalverzeichnis, aus einem vorgelagerten Token oder aus einem unbestätigten Request-Feld stammte.

Der TTS hatte genau diese Zeichenfolge signiert. Das beantwortete nicht, warum die Organisation sie für wahr gehalten hatte.

Die Verwechslung entsteht, wenn kryptografische und sachliche Gewissheit in einem Status zusammenfallen. Eine JWS-Signatur kann zeigen, welcher Schlüssel welche Bytes signiert hat und dass diese Bytes danach unverändert blieben. Der Transaction Token Service bestimmt, welche Claims bereitgestellt werden. Die Herkunft, Prüfung, Frische und Zweckbindung jedes einzelnen Werts sind eine weitere Ebene.

Revision 11 ist weit, aber nicht endgültig

Der Datatracker-Eintrag führt Revision 11 vom 30. Juli 2026 als aktiven Internet-Draft der OAuth Working Group auf dem Standards Track. Zum Recherchezeitpunkt lautete der WG-Zustand WG Consensus: Waiting for Write-Up, der IESG-Zustand I-D Exists. Ein verantwortlicher Area Director und ein Telechat-Termin waren nicht eingetragen. Das ist relevanter Fortschritt, jedoch weder RFC noch abgeschlossene IETF-Entscheidung.

Die Dokumenthistorie und der offizielle Vergleich 10→11 begrenzen die sachliche Änderung: Korrigiert wurde ein Schreibfehler in der Historie. Das hier untersuchte Vertrauensmodell stand bereits in Revision 10. Die I-D-Ankündigung belegt die Veröffentlichung der neuen Fassung, nicht das Ende des Standardisierungswegs.

Der Entwurf löst ein bekanntes Problem verteilter Anwendungen. Eine Transaktion läuft vom Eingang durch mehrere Workloads. Jeder Hop benötigt Angaben über Identität, Zweck, Berechtigungsumfang und Vorgang, soll aber nicht zwingend den ursprünglichen externen Nachweis erhalten und selbst neu interpretieren. Das Transaction Token übermittelt deshalb einen gemeinsamen Kontext als kurzlebiges signiertes JWT innerhalb einer durch aud benannten Trust Domain.

Jede solche Domain besitzt genau einen logischen Transaction Token Service, auch wenn mehrere Instanzen betrieben werden. Der TTS authentifiziert den anfordernden Workload, prüft dessen Berechtigung zum Tokenbezug, stellt die Claims zusammen und signiert das Ergebnis. JWT liefert das Claim-Format, JWS die signierte Darstellung; die OAuth Working Group entwickelt den Vorschlag.

Tokenprüfung und Autorisierungsentscheidung bleiben getrennt

Ein empfangender Workload muss die JWS-Signatur validieren, aud seiner Trust Domain zuordnen und das Ablaufdatum prüfen. Besteht das Token diese drei Prüfungen, ist innerhalb seiner Zeitgrenze belegt, dass die vorgesehenen Bytes vom TTS signiert und nicht verändert wurden.

Danach darf der Empfänger die Informationen für eine lokale Autorisierung verwenden. Wie diese Entscheidung funktioniert, lässt der Entwurf bewusst offen. Der gemeinsame Aussteller transportiert Kontext; der Dienst, der eine Wirkung auslöst, bleibt für die Auslegung der benutzten Felder verantwortlich.

Das Transaction Token ist ausdrücklich kein Authentisierungsnachweis und darf nicht als OAuth Access Token verwendet werden. Ein Access Token im Sinne von OAuth 2.0 repräsentiert eine erteilte Befugnis. Das Transaction Token repräsentiert Transaktionskontext. Ähnliche Codierung gibt dem zweiten Objekt nicht die Autorität des ersten.

Auch Replay-Schutz entsteht nicht durch die Signatur. Die eindeutige txn-Kennung kann Erkennung oder einmalige Verwendung ermöglichen. Eine strikte Umsetzung über eine verteilte Call Chain kann jedoch gemeinsamen Zustand erfordern, der praktisch nicht verfügbar ist. Unveränderte Bytes können ein zweites Mal präsentiert werden.

Einheitliche Auswahl ist keine einheitliche Provenienz

Der obligatorische scope wird vom TTS festgelegt. Er darf den Scope des ursprünglichen Subject Tokens nicht erweitern. Versteht der TTS den Eingangs-Scope nicht, muss er ablehnen, statt Unkenntnis als unbeschränkte Befugnis zu lesen. Das ist eine konkrete normative Zusicherung gegen Rechteausweitung.

Bei rctx, dem empfohlenen Request- und Umgebungskontext, wird die Herkunft vielfältiger. Stellt der Anforderer Kontext bereit, sollte der TTS ihn bewerten. Ein endgültiger Wert kann exakt aus der Eingabe übernommen, daraus abgeleitet oder unabhängig vom TTS behauptet werden. Der TTS ist für die bereitgestellte Claim-Menge maßgeblich. Daraus folgt nicht, dass jeder Bestandteil nach demselben Verfahren erhoben und geprüft wurde.

Das ebenfalls empfohlene tctx soll Transaktionsdetails enthalten, die in der Call Chain unverändert bleiben. Sie können Request-Angaben wiedergeben, aus ihnen berechnet oder zusätzlich vom TTS gesetzt werden. Die Signatur schützt die ausgegebene Version; sie rekonstruiert nicht ihre Vorgeschichte.

Ein Beispiel macht den Unterschied sichtbar. request_ip stammt aus der Beobachtung eines authentifizierten Gateways. order_value wurde aus einem unsignierten Eingabeobjekt kopiert. risk_level berechnete der TTS nach Policy 43 aus einem geprüften Nachweis und einem aktuellen Signal. Dieselbe Signatur umfasst alle drei. Ihre Belegkraft hängt dennoch jeweils von Gateway, Eingabeberechtigung beziehungsweise Berechnungsgrundlage ab.

Damit sind rctx und tctx nicht grundsätzlich unvertrauenswürdig. Einzelne Werte können stark abgesichert sein. Die Stärke gehört aber zur konkreten Quelle, Kontrolle, Zeit, Transformation und Nutzung. Ein Container darf verschiedene Assurance-Klassen mischen; ein Verbraucher darf sie nur nicht unter einem pauschalen Etikett verstecken.

Unterschiedliche Subject Tokens erzeugen unterschiedliche Prüfhistorien

Als Subject Token kann ein OAuth- oder SAML-Token, ein selbst signiertes JWT, ein unsigniertes JSON-Objekt oder ein anderes vom TTS verstandenes Format dienen. Der TTS muss es validieren und bei signierten Objekten die Signatur prüfen. „Validiert“ umfasst daher je nach Typ andere Schritte: Aussteller, Schlüssel, Algorithmus, Audience, Zeit, Schema und geschützten Übertragungsweg.

Die JWT Best Current Practices zeigen, warum Algorithmus und Schlüssel nicht unkritisch aus dem Token selbst übernommen werden dürfen. OAuth Token Exchange ist ein verwandter Rahmen für Tokenaustausch; Transaction Tokens behandeln den internen Vorgangskontext. Ein unsigniertes JSON kann unter einem abgesicherten lokalen Vertrag zulässig sein, erhält dadurch aber nicht die kryptografische Herkunft eines validierten Credentials.

Zusätzlich prüft der TTS Authentisierung und Ausgabeberechtigung des anfordernden Workloads. Emissionsrichtlinie und Geschäftslogik sind deployment-spezifisch und außerhalb des Entwurfs. Zwei konforme Systeme können daher dasselbe Feld unterschiedlich prüfen. Ohne Richtlinienversion täuscht ein gemeinsamer Feldname eine gemeinsame Assurance vor.

exp ist nicht die Frische jeder Quelle

Transaction Tokens sollen Minuten oder weniger gelten und nur so lange wie der erwartete Aufruf. Unter einer TTS-Richtlinie kann das neue Token dennoch später als das bei der Ausgabe vorgelegte Subject Token ablaufen; der TTS sollte das Risiko bewerten. Das kann eine bereits begonnene kurze Kette stabil abschließen. Es bedeutet nicht, dass mit dem neuen exp alle vorgelagerten Fakten neu bestätigt wurden.

Ein OAuth Access Token kann vor seinem regulären Ende widerrufen werden. Je nach Risiko darf der TTS über Token Introspection oder einen ähnlichen Mechanismus den aktuellen Zustand prüfen. Eine universelle Live-Abfrage verlangt der Entwurf nicht. „Zeitlich gültig“ und „um 15:26 nicht widerrufen“ sind deshalb verschiedene Aussagen.

Replacement Tokens dürfen Befugnisse nicht erweitern und txn, sub oder aud nicht ändern. Sie dürfen Scope reduzieren, Assertions hinzufügen und unter einer Richtlinie die Lebensdauer verlängern. Die Call Chain der anfordernden Workloads muss erhalten bleiben, das Verfahren bleibt aber offen. Ohne Zuordnung neuer Claims zum jeweiligen Ersatzschritt sieht eine schrittweise entstandene Geschichte im Endtoken wie ein einziger Zeitpunkt aus.

Außerhalb der aud-Trust-Domain ist das Token keine portable Autorität. Für Domain-Übergänge verweist der Entwurf auf die getrennte OAuth-Arbeit zur Verkettung von Identität und Autorisierung. Eine technisch prüfbare Fremdsignatur importiert nicht die lokale Semantik der anderen Domain.

Ein Review-Hinweis bleibt ein Review-Hinweis

In einer WGLC-Nachricht vom 8. August 2026 unterstützte ein Reviewer das Weitergehen und erklärte seine Anmerkungen ausdrücklich für nicht blockierend. Er wünschte klarere Auditierbarkeit von Replacement Chains und warnte davor, in einem signierten Token transportierte Information mit einer unabhängigen Bestätigung durch den Aussteller gleichzusetzen.

Die Aussage ist relevant und begrenzt. Sie stammt von einem Reviewer und dessen berichteter Umsetzungserfahrung. Sie ist kein WG-Konsens, keine Häufigkeitsmessung, kein bestätigter Vorfall und kein Beleg für einen Defekt in Revision 11. Sie benennt eine plausible Fehlinterpretation, nicht deren Verbreitung.

Eine Herkunftshülle neben dem Entscheidungsbeleg

Daniel Kades redaktioneller Vorschlag ist eine Claim-Herkunftshülle für jeden tatsächlich verwendeten Wert. Sie hält Quellenklasse und nicht geheime Referenz, wirklich ausgeführte Validierung, Beobachter und Zeitpunkt, Transformation und Code- oder Richtlinienversion, bei Bedarf Aussteller, Schlüsselreferenz und Domain-Grenze, Frische- oder Widerrufsprüfung, erlaubte Nutzung, Sensitivität, Logging-Regel, Widersprüche, Downstream-Entscheidung, Ablauf und Abschluss fest.

Diese Hülle muss nicht im Transaction Token liegen und ist kein universelles Claim-Schema. Sie kann auf einen Emissionsbeleg verweisen, einen Token-Hash halten oder minimierte Evidenz adressieren. Der Entwurf verbietet, vollständige Tokens wörtlich zu protokollieren, weil sie wiederholbar sind und sensible Daten enthalten können. Ein Hash kann mit TTS-Ausgabedaten korrelieren; auch ein unsignierter JWS-Payload kann je nach Fall geloggt werden. Er kann weiterhin personenbezogene Angaben enthalten.

Ob eine IP-Adresse oder Umgebungseigenschaft rechtlich personenbezogen ist, hängt von der Jurisdiktion ab; dieser Artikel trifft keine Compliance-Entscheidung.

Die Hülle soll den Grund einer Entscheidung rekonstruierbar machen, ohne ein zweites Lager für nutzbare Bearer Tokens und Rohdaten zu schaffen. Gespeichert wird die Herkunft, nicht das Geheimnis.

Quellen