Summary

  • 11月1日更新の改訂02は「すべての代理を評価する」という前版の記述を削り、現在の代理とトークンの上位クレームを受付判断の対象にした。
  • 上流の代理が後から停止されても、その履歴だけで受信側が次の呼び出しを拒む規則はない。連結した記録から、仕事が続いたことは事後に分かる。

受付の端末には、依頼が渡ってきた経路が見える。途中の代理が停止された印も付いている。それでも端末が読むべき通行証は最後に来た代理のものだ。Agent Execution Evidence草案の改訂02は、この一見奇妙な運用を、記録と認可を分ける設計として書き直した。

改訂01には受信側がすべての代理を評価するという文があった。著者によると、公開された01は古い作業状態からアップロードされ、意図した修正が入っていなかった。02では、取引の本人と現在の代理に対して受信側の方針を適用し、入れ子のactに載る過去の代理をactor_chainの監査履歴に限定する。これはRFC 8693の第4.1節が定める、トークン上位のクレームと現在の代理だけをアクセス制御に用いる規則に沿う。

履歴の用途は明確だ。草案は呼び出す側と受ける側の双方に記録を残し、後から照合できるようにする。ある上流代理の停止後も仕事が下流へ進んだか、各段階で誰が受け入れ、何をadmission_basisとして記録したかを追える。一方、受信側は過去の代理が停止されたことだけを理由に呼び出しを拒めない、と本文が明記する。照合で分かることと、その場で止められることは同じではない。

しかも受付時の履歴はトークン発行者が主張する経路であり、全経路の網羅性も権限の段階的な縮小も保証しない。入手できた記録同士の整合は確かめられるが、欠けた一段を自動的には見つけられない。現在の呼び出し代理については、保証声明と登録の状態が受信側の求める鮮度を満たす必要があり、制限中なら許された種類の操作に限られる。

第14節は履歴全体に基づく受付を未解決課題として挙げる。完全な経路の証明、信頼する状態情報、RFC 8693との整合を別途決める必要がある。IETFの記録では11月1日更新の個人草案で、採用済みの仕組みではない。判断を変える材料は、上流代理の状態を受付前に調べる規則と、それを実行する具体的なサービスだ。