Agentenberechtigung: zwei Bücher, 250 Pfund Rechnung

Summary

Ein individueller IETF-Entwurf lässt einen Auftraggeber ein Ausgabenlimit für einen Softwareagenten signieren. Im eigenen Beispiel meldet die Prüfung 230 Pfund Ausgaben gegen ein Limit von 200 Pfund.
Dieselbe Prüfung rechnet innerhalb eines einzigen Protokolls. Werden 125 Pfund in jedem von zwei getrennten Protokollen verbucht, können beide grün melden, während der Auftraggeber insgesamt 250 Pfund bezahlt.

Zwei grüne Häkchen für eine rote Rechnung

Der Auftraggeber gibt seinem Agenten Geld für Büromaterial. In der Beispielberechtigung des Entwurfs stehen 200 Pfund als Gesamtsumme und 100 Pfund je Bestellung. Jede Bestellung braucht die Gegensignatur des Lieferanten; oberhalb von 60 Pfund muss der Auftraggeber zusätzlich genau diese Bestellung genehmigen. Vier Einträge über 45, 80, 25 und 80 Pfund ergeben 230 Pfund. Der Prüfer findet die Überschreitung und eine fehlende Zustimmung. Für ein einziges Protokoll ist die Buchführung klar.

Nun teilen sich zwei Einkaufsstellen dieselbe signierte Berechtigung. Jede führt ihr eigenes Protokoll und verbucht 125 Pfund. Die nötigen Zustimmungen und Gegensignaturen liegen in beiden vor. Jeder lokale Prüfer sieht 125 von erlaubten 200 Pfund und bestätigt seinen Teil. Zusammen sind es 250 Pfund. Das ist eine aus der Regel des Entwurfs konstruierte Rechnung, kein dokumentierter Einkauf. Der Entwurf benennt die Grenze selbst: Summen, Stückzahlen und Zeitfenster werden innerhalb eines Protokolls geprüft; Belege derselben Berechtigung aus mehreren Protokollen werden nicht zusammengezählt.

Der Fehler braucht weder gefälschte Schlüssel noch einen böswilligen Lieferanten. Der Auftraggeber kann den Betrag von 200 Pfund korrekt signiert haben. Beide Agenten können ihre Handlungen korrekt signiert haben. Selbst zwei tadellos geführte Protokolle beantworten die falsche Frage, wenn die Rechnung über beide läuft. Wer verkauft die beiden lokalen Ergebnisse als Einhaltung eines gemeinsamen Limits, beansprucht eine Übersicht, die seine Prüfer nie hatten.

Was Izmaylov tatsächlich vorgeschlagen hat

Pavel Izmaylov veröffentlichte die Fassung 01 am 24. Oktober 2026. Das IETF-Datatracker-Profil führt sie als individuellen Internet-Draft ohne zuständigen Area Director oder förmlichen IETF-Stream. Der Vorschlag ist präzise genug, um geprüft zu werden: Der Auftraggeber signiert mit einem Passkey eine maschinenlesbare Berechtigung. Sie kann Gesamtsummen, Einzelbeträge, Anzahl und rollierende Zeiträume begrenzen. Der Agent signiert für jede Handlung eine Quittung. Ein Protokollführer ordnet die Quittungen in einen Baum mit signierten Köpfen und Zeitstempeln ein; ein Dritter kann die erhaltenen Unterlagen später offline nachrechnen.

Die neue Fassung verschärft einige Annahmeregeln des Prüfers. Anhang C sagt zugleich, dass die Bytes der Datensätze gegenüber Fassung 00 unverändert bleiben. Strengere Regeln für Feldnamen, Schlüsselcodierung und Signaturlängen machen einen Eintrag verlässlicher lesbar. Sie öffnen keinen Blick in ein zweites Buch.

Vor allem beschreibt der Entwurf kein Vollzugsorgan, das eine Bestellung vor ihrer Wirksamkeit ablehnt. Die Prüfung folgt der Handlung. Im Beispiel fällt der Wert von 230 Pfund auf, nachdem die Bestellung eingetragen wurde, die ihn erzeugt hat. Der Befund kann einen Streit entscheiden oder eine Abrechnung korrigieren. Eine echte Sperre am Einkaufspunkt müsste den gemeinsamen Restbetrag schon vor der Annahme reservieren und bei gleichzeitig eintreffenden Aufträgen, Wiederholungen und Netzausfällen genau eine Entscheidung treffen.

Auch die Unterschriften haben unterschiedliche Aufgaben. Die Gegensignatur belegt, dass jemand mit dem benannten Lieferantenschlüssel den konkreten Beleg unterschrieb. Der Entwurf warnt davor, daraus ohne Weiteres die reale Identität des Schlüsselinhabers abzuleiten. Eine zusätzliche Zustimmung des Auftraggebers bindet eine bestimmte Handlung. Ein signierter Baumkopf bindet den erfassten Verlauf eines Protokolls. Keine dieser Signaturen zählt automatisch, was ein zweiter Protokollführer schon aus derselben Kasse genommen hat.

Die Integrität eines Baumes ist kein gemeinsames Konto

Der Entwurf nutzt den Merkle-Baum nach RFC 9162. Ein Konsistenzbeweis kann zeigen, dass ein Baum durch Anhängen gewachsen ist, statt seine frühere Geschichte auszutauschen. Bewahrt ein unabhängiger Zeuge einen signierten Kopf, wird eine spätere Kürzung des von ihm gesehenen Verlaufs erkennbar. Das ist wertvoll, wenn jemand den Inhalt eines bestimmten Buches bestreitet. Ein zweites, ebenfalls sauberes Buch bleibt außerhalb dieses Beweises.

Der Sicherheitsabschnitt nennt außerdem abgeschnittene Protokolle und voneinander getrennte Ansichten, zwischen denen kein definierter Konsistenzbeweis besteht. Der Fall mit zweimal 125 Pfund ist noch unbequemer: Niemand muss etwas löschen oder unterschiedliche Geschichten vorspielen. Zwei vollständige, ehrliche Bücher können eine zu hohe Gesamtrechnung begleiten. Die Lücke liegt im Geltungsbereich des Rechenwerks, nicht in der Schönheit seiner Kryptografie.

Im Implementierungsabschnitt stehen zwei Bibliotheken des Autors selbst. Für die Python-Bibliothek fehlt demnach noch die Prüfung einer SLH-DSA-Signatur am Baumkopf; außerdem ist ein Problem mit einem Zeitstempelattribut vermerkt. Eine unabhängige Implementierung ist dort nicht bekannt. Was die Bewertung ändern würde, ist ein öffentlicher Test mit einer Berechtigung an zwei gleichzeitig aktiven Protokollführern: Wird die zweite Ausgabe abgewiesen, und kann ein unabhängiger Prüfer den gesamten Verbrauch rekonstruieren?

Auch die Prüfung wiederverwendeter Kennungen bleibt laut Sicherheitsabschnitt auf ein Protokoll begrenzt. Ein Betreiber kann also nicht zuerst mit eindeutigen Belegnummern in Buch A werben und anschließend unterstellen, Buch B habe dieselben Nummern oder dieselbe Gesamtsumme mitgeprüft. Diese Grenze muss im Kaufvertrag und im Prüfbericht beim Namen stehen: Welcher Protokollführer erfasst welche Agentenhandlung, und wer führt die beiden Mengen zu einer verbindlichen Rechnung zusammen? Eine Passkey-Unterschrift belegt zudem nicht, dass der Auftraggeber jede angezeigte Bedingung gelesen hat; auch das sagt der Entwurf ausdrücklich.