Summary

  • A new individual IETF draft case lets one agent spend at most $30 on any order and $100 across a day of food, travel and household purchases. Its $38 ride waits for a human exception; the illustrative grant ends at midnight.
  • Three independent checkouts cannot enforce one cumulative promise by inspecting only their own receipts. The draft identifies missing common spend-cap rules, grant-wide revocation and an execution-time path from the grant to each service.

A Budget With Three Cash Registers

In the draft’s example, a person gives an assistant a $100 daily budget. The agent can order dinner, arrange travel and buy household supplies, so long as each purchase stays under $30. It spends $24 on dinner, asks for a $38 ride and buys $18 of supplies. The ride hits the per-purchase stop and needs a human exception. That sequence is an invented use case in a revised OAuth agent-authorization draft, not a report from three merchants. It makes the real design problem vivid: each cash register knows its own sale. Who knows what the agent has spent for the day?

The 27 October announcement and IETF Datatracker identify revision 05 as an individual Internet-Draft without IETF endorsement or an RFC stream. The authors added “Daily Small-Amount Orders” to a wider catalogue of authorization situations. Revision 04 has no such case. The new example calls this one upfront approval for a bounded day “amortized consent”: the person authenticates once, then the assistant works within fixed limits without interrupting them for every $18 purchase.

That bargain sounds simple until the agent leaves the first service. A food provider can check the $24 meal against a $30 per-order maximum. A ride provider can reject or hold a $38 trip against the same rule. The $100 total is different. The household supplier cannot know whether another service has already accepted $24, $75 or $99 unless all three can recognize the same grant and learn a trustworthy total. A number shown on a consent screen is not an enforcement system. It needs a common identity for the authorization, a rule for what counts as spend, and a state the independent services can consult or update before an effect is committed.

The Draft's Shopping List for Authority

The case asks for more than two amounts. The grant must distinguish reading options, drafting an order, sending it and spending money. It must limit which applications can be used, set a compulsory expiration, prohibit the agent from widening or extending its own permissions, and let the person revoke the whole grant and everything issued under it in one action. Each execution must be cryptographically attributable to that exact grant. Otherwise the checkout may know an agent has a token without knowing which daily promise it is consuming.

The authors map some pieces to existing OAuth machinery: an authorization-code flow can establish the initial grant; Rich Authorization Requests can carry structured details; DPoP can bind a token to its presenter; token revocation can kill a token. Their gap analysis says the package still lacks standard meanings for spending caps, a grant-wide stop command and an interoperable path from the promised bounds to the services that commit the orders. The draft describes requirements. It does not specify a working cross-merchant meter or show measurements from one.

The $38 ride illustrates why exceptions cannot hide in accounting. It exceeds the $30 transaction cap before the daily $100 is at issue. The draft holds it for Dave's explicit approval. A real design has to name the object of that approval: this ride, at this amount, under this grant, before the service charges. A casual “allow rides” would change the authority for many future trips. The draft's immutable-boundary requirement gives the agent no right to enlarge its own grant. The human exception is a separate decision, not a friendly rewrite by the assistant.

Midnight brings a second boundary. The example says the day's grant expires automatically, and the person must be able to revoke it earlier with one immediate action. A token minted for the food app and another minted for the ride app must both lose the authority of that same grant. Deleting one visible connection while an untracked derived token survives would make the user's stop button a piece of decoration. Attribution matters here for a second reason: it lets a later card statement and an agent's explanation be compared with the grant that actually authorized each order.

Original records