Summary

  • 2026年11月1日付の個人インターネット草案は、承認時刻にエージェントのワークロードIDトークンの期限を改めて調べる規則を加えた。
  • 実行用アクセストークンの期限も、そのIDより後にはできない。委任の有効性と実行者の有効性は別の時計で測る。

たとえば、エージェントが別の組織へ支払い指示を運ぶ。受け手は委任と委任者の権限を確かめたが、追加の署名を待つ。署名が届いた時には委任はまだ生きている一方、エージェントのワークロードIDは失効していた。この時に最初の検証結果だけを見て実行を許すなら、誰を通したのかという問いが残る。

Cristian Huleaによる改訂版の草案第10.2節は、承認時刻 A を、義務の履行とアクセストークン発行を行う処理の中で受け手自身の時計から得ると定める。その時点で、委任の連鎖、委任権限を裏付ける声明、選んだ時間枠に加え、ワークロードIDトークン（WIT）の期限を再確認する。条件を満たせなければ拒否する。発行するトークンも、これらの期限と許容寿命のうち最も早いものまでしか使えない。

前の-00版もAでの再確認を求めていた。ただしWITはその項目にも、発行トークンの寿命を決める項目にも入っていなかった。-01版の変更記録は、両方に追加したと明記する。ここで示した支払いは仕組みを説明する仮定であり、実際の銀行事故ではない。

委任状は「何を任せたか」を示す。別の権限声明は「その委任をする権限があったか」を支える。運用者が発行するWITは、特定の識別子と鍵を持つエージェント実体を稼働させていると示す。草案はWITがモデル、設定、振る舞いまで保証するものではないと書く。三つの主張を一つの「承認済み」に丸めれば、どの発行者の時計が止まったか見えなくなる。

先の検証時刻 T の結果は、その時点の記録として残る。承認までに必須の状態証拠が古くなれば、新しい証拠で再検証するか、不確定な結果を方針に従って扱う。今回のWIT追加はさらに、実行者の期限という別の穴を塞ぐ。新たな身分証を用意して確認し直すか、その動作を止めるか。発行したトークンで許される実行は一回だけで、二回目は資源サーバーが拒否する。

IETFの記録にあるのは個人草案である。現場での採用や障害の実績は、この記録からは分からない。