エージェントの一日上限を三つの店で守れるか

要約

IETFの個人草案に新たに加わった例では、エージェントは一件30ドル、一日合計100ドルまで、食事、移動、日用品を買える。38ドルの乗車は一件の上限を超え、本人の例外承認を待つ。
店ごとのレジには他店の支出が見えない。草案は共通の支出上限、許可全体の取り消し、各店での実行時検査に通用する標準的な仕組みが足りないと指摘する。

レジは三台、財布は一つ

夕食が24ドル。次の車が38ドル。日用品が18ドル。運転を任されたエージェントがこの順に動くと、車の予約だけは一件30ドルの線に引っ掛かる。朝に決めた一日100ドルの線とは別の問題だ。これは改訂されたエージェント認可の草案が作った例で、実際の売上記録ではない。人が朝一度だけ許可し、細かな買い物は毎回呼び出されずに済む。その代わり、三つの店の誰が一日の合計を数えるのか。

10月27日の公開通知は版05を告知した。IETFの文書記録ではRFC系列に入っていない個人Internet-Draftである。版04には、この「日々の少額注文」はなかった。著者らは、強い本人確認を最初に一度行い、決められた期間だけ自律的に動かすことを「償却された同意」と呼ぶ。毎回「夕食を買っていい？」と聞かない便利さは、一つの許可を複数サービスが同じ意味で扱う仕事を生む。

各店が扱いやすいのは一件の上限だ。食事の24ドルは30ドル以下。車の38ドルは超えるので、例ではDaveの明示的な例外承認を待つ。難しいのは一日100ドルだ。日用品店は自店の18ドルを知っても、食事店が先に何を受け付けたかは分からない。許可の識別子、既に使った額、次の注文を確定する時点が共有されなければ、100という表示は各店の判断材料にならない。キャンセルした注文をいつ戻すかも、誰かが定義しなければならない。

取り消しボタンは一つで全部に届くか

この例は金額だけを並べていない。選択肢を読む、注文を下書きする、送る、支払うという行動を分け、使えるアプリも限定する。エージェントは自分で許可を広げたり延ばしたりできない。期限は必須で、本人は許可全体とそこから生じた権限を一度に取り消せる必要がある。各行動を、どの許可に基づくか暗号学的に結び付けることも求める。個々のトークンが有効でも、月曜朝の一つの約束に結び付かなければ、一日分の停止命令は届かない。

草案は既存のOAuthの道具も挙げる。認可コードは最初の許可、Rich Authorization Requestsは構造化された条件、DPoPは提示者へのトークンの結び付け、トークンの失効は個々の停止に役立つ。それでも著者らは、金額上限の共通の意味、許可全体を終える操作、独立した店に条件を運んで実行時に守らせる経路が標準化されていないと整理する。この文章は課題の一覧であり、三店で使える完成した会計機を仕様化したものではない。

車の38ドルを承認する際も、単に「移動を許可」にしてしまえば別の旅行まで開いてしまう。例外はその乗車、その金額、その日の許可に結び付く必要がある。午前零時の期限と早期の取り消しは、食事、移動、日用品のそれぞれに渡った派生トークンを閉じなければ意味がない。後からカード明細を見てエージェントに説明させるなら、各注文と許可、例外、実行結果を照合できる記録が必要だ。