Summary

  • An individual IETF proposal lets a person sign an agent's spending limits and lets an offline verifier compare action receipts with those limits. Its sample permission caps supply orders at GBP 200; the sample log flags a GBP 230 total.
  • The proposal checks a budget inside one log. Put receipts under the same permission in two logs and it adds neither ledger to the other. Two histories can each pass while the combined spend breaks the person's limit.

Two ledgers, one wallet

The draft's sample office agent may order up to GBP 200 in supplies, no more than GBP 100 per order. Its principal must approve orders above GBP 60, and the supplier must countersign every order. The sample log reaches GBP 230. The verifier catches the excess, along with a missing approval. That is the easy demonstration: one wallet, one ledger, one arithmetic result.

Now give the same permission to two recorders. Let each ledger contain GBP 125 of correctly approved and countersigned orders. Each verifier reports a total below GBP 200. The principal has still been charged GBP 250 across the pair. These orders are a constructed illustration of the draft's explicit rule, not a reported incident. The Security Considerations state the rule plainly: totals, counts, period limits and duplicate identifiers hold within one log; receipts for one permission in two logs are not added together. The budget is global in the person's head and local in the verifier's arithmetic.

That gap is the story of a signature being asked to do a ledger's job. A passkey can bind a person to an exact GBP 200 limit. An agent's signed receipt can bind a claimed action to that permission. A supplier's countersignature can add another party's key to a particular order record. None of those signatures decides which other logs must be included when the budget is totaled. The missing decision is administrative and operational: who owns the authoritative spend domain, and which actor must refuse the next order when the combined balance is gone?

What the proposal actually checks

Pavel Izmaylov's revision 01, posted on 24 October 2026, is an individual Internet-Draft. The IETF Datatracker lists no adopted stream or responsible area director. The proposed records are specific. A principal signs a permission with a passkey. Its constraints can cover totals, per-action amounts, action counts and rolling periods. The agent signs each action receipt; a recorder places the entries in a log with signed tree heads and timestamps. A later verifier can work offline from the records it receives.

The author revised the draft with unusual attention to verifier behavior. Appendix C says record bytes did not change between revisions 00 and 01, but some records that an earlier verifier accepted now fail stricter key, signature-length and field checks. The security section also explains what another party would need to retain to expose an unwritten receipt. Those are real improvements to record interpretation. The two-ledger total remains a separate unsolved count.

The proposal describes its output as a retrospective finding. It specifies no executor that refuses an action before it takes effect. In the example, the GBP 230 log is excellent evidence that the allowance was exceeded; the order that took the total to GBP 230 has already entered the record. A later warning may help a dispute, recovery or change to the process. It cannot unplace the order. An operator selling this as a spending brake would need another mechanism at the point of action.

A perfect proof of the wrong total

The log borrows Merkle-tree machinery from RFC 9162. A signed head held outside the recorder can make later rewriting or truncation of the covered history visible. RFC 9162's consistency proof establishes the append-only property of a tree. That is valuable when one history is contested. It does not tell a verifier that a second, separately kept history used the same spending permission. A proof that ledger A was not rewritten says nothing about ledger B's unspent allowance.

There are two related ways a record keeper can exploit the boundary. The draft warns that a trailing head can be removed if nobody else holds it, and that a recorder can keep two views without a defined consistency proof linking them. More basic here is the accounting problem even when both logs are honestly preserved: neither local verifier sums the other's receipts. Shared permission identity gives an auditor a clue to search, but the specification supplies no cross-log aggregation rule or atomic reservation service. The danger is not a broken hash. It is a missing denominator.

The draft's own implementation table keeps the claim proportionate. It lists JavaScript and Python libraries by the same author, notes a missing Python check for the tree head's SLH-DSA signature and a timestamp-attribute issue, and reports no known independent implementation. A procurement team can inspect those artifacts. It cannot infer from them that a multi-recorder budget has been tested under contention.

The authority question hidden in accounting

A buyer should ask for a diagram with a boring answer: where is the one balance? If an agent can call two suppliers, two regions or two executors, the permission identifier must reach a common spend state before either side commits a consequential action. A later auditor needs the joined receipt set, a record of reservations and the outcome of each attempted order. If an operation is retried after a timeout, the record must show whether its charge was reserved, committed or released. A number written in a signed permission is a policy input; the budget exists operationally where those transitions are serialized.

The strongest version of this proposal's evidence would still be useful. A signed GBP 200 limit gives the principal's exact instruction; linked receipts and independent heads make the submitted history easier to challenge; supplier-side records can contradict a self-serving agent log. These pieces let a verifier say precisely which record was checked. The practical purchasing test is to give one permission to two independent recorders and run orders until their local sums diverge from the shared total.

If the system refuses the excess at the common spend point and later yields a reconciled receipt set, the missing governance edge has become an operating control.

Sources