Summary

  • 10月27日の個人提出Internet-Draft改訂案は、一つの意図した操作にdecision.operationKeyを与える。応答を失った後の再試行は同じ鍵、別の支払いは新しい鍵を使う。
  • 草案の例では500ポンドの上限に対し、300ポンドが支払済みで120ポンドが保留中。同じ操作の再試行は合計420ポンドのまま、同額の新しい操作なら540ポンドになる。

経理担当者が「同じ請求書を二枚見た」と言う。AIエージェントの返事が届かず、同じ支払い要求を送り直したのなら一枚目の再送だ。依頼者が同じ相手に同じ額をもう一度払うよう指示したのなら、二枚目は別の約束になる。金額も宛先も一致するが、予算に与える影響は一致しない。

27日付の改訂案は、要求本文のハッシュを操作の身分証にしない。ハッシュが表すのは行為、引数、対象の組み合わせであり、依頼者が何回その行為を望んだかではない。代わりに、一つの予定された操作にdecision.operationKeyを割り当て、署名された要求に載せる。返事を失って再送しても鍵は変わらない。新しい支払いには、たとえ要求内容が同じでも別の鍵を与える。

この変更は前の第01版の弱点を狙う。そこでは要求のダイジェストで再試行を判定していた。二件の同額支払いが同じ内容なら、後の一件まで既存の保留分に見えてしまう。監査の節約術としては、かなり高くつく。

草案が示す数字は明快だ。委任された上限は5万ペンス。すでに3万ペンスが確定し、1万2000ペンスの許可が結果待ちで保留されている。同じ鍵で再試行する場合、使用済みと保留の合計は4万2000ペンス。別の鍵による新たな1万2000ペンスの要求なら5万4000ペンスとなり、上限を超える。新案では保留中の各許可に操作鍵、要求ダイジェスト、金額を記し、保留総額との整合も確かめる。

返答がなかったことは、支払いが起きなかった証拠にはならない。許可は、同じ操作について効果が発生したか、発生しなかったかを示す記録が来るまで保留のままだ。記録を保持する側は状態の改訂番号も追い、先の保留を見落とした古い残高で次の許可を出していないか調べる。超過した許可は記録から消さず、超過として読めるようにする。

IETFの文書情報では、この文書はまだ個人提出のInternet-Draftで、状態はI-D Exists。提案の核心は小さな欄の追加に見える。実際には、誰かの予算で動く代理人が「同じ文面」を「同じ意思」と取り違えないための欄だ。