エージェントの支出許可：二冊の合格帳簿と250ポンドの請求

Summary

個人提出の IETF 草案は、本人がパスキーで代理人の支出上限を署名し、後から行動記録と突き合わせる仕組みを示す。例では総額200ポンドの許可に対し、単一ログが230ポンドに達すると超過が検出される。
同じ許可が二つのログで使われた場合、草案の検証器は両者を合算しない。それぞれが上限内でも、本人が負う合計額は上限を超え得る。

200ポンドの財布が二冊に分かれる

オフィスの備品を買う代理人を想像してほしい。10月24日の草案が置く許可は、総額200ポンド、一回100ポンドまで。すべての注文に供給者の副署が要り、60ポンドを超える注文には本人の個別承認も要る。本文の例は45、80、25、80ポンドの注文を一冊のログへ積み、計230ポンドとなる。検証器は上限超過と承認欠落を報告する。署名も計算も同じ冊子を見ている限り、筋の通った結果だ。

では同じ許可を二つの記録者へ渡す。それぞれのログに、必要な承認と副署を備えた125ポンドの注文が残る。片方ずつ検証すれば、どちらも200ポンド以下である。本人に請求される合計は250ポンドだ。これは文書の規則から組み立てた計算例で、実際の事故を示すものではない。草案のセキュリティ節は、合計額、件数、期間制限、識別子の重複を一つのログ内で判定し、同じ許可の記録が二冊に分かれれば合算しないと明記している。

上限に本人の本物の署名があっても、それだけで支出は止まらない。代理人の署名は行動を記した受領記録を結び、供給者の副署は特定の注文に別の鍵を加える。二つの執行点が同時に使う残高を誰が持つかは、まだ決まっていない。本人の「総額」と検証器の「このログの小計」が同じ語で売られるとき、帳簿の境界が授権の範囲を勝手に変えてしまう。

事後検証の得意分野

Pavel Izmaylov の第01版は個人 Internet-Draft であり、IETF Datatrackerには採択された作業部会や担当のエリアディレクターが載っていない。提案そのものは詳細だ。本人がパスキーで許可を署名し、総額、単発額、回数、移動時間枠の制限を入れる。代理人は行動ごとの受領記録を署名する。記録者は署名された木の根と時刻証明を添え、第三者が渡された材料をオフラインで検査できるようにする。

第00版から第01版への変更も無視できない。付録Cによれば、記録のバイト列は変えていないが、鍵の表現、署名長、予約された項目名などについて検証器の拒否条件を厳しくした。同じ紙をより厳しい目で読む改訂である。しかし一冊の紙しか持たない検証器に、隣の紙の支出は見えない。

文書は、実行前に注文を拒む執行器を規定していない。例の230ポンドが検出されるのは、その額を作った注文の記録がそろった後だ。事後の報告は違反を示し、紛争や改善の材料になる。購買を止めるには別の制御が必要だ。支出の予約を一つの残高で直列化し、再試行、遅延応答、別地域からの同時要求に対しても、次の一件を拒否できなければならない。

副署が証明する範囲も狭い。草案は、供給者に指定された鍵の保持者が署名したことと、その保持者の現実の身元を区別する。本人の承認は閾値を超えた特定の行動へ向く。木の根は受け取った履歴の改変を検出する助けとなる。実際に品物が納入されたことや、他のログで残高がいくら使われたかは、別の記録と照合が要る。強い部品を並べても、部品が問われていない計算は生まれない。

一本の木は隣の木を数えない

提案は RFC 9162 の Merkle 木を使う。記録者の外に保管された署名済みの木の根があれば、覆われた履歴の後日改変や切り詰めを見つけやすい。整合性証明は、一つの木が以前の葉を変えずに伸びたことを示す。これは重要な証拠だ。ただし二本の木がそれぞれ整合していても、両方が同じ200ポンドの許可を使ったか、その合計がいくらかは計算されない。

草案は末尾の根を外部保管者なしで消せる問題や、記録者が異なる相手に分岐した履歴を見せられる問題も挙げる。これらは過去の見え方をめぐる危険である。二冊の125ポンドはもっと単純だ。改変も切除もなく、両方の記録が完全でも、局所的な判定は二回とも緑になる。足りないのは暗号の強度ではなく、何をひとつの支出として数えるかという契約だ。

実装状況の欄には、同じ作者による JavaScript と Python のライブラリが載る。Python 版では木の根に使う SLH-DSA 署名の検査がまだなく、時刻証明の属性処理にも既知の問題がある。独立実装は確認されていない。評価を変える事実は明確である。同じ許可を二つの記録者に同時投入し、共有残高で超過を拒否したうえで、第三者が全受領記録を再計算できる試験結果だ。