要約

  • 2026年9月28日付の個人Internet-Draft初版 AAuth Events は、リソースからの署名付きイベントを常時到達可能なAgent Provider（AP）に渡す仕組みを提案する。
  • APのHTTP 202は受理したイベントを永続的に記録した後でしか返せない。一方、APからエージェントへの配送方式は草案の対象外であり、受理は本人の確認や行動を証明しない。

スマートフォン上のエージェントが休止し、企業のワークロードも外部からの着信を受けない。そんなときリソースが後から知らせたい変更をどう届けるか。Dick Hardtの AAuth Events は、その最初の宛先として常時稼働するAPを置く。到達性に関する現実的な提案である。ただし、APという受信箱に入った瞬間にエージェントが起きたわけではない。草案を運用上の「通知完了保証」と読むなら、最も重要な一段を飛ばしてしまう。

本文書は2026年9月28日付の -00 版で、著者個人によるInternet-Draftだ。将来のStandards Trackを想定していても、現時点で承認済みRFCやIETF全体の合意ではない。Datatrackerで草案の存在を確認できることと、実装の配送成績が検証されたことも違う。親に当たるAAuthプロトコル草案は、人に代わってエージェントがリソースを利用する際の認可を扱う。今回の拡張が狙うのは、その場の要求応答を終えた後に起きる非同期の出来事である。

エージェントはリソースのイベントを購読し、リソースは発生したイベントの署名付きトークンと本文をAPに送る。APはリソースの署名、宛先を示すaudience、有効な購読、本文と body_s256 の一致を確かめる。発行者とイベント識別子の組で重複を見分けることもできる。これらは偽の投稿や本文のすり替えを第一段階で抑えるための条件である。しかし、エージェントがオンラインか、端末が通知を表示したか、ローカルの作業に結び付いたかは、ここからは分からない。

APには明確な責務がある。受け入れたイベントを後の配送に向けて永続的に記録する前に 202 Accepted を返してはならない。単なる一時メモリへの投入を成功と呼ばせない点は重要だ。リソースは、少なくとも常時稼働する相手が保管を引き受けたと判断できる。だが、APからエージェントへの最後の経路はプラットフォーム依存で、草案の範囲外に置かれている。標準化された共通のプッシュ方式、端末側の受領証、再試行間隔、端から端までの配送時間はここから生まれない。

受け皿が正しく働いても、期限の問題は残る。イベントのJWTには有効期限がある。エージェントは後から受け取ったときに、トークンの有効性、宛先、本文のハッシュと自らの文脈を確認し、期限切れや不正な本文を根拠に行動してはならない。例えば短時間だけ有効な予約枠の知らせがAPに保存され、端末が翌朝起動したとする。保存記録は完全でも、そのイベントに基づく行動は認められないかもしれない。これは設計を説明する仮定であり、実際の障害事例ではない。保存できたという事実は、意思決定の時間を延ばさない。

body_s256 が守るのも、内容の一致という限られた領域だ。草案は、APによる本文の改変や差し替えを検出できる一方、APがイベントを隠したり遅らせたりすることは防げないと記す。意図的な妨害がなくても、混雑したキューや起動しない端末には同じ時差が生じる。内容が正しいこと、間に合ったこと、エージェントが妥当と認めたこと、そして実際に処理したことを一つの緑色の印にまとめてはいけない。特に期限つきイベントでは、どの段階で時計が進んでいたかが結果を左右する。

さらにAPは単なる透明な郵便受けではない。購読とイベントのトークンから、エージェントがどのリソースと関係しているかを知り、イベント本文も見る。草案自身が、個人のリソース利用をAPから遠ざけようとする親プロトコルの発想との違いを認める。どのAPも情報を悪用するという話ではなく、導入する側が情報の集中を評価すべきという話だ。本文を最小限にできるか、購読の識別情報をいつ消すか、APに見える範囲がサービスの必要を超えないかは、実装の判断として残される。

したがって今回の焦点は「エージェントにもイベントが届くようになる」という一般論ではない。外部から呼べないエージェントのために入口を増やすと、確実な保管の証拠は得られるが、最終配送の証拠は別に必要になる。しかも入口の運営者が関係先と内容を見られる。運用者は 202 を最後の受領証として見せる前に、期限内の到達を何で示せるのか、そしてその証明のために誰が何を見るのかを確かめなければならない。

出典