Zusammenfassung

  • Die IETF kündigte für den 28. September 2026 ein virtuelles OAuth-Interimstreffen mit der Agenda „Anthropic & OpenAI Agentic Use Cases“ an. Daraus folgen weder eine Unterstützung bestimmter Entwürfe durch die Unternehmen noch eine Arbeitsgruppenentscheidung.
  • RAR kann bekannte Beträge und Empfänger fein ausdrücken; DPoP bindet ein Token an einen Schlüssel. Erst wenn das Modell die konkrete Aktion erzeugt, entsteht die Restfrage: Eine unabhängige Quelle muss die endgültigen Werte autorisieren, und der erste wirksame Sink muss diese Bindung vor Ausführung prüfen und verbrauchen.

Die übliche Sicherheitsgeschichte fragt, ob ein Angreifer das Token gestohlen hat. Agentische Systeme brauchen eine zweite Geschichte: Was, wenn der legitime Inhaber nach einer vergifteten Eingabe den richtigen API-Aufruf mit dem falschen Konto erstellt? Schlüssel, Audience, Resource und Scope können stimmen. Der Akt stimmt nicht.

Die IETF-Ankündigung nennt 17:00 bis 18:00 UTC und genau eine Agendazeile. Sie belegt Thema und Termin. Sie sagt nicht, was Anthropic oder OpenAI vortragen, unterstützen oder einsetzen. Ein Treffen ist kein Konsens; ein individueller Internet-Draft bleibt individuell.

Die OAuth-Charter beschreibt begrenzte Delegation ohne Weitergabe langfristiger Zugangsdaten oder zwingend der Identität. RFC 9396 ergänzt authorization_details für feingranulare Angaben. Das Zahlungsbeispiel enthält Betrag und Gläubiger. Sind diese Werte bekannt und genehmigt, kann der Resource Server eine abweichende POST-Anfrage ablehnen. RAR ist nicht bloß grob.

Der Mailinglistenauftakt vom 1. September fragt nach dem späteren Moment: Das Modell erzeugt {tool, arguments} erst im Lauf. Prompt Injection kann einzelne Parameter verändern, ohne den erlaubten Dienst zu verlassen. Im Austausch über RAR wird die Grenze präzisiert. Das Kopieren der Werte in ein feines Autorisierungsobjekt beschreibt sie; es schafft keine vom unzuverlässigen Vorschlag getrennte Entscheidung.

Diese Quelle kann ein früher bestätigtes Mandat, eine versionierte Unternehmensregel, eine geprüfte Bestellung oder eine Ausnahmefreigabe sein. Unabhängig heißt nicht zwangsläufig manuell. Es heißt, dass der Kandidat seine Erlaubnis nicht selbst ausstellen kann.

Der Chen-Entwurf zeigt Context Collapse: Am Montag beauftragt Alice eine Picknickplanung; am Dienstag erscheint parks.book neben calendar.write, nachdem der Agent den Ort gewählt hat. Zweck, Ort und Preis fehlen auf dem Consent-Screen. Der Text verlangt nicht, dass OAuth Sprache versteht oder Aufgaben orchestriert; er sucht die Verbindung zwischen früheren Grenzen und späterer Ausführung.

Der Liu-Entwurf trennt einen strukturierten Operation-JWT ohne ursprünglichen Naturtext vom Token für eine bestätigte konkrete Operation. Der Yossif-Entwurf nennt die menschliche Autorisierung T0 und die autonome Ausführung T1. Tausende Rückfragen vernichten Autonomie; fehlende T0-Grenzen lassen T1 ungebunden. Das Dokument definiert Anforderungen, aber ausdrücklich kein Protokollverhalten.

Alle genannten Entwürfe sind Work in Progress. Sie sind keine RFCs und ihre normativen Wörter erzeugen keine Betreiberpflicht.

Für die technische Bindung müssen Argumente deterministisch kanonisiert werden. JSON-Reihenfolge, Zahlenform, Defaults, URL und Live-Formularwerte können Identität oder Wirkung ändern. Werkzeug, Ziel, Betrag, Objekt und Konsequenzklasse gehören in eine versionierte Digest-Regel. Der Digest ist jedoch nur ein Commitment: Er konserviert auch einen schädlichen Empfänger perfekt. Er beweist Gleichheit, nicht Berechtigung.

Der Das-Entwurf beschreibt ein mögliches Host-Profil: Candidate Act nicht wirksam halten, kanonisieren, validieren, Evidenz festschreiben, begrenzte Authority ausgeben, am Dispatch Sink prüfen und verbrauchen, erst dann aufrufen. Es ist ein individueller Informational-Draft mit IP-Hinweis, keine IETF-Auswahl. Sein brauchbarer Satz lautet: tool_use ist nicht invoke().

Der Sink ist die erste Stelle mit Außenwirkung. Bei HTTP kann es der Resource Server sein, bei lokalen Funktionen bereits die Function Map, bei Computer Use der Browser-Controller und bei MCP der Client-Wrapper. Ein alter Pfad mit denselben Credentials entwertet die Schranke. Ein Folgebeitrag formuliert als Teilnehmeransicht, dass ein Host ohne Übereinstimmung von finalem Parameter-Digest und autorisierter Policy Assertion nicht aufrufen solle.

RFC 9449 bindet per DPoP das Token an einen Schlüssel und erkennt Replay. Er beurteilt nicht den falschen Akt eines legitimen Schlüsselinhabers. RFC 8693 trägt Delegations- und Impersonation-Semantik durch Token Exchange, autorisiert aber nicht automatisch Endargumente.

Nach dem Aufruf bleibt Outcome-Evidenz nötig. Stürzt der Host nach dem Verbrauch der Authority und vor der Antwort ab, kann der Effekt fehlen oder bereits bestehen. Blinder Retry dupliziert, blindes Aufgeben verliert. Gemeinsame Idempotenz, Reconciliation und getrennte Zustände für autorisiert, gesendet, angenommen, festgeschrieben und beobachtet sind Pflicht. HTTP 200 ist kein Nutzerergebnis.

Die Belegkette beginnt mit Principal, Policy-Version, Mandat und Task Context. Es folgen Tool, Konsequenz, Kanonisierung und Digest; unabhängige Grundlage, Issuer, Audience, Ablauf und Schlüssel; Sink, Live-Digest, Replay und Consumption; schließlich Antwort, dauerhafter Zustand, Kompensation und sichtbares Ergebnis. Ohne diese Genealogie kann „Task abbrechen“ abgeleitete Rechte und Wirkungen nicht finden.

Heng Lus Minimum Initial Specification spricht für ein dünnes gemeinsames Format für Mandat, Akt, Bindung, Sink und Receipt; lokale Risikopolitik soll lokal bleiben. Seine Reality Layers trennen Protokollfakt, Autorisierungsfakt, Implementierungsbeleg, Außenstatus und Ergebnis. Running-Code Primacy verlangt Tests: Empfänger nach Freigabe ändern, Single-Use konkurrieren lassen, Legacy-Pfad nutzen, Host nach Consumption töten. Wirkung ohne passenden Beleg ist symbolische Autorisierung.

Quellen