要約

  • 2026年9月28日に提出されたAAuth-R3の初版は個人Internet-Draftであり、RFCでもIETFの採用決定でもない。第10.4節は、実行自体に外部の結果がない保留中の呼び出しについて、先に計算して結果の開示だけを後で承認する道を提案する。
  • その場合、画面は操作が既に行われたと明記しなければならない。資源側は実際の件数や機微な項目の種類を知ってから、どんな結果を渡すかを提示できる。
  • 実行によって監査記録、利用量、料金、回数制限、第三者への呼び出しが動くなら、承認は実行より前に必要だ。「読み取り専用」という名前だけでは条件を満たさない。

承認画面に残った仕事

エージェントが従業員のデータを求めたとする。資源側は照会を実行し、給与や住所を含む回答を得たが、送信せず保持している。利用者が今決めるのは照会の開始ではなく、その回答をエージェントへ開示してよいかどうかだ。AAuth-R3の初版はこの二つの行為を分ける。承認画面が「実行前」と思わせるなら、利用者は自分の権限を誤認する。

先に計算すると、資源側だけが知り得た事実を承認材料にできる。検索文からは、十件が返るのか大量の記録が返るのか、機微な列が含まれるのか分からない。草案の単一呼び出し提案では、既に実行した場合に限って任意のresult欄で件数や種類を記述する。実データを提案に載せるわけではない。どの説明を人に見せ、どの出力を隠すかは資源側が選ぶため、説明が乏しければ承認は依然として弱い。

ただし、「先に計算」は何にでも使える抜け道ではない。呼び出し自体がアクセスログに記録され、課金や使用枠を消費し、別の相手を動かすなら、その時点で結果以外が変わる。後から開示を拒否しても、料金や通知は取り消せない。草案はそのような実行を承認前に行うことを禁じる。判断基準はAPIの動詞ではなく、走らせた瞬間に回答の外側で何が変わるかだ。

保留した呼び出しを何に結び付けるか

Datatrackerの現行記録は-00を個人提出のI-D Existsとして示す。Standards Trackという表記は意図する進路で、承認済みという意味ではない。草案は一回の操作と具体的な引数を提案文書に記し、トークンはr3_uriとr3_s256でその文書を参照する。HTTP 202で呼び出しを保持する経路では、エージェントが引数を作り直さない。401で再試行させる経路では、資源側が実際の引数と承認された提案を照合し、ダイジェストで表した値なら同一バイト列を確認する。一つの許可で二回実行することも認めない。

結果を先に固定できるのは前述の厳しい条件を満たす場合だけである。そのとき人は、後で別の照会が返すかもしれない回答ではなく、既に存在する回答の受け渡しを承認する。だがトークンが提案を正しく結び付けても、資源側が結果の機微性を十分に説明したかは別の問題だ。草案は実サービスの導入例や試験結果を示していない。本稿は提案の統治上の境界を読むものであり、既存のAAuth予算やイベント配送の記事を繰り返すものではない。

出典