Summary

  • 10 月 27 日更新的一份 IETF 个人草案提出用 decision.operationKey 标识一项预期操作；真正的重试沿用同一个键，第二项操作另取新键。
  • 草案以 500 英镑上限为例：已花 300 英镑、另有 120 英镑待结。重试不会再扣一次；新付同样的 120 英镑则使承诺总额达到 540 英镑。

第一笔 120 英镑已经得到许可，工具的回复却没回来。代理只好再发一次。此时账本应当看到原来那笔待结款，不能再占一份额度。接着，委托人又下了一笔内容完全相同的付款指令。若账本只看“动作、参数、收款对象”的内容哈希，它会把第二笔真实支出也认成重试。看似省下的额度，其实是被藏起来的承诺。

10 月 27 日的草案修订改用操作键分辨这两种情况。代理给一项打算完成的操作分配 decision.operationKey，在签名请求里带上它；请求失败后的再试继续用原键。另一次独立付款，即使内容一字不差，也必须有自己的键。这个键还与授权上限文件的摘要绑定，使核验者能沿着同一份委托额度追查。

草案自己的数字很直白：上限 50,000 便士，已结算 30,000 便士，一笔 12,000 便士的许可仍处于保留状态。原操作重试时，已花加保留仍是 42,000。新操作再要 12,000，就成了 54,000。旧的第 -01 版用请求摘要认重试，碰到两笔完全一样、但原本就打算分别支付的款项，可能把第二笔漏算。

新版本让每笔待结许可在 held 列表里留下操作键、请求摘要和金额；这些金额之和必须等于保留总额。核验者据此计算是否越过额度。丢失回复也不会让许可凭空消失：只有同一操作的后续记录确认效果发生，金额才转入已消耗；确认没有发生，保留才可释放。

还要看时间顺序。草案要求保存记录的一方比较消费状态的连续版本。如果后一次决策读到过旧版本，漏看先前的待结许可，双重占用额度的窗口就能被找出来。越额许可仍会被记录为越额许可，供之后追责。

IETF 文件页把它列为个人 Internet-Draft，状态为 I-D Exists。这里没有一宗已经发生的支付事故；真正值得追问的是，自动代理替别人花钱时，谁能证明它到底执行了一次意图，还是两次？