Zusammenfassung

  • Der am 28. September veröffentlichte Erstentwurf AAuth Budgets sieht eine vom abrechnenden Dienst durchgesetzte Ausgabengrenze je Autorisierungstoken vor.
  • Die Obergrenze einer Person bleibt eine andere Größe: Bei mehreren aktiven Tokens muss der Aussteller Zuteilungen gemeinsam reservieren und unbekannte Nutzung später mit Messwerten abgleichen.

Eine Rechnung kann zu hoch sein, obwohl kein einzelnes Limit überschritten wurde. Angenommen, zwei Agentenaufträge erhalten gleichzeitig je einen Token über zehn Geldeinheiten. Die Beträge sind nur ein Gedankenexperiment. Der Dienst stoppt jeden Token gewissenhaft bei zehn; zusammen kann er trotzdem zwanzig berechnen. Wer eigentlich höchstens zehn für die Person freigeben wollte, hat die Grenze bereits beim Ausstellen der beiden Berechtigungen verfehlt. Das ist eine andere Fehlerstelle als ein ungenauer Zähler beim Dienst.

Dick Hardts erster Entwurf AAuth Budgets vom 28. September 2026 macht diese Trennung zum Gegenstand eines Protokollvorschlags. Er ist ein individueller, ausdrücklich explorativer Internet-Draft. „Standards Track“ ist die beabsichtigte Entwicklung, nicht sein heutiger Status: Der IETF-Datatracker führt ihn als vorhandenen Entwurf ohne festgelegten RFC-Stream. Weder eine verabschiedete Norm noch eine Arbeitsgruppenentscheidung oder breite Einführung ist damit belegt. Die Erweiterung baut auf einem separaten AAuth-Protokollentwurf auf. Ein Agent fordert ein Budget an; die Ressource nennt Einheit und mögliches Angebot; Personenserver und gegebenenfalls Zugangsserver können den Betrag verkleinern. Der erteilte Wert steht im Autorisierungstoken. Der Dienst setzt ihn durch. Den übergeordneten, privaten Rahmen einer Person trägt der Token gerade nicht.

Der Dienst soll eine harte Grenze je Token sicherstellen. Im Vorschlag darf bereits verbrauchter Betrag plus offene Reservierungen für gleichzeitige Anfragen den erteilten Betrag zu keinem Zeitpunkt überschreiten. Gerade bei generierter Ausgabe ist der tatsächliche Preis erst später bekannt. Vor dem Start einer kostenpflichtigen Anfrage braucht der Dienst deshalb einen endlichen Höchstpreis, etwa aus einer angegebenen Ausgabelänge oder einer dokumentierten Voreinstellung. Er reserviert diesen Höchstwert atomar, führt die Anfrage aus, bucht den wirklichen Preis und gibt den Rest frei.

Das kann eine Anfrage abweisen, deren tatsächliche Kosten am Ende möglicherweise gepasst hätten. Ein kleinerer Höchstwert erlaubt einen neuen Versuch. Ein solches Verhalten ist keine Panne des Limits, sondern die Bedingung dafür, dass es vor der Ausgabe wirkt.

Auch personenbezogene Nutzungszähler sieht der Text vor. Sie verwandeln den Dienst aber nicht in die Instanz, die das private Gesamtlimit festlegt. Der Dienst kennt es nicht und soll keine eigene zusätzliche Grenze aus kumulierten Zahlen erfinden. Der Personenserver muss seine aktiven Zuteilungen gegeneinander rechnen. Die Warnung des Entwurfs ist präzise: n gleichzeitig gültige Tokens über je X erlauben bis zu nX Exposition während ihrer Gültigkeit. Das ist eine hypothetische Berechtigungswirkung, kein Bericht über tatsächlich verursachten Schaden. Ein weitergereichter Auftrag an einen Unteragenten übernimmt zudem kein vom Elterntoken automatisch abgebuchtes Teilbudget. Auch sein Token benötigt eine neue, in die Summe einzurechnende Zuteilung.

Die zweite Schwachstelle entsteht nach dem Ausstellen. Ein Agent kann abstürzen, einen Token verwerfen oder ihn beim Erneuern nicht mehr vorlegen. Der Aussteller kennt dann die Genehmigung, aber nicht zwingend die verbrauchte Menge. Nach dem Entwurf muss er die unbekannte Zuteilung vorläufig als vollständig verbraucht behandeln. Ein späterer Verbrauchseintrag aus einer Challenge ist nur eine Momentaufnahme; ein noch gültiger Token kann weiter kosten. Erst eine Nutzungsabfrage, deren Messwert bis zu einem angegebenen Zeitpunkt as_of vollständig ist, kann inzwischen abgelaufene Zuteilungen abrechnen. Bestätigte Sperrung bei der Ressource kann diesen Zeitpunkt vorziehen. Fehlt eine Sperrfunktion oder ist ihr Ergebnis unklar, darf der reservierte Betrag nicht sofort wieder vergeben werden. Bereits laufende Anfragen können enden und Kosten auslösen. Ein Druck auf „Stopp“ ist kein nachträglicher Erlass.

Ein Budget begrenzt ferner die Menge, nicht die Handlung. Eine billige unumkehrbare Operation benötigt weiterhin den passenden Berechtigungsumfang. Bei mehreren Rechnungskonten derselben Person beantwortet der Budgetwert allein auch nicht, welches Konto belastet werden soll. Der vorgeschlagene Antwort-Header AAuth-Budget hilft dem Agenten, Kosten und Restbetrag seines Tokens einzuschätzen; er ist standardmäßig nicht signiert und nicht die Autorisierungsquelle. Eine Signatur der Nutzungsantwort wird empfohlen, nicht verlangt. Sie hält fest, was der Dienst behauptet hat, beweist aber nicht die Ehrlichkeit seines Zählers oder die Richtigkeit einer Rechnung. Die Implementierungshinweise im Entwurf sind Selbstauskünfte; sie wurden für diesen Artikel nicht unabhängig verifiziert. Vom Anbieter selbst bezahlte Agenteninferenz ohne Personenserver in diesem Weg fällt nicht unter die Erweiterung.

Entscheidend ist damit ein Zustandsbild, das kein einzelner Token liefern kann: Welche Zuteilungen sind noch aktiv, welcher Teil des privaten Rahmens ist dafür gebunden, bis wann reicht die letzte vollständige Messung und was hat ein Sperrversuch wirklich beendet? Eine grüne Anzeige für einen einzelnen Agenten kann gleichzeitig wahr und für die Gesamtentscheidung unzureichend sein.

Quellen