Summary

  • as_signature umfasst nach Abschnitt 3.6 nur id und das vollständige user_confirmation mit angezeigtem Inhalt, Benutzerhandlung und Zeitstempel.
  • audit_trail soll die semantische Übersetzung in autorisierte Operationen erklären, ist aber ausdrücklich ausgeschlossen. Zwei verschiedene Trails ergaben lokal denselben vorgeschriebenen Signaturinput.
  • Der äußere Signaturmantel eines intakten JWT schützt weiterhin alle eingebetteten Felder. Bei undurchsichtigen Tokens schützt TLS den Abrufkanal, nicht die spätere Portabilität des ausgeschlossenen Trails.

Der scheinbare Widerspruch ist eine Objektgrenze

draft-liu-oauth-authorization-evidence-01 definiert einen Evidenzkern aus Kennung, Benutzerbestätigung und abgetrennter JWS. Die Bestätigung enthält den exakten Bildschirmtext, die Art der bestätigenden Handlung und eine NumericDate-Zeit.

Abschnitt 3.6 verlangt ein neues JSON-Objekt mit ausschließlich id und user_confirmation. Es wird mit JCS nach RFC 8785 kanonisiert und als Bytefolge signiert. Erweiterungsfelder jenseits von id, user_confirmation und as_signature dürfen nicht aufgenommen werden. Der Audit-Trail ist deshalb nicht versehentlich ungeschützt, sondern liegt normativ außerhalb des inneren Signaturobjekts.

Wenn der Text später as_signature für undurchsichtige Tokens als einzigen Integritätsschutz des Evidenzdatensatzes bezeichnet, muss „Datensatz“ anhand dieses Signaturinputs gelesen werden. Die Signatur macht die aufgezeichnete Bestätigung portabel. Sie macht nicht automatisch jede benachbarte Erklärung portabel.

Der Entwurf begrenzt auch die Autorität der Bestätigung. Sie beweist, dass der Autorisierungsserver sie aufgezeichnet hat, nicht unabhängig, dass der Nutzer tatsächlich zustimmte. Server und Signaturschlüssel gehören derselben Vertrauensdomäne. Stärkere Nichtabstreitbarkeit braucht eine Nutzersignatur oder unabhängige Prüfung.

Ausgerechnet die Erklärung bleibt daneben

audit_trail soll laut Abschnitt 4 semantische Nachvollziehbarkeit liefern: Wie wurde die Absicht interpretiert und in autorisierte Operationen übersetzt? Zu den optionalen Feldern gehören eine Evidenzreferenz, semantic_expansion_level und proposal_ref.

Die Klassen von none bis high sind Beschreibungen, keine ausführbaren Diffs. medium kann ausdrücken, dass „günstige Kopfhörer“ in eine 50-Dollar-Grenze und eine Kategorie überführt wurden. Es sagt nicht, welche Regel, Datenquelle oder Policy-Version diese Auswahl traf.

Die Vorschlagsreferenz ist eine undurchsichtige, vom Autorisierungsserver vergebene URI. Der Entwurf definiert weder Abrufprotokoll noch Inhalts-Hash, Aufbewahrungszeit oder Zugriffsrecht. Eine vorhandene Referenz garantiert also nicht, dass ein späterer Prüfer denselben Vorschlag reproduzieren kann.

Das ist keine Behauptung über einen Angriff. Eine Implementierung kann einen unveränderlichen Speicher, einen signierten Antwortmantel oder ein weiteres Commitment hinzufügen. Die Spezifikation macht diese Eigenschaft nur noch nicht zur gemeinsamen Mindestregel.

Der lokale Test hielt den Signaturinput konstant

Für die Reproduktion entstanden zwei vollständige Objekte mit derselben Kennung, Anzeige, Handlung und Zeit. Das eine trug medium und eine 50er-Vorschlagsreferenz, das andere high und eine 500er-Referenz. Die vollständigen kanonischen Objekte und Hashes unterschieden sich. Die Projektion nach Abschnitt 3.6 blieb gleich: aec26fa5351ab57f144fd6b387b297969f73e34ec3ea5a557592a0b2d3a7b512.

Der Versuch zeigt ausschließlich die Konstruktionsgrenze. Er validiert nicht die abgekürzte JWS des Entwurfs, bricht weder JWS noch JCS, untersucht kein Produkt und belegt weder Missbrauch noch Transaktion oder Schaden.

Das äußere JWT und der TLS-Kanal leisten anderes

In einem nach RFC 9068 signierten JWT-Access-Token deckt die äußere Signatur das vollständige eingebettete Objekt einschließlich Audit-Trail ab. Eine Änderung im intakten Token würde diese Signatur ungültig machen. Es wäre falsch, aus der schmalen inneren Signatur auf unerkannte Manipulierbarkeit des vollständigen JWT zu schließen.

Bei einem undurchsichtigen Token ruft der Ressourcenserver Daten über RFC-7662-Introspektion oder einen eigenen Endpunkt ab. TLS schützt Gegenstelle und Antwort während dieser Verbindung. Nach Extraktion, Speicherung oder Weitergabe wird der Kanal aber nicht zu einer Signatur über benachbarte Metadaten. Der abgetrennte JWS bleibt auf seine Projektion begrenzt.

Introspektion liefert zudem gegenwärtigen Autorisierungskontext. active ist serverabhängig, Antworten können je Ressourcenserver variieren, Caching tauscht Aktualität gegen Last. Daraus entsteht nicht automatisch ein dauerhaftes Semantikprotokoll.

Begründung und Policy haben getrennte Autorität

Der begleitende Rego-Entwurf trennt Evidenz für das Warum von der Policy für das Was. authorization_evidence und rego_policy stehen im Gesamtbeispiel nebeneinander. Die innere Bestätigungssignatur bindet weder Policy-URI noch Entry Point oder Auswertungseingaben.

Ein intaktes äußeres JWT kann die kombinierte Darstellung binden. Ein undurchsichtiges System muss für Abruf und Aufbewahrung selbst sorgen. Sonst verschmilzt „autorisiert“ Anzeige, Interpretation, Policy, Ressourcenentscheidung, Versand, Ausführung und Wirkung und überlässt die fehlende Bedeutung dem ausführenden Baustein.

Ein Konstruktionspass für die Interpretation

Bei folgenreichen Agentenaktionen sollte ein Interpretationspass Evidenz- und Sitzungskennung, Hash und Sprache der Anzeige, unveränderlichen Vorschlag, aufgelöste Operation, semantischen Diff und erzeugende Komponente, Policy-Kennung, Hash, Einstieg und Inputs, Aussteller, Zielgruppe, Subjekt, Agent und Client, Ressourcenentscheidung, Hash des versandten Auftrags, Ausführungsbeleg und getrennt beobachtete Wirkung verbinden.

Das ist eine Analyse von Daniel Kade, keine Anforderung der Revision 01. Vertrauliche Inhalte können zugriffsgeschützt und über Hashes gebunden bleiben. Eine minimale Spezifikation muss nicht alles zentralisieren; sie muss die kleinste reproduzierbare Entscheidungskette benennen.

Sources and limits

Beobachtungsstand ist der 30. September 2026, Asia/Shanghai. Revision 01 ist ein aktiver individueller Internet-Draft, kein RFC, kein OAuth-Arbeitsgruppenkonsens und kein Adoptionsnachweis. Die lokale Reproduktion belegt nur die definierte Projektion. Sie belegt keinen JWS/JCS-Bruch, keine Manipulation im TLS-Kanal, keinen Implementierungsfehler, keine Böswilligkeit, keinen Schaden und keine abgeschlossene Operation. Der Entwurf kann sich ändern, ersetzt werden oder verfallen.