摘要

  • IETF 一份个人草案新增了小额日常订单案例：代理单笔最多花30美元，一天总计最多100美元，活动横跨餐食、出行和家居服务。案例中的38美元车程先等用户批准例外。
  • 三家独立收银台各知道自己的订单，却不会天然知道彼此花了多少。草案指出，跨服务总额、整个授权的撤销，以及在实际成交时执行限额，仍缺互通规则。

三家店的收银机，谁装那只总表？

周一早晨，Dave 给助手一张当天的采购许可：每单不超过30美元，全天不超过100美元。助手先订24美元晚饭，又想订38美元车程，接着买18美元家用品。车程超出单笔限额，要等 Dave 专门批准；到了午夜，许可自动到期。这是新修订的代理授权案例草案编写的情境，并非真实商家的订单报告。它把问题说得很像日常购物：每家店都会算自己的钱，但谁来算这个助手一整天的钱？

10月27日的公告和IETF 文件记录把修订版 05 列为个人 Internet-Draft，没有 RFC 轨道或 IETF 背书。修订版 04还没有这个“每日小额订单”案例。作者给它起了一个听起来很省事的名字：摊销式同意。用户早上完成一次较强的身份确认，此后代理在固定时间和限额里自行处理小事，不必每买一份晚饭就来敲一次门。

省掉敲门，账就得算得更清楚。外卖平台可以核对24美元是否低于单笔30美元。出行平台也能看出38美元超线。但家居商家只看自己的18美元订单，无法从本地收据推断外卖和出行平台已经接了多少。全天100美元这个数字，需要各服务识别同一份授权，还需要一个可信的累计状态，告诉下一家店成交前还有多少可用额度。哪些订单算“已花”？下单、接受、扣款、取消分别怎么记？草案提出了限制，却没有给出已完成的跨商家共享计数协议。

不只是两个数字，还有四道门

新案例要求授权能区分读取选项、拟好订单、发送订单和真正花钱，也要限定可用的应用。代理不得自己扩大权力或延长期限。授权必须有明确到期时间；用户应能一次撤销整份授权及其派生权限。每个动作还必须能以密码学方式归到当天那份具体授权。否则，商家拿着一个看似有效的令牌，却不知道它是在消费哪一天、哪一笔人的决定。

作者逐项盘点 OAuth 已有零件：授权码流程可建立最初授权，Rich Authorization Requests 可表达结构化要求，DPoP 可把令牌绑到使用者，令牌撤销可停掉单个令牌。卡住的恰是组合后的承诺：没有统一的累计支出语义，没有标准的“把整份授权及所有派生令牌一起关掉”，也没有互通路径让独立商家在实际执行时读懂同一套限额。三个系统都验出“令牌有效”，仍可能对“今天还剩多少”给不出共同答案。

38美元车程检验的是单笔上限，跟100美元日总额是两条不同的线。案例把它暂停，交给 Dave 对例外做明确决定。批准对象应是这次车程、这个价格、这份授权，而不是把“允许叫车”一口气放宽。午夜到期同样不能只关掉用户看见的一个按钮：餐食、出行和家居三个服务手中的派生凭证都必须一起失效。订单与授权的关联记录，才让日后的信用卡账单和助手的解释能够逐笔对上。

原始文件