Summary

  • Die Fassung vom 27. Oktober eines individuell eingereichten Internet-Drafts ergänzt decision.operationKey: Wiederholte Versuche derselben beabsichtigten Zahlung behalten den Schlüssel, eine neue Zahlung erhält einen anderen.
  • Im Rechenbeispiel sind von einem Limit von 500 Pfund bereits 300 verbraucht und 120 reserviert. Ein echter erneuter Versuch bleibt bei 420; ein weiterer Auftrag über 120 würde 540 erreichen.

Zwei identische Zahlungsaufträge liegen auf dem Tisch. Beim ersten ist die Antwort des Werkzeugs verloren gegangen, weshalb der Agent ihn erneut absendet. Der zweite ist eine neue Anweisung des Auftraggebers über denselben Betrag an dasselbe Ziel. Wer nur den Inhalt der Nachrichten vergleicht, findet keinen Unterschied. Wer das Budget verantwortet, muss einen finden: Die eine Nachricht berührt eine bestehende Reservierung, die andere verlangt eine weitere.

Genau dort setzt die überarbeitete Entwurfsfassung an. Sie bindet eine Kennung an die beabsichtigte Operation und nimmt decision.operationKey in die signierte Anfrage auf. Geht eine Antwort verloren, trägt der nächste Versuch denselben Schlüssel. Für eine zweite, selbstständige Zahlung braucht es einen neuen, selbst wenn Aktion, Parameter und Ressource unverändert sind. Der Schlüssel wird innerhalb des durch limitDigest bestimmten delegierten Ausgabenlimits gelesen.

Der Vorgängertext erkannte Wiederholungen am Digest der Anfrage. Ein solcher Digest beschreibt den Inhalt. Er kann daher bei zwei getrennt gewünschten, aber identisch formulierten Zahlungen gleich sein. Die neue Fassung benennt diesen Fehler ausdrücklich: Der zweite Auftrag könnte als Wiederholung gelten und aus der Rechnung fallen. Das Kassenbuch hätte dann eine sehr originelle Art zu sparen.

Das Beispiel des Autors arbeitet mit Pence. Das Limit beträgt 50.000, davon sind 30.000 bereits ausgegeben. Eine Genehmigung über 12.000 ist noch reserviert, weil ihre Antwort fehlt. Wiederholt der Agent genau diese Operation, bleiben 42.000 ausgegeben oder gebunden. Kommt dagegen ein weiterer Auftrag über 12.000 mit anderem Operationsschlüssel, steigt die Summe auf 54.000 und überschreitet das Limit. Der gleiche Anfrage-Digest ändert an dieser Rechnung nichts.

Für jede offene Genehmigung schreibt der Vorschlag Operationsschlüssel, Anfrage-Digest und Betrag in die Liste held; ihre Beträge müssen mit dem reservierten Gesamtbetrag übereinstimmen. Ein Prüfer berechnet withinLimit aus dem verbrauchten, reservierten und neu angeforderten Betrag. Eine echte Wiederholung, deren Schlüssel schon in held steht, wird nicht doppelt gezählt. Eine Entscheidung jenseits des Limits bleibt als solche im Datensatz sichtbar, auch wenn die Entscheidungsstelle sie trotzdem erlaubt hat.

Die fehlende Antwort beendet keine Reservierung. Erst ein späterer Datensatz derselben Operation kann den Effekt als eingetreten bestätigen und den Betrag zu „verbraucht“ verschieben oder sein Ausbleiben belegen und die Reservierung freigeben. Über mehrere Datensätze hinweg lässt sich außerdem feststellen, ob eine spätere Entscheidung einen veralteten Zustandsstand gelesen und eine offene Genehmigung übersehen hat.

Der IETF-Datatracker führt das Dokument als individuellen Internet-Draft mit dem Status I-D Exists. Seine nüchterne Erkenntnis ist praktisch: Eine Kopie des Auftrags ist noch keine Kopie des Willens, der ihn ausgelöst hat.