この仕様の解説はまだ書かれていない。下の要約・関係・対応状況は維持されている。
WIMSE アーキテクチャと OAuth 2.0 系の上で AI エージェントのやり取りを認証・認可するためのベストプラクティス。どの既存標準を使い、どこにギャップがあるか。
AI Identity Management System (AIMS)
WIMSE アーキテクチャと OAuth 2.0 系の上で AI エージェントのやり取りを認証・認可するためのベストプラクティス。どの既存標準を使い、どこにギャップがあるか。
- 現在地
- 状態不明
- 公式本文
- 公式に文書化された対応
- 0
他の仕様との関係
関係図
flowchart LR s_aims["AI Identity Management System"] s_wimse_arch["WIMSE Architecture"] s_oauth2["OAuth 2.0"] style s_aims stroke-width:3px s_aims -->|土台とする仕様| s_wimse_arch s_aims -->|土台とする仕様| s_oauth2
公式に文書化された対応
利用状況には、公式のドキュメント（ベンダーやプロジェクト自身のもの、または標準化団体がその名前を挙げているページ）に対応が明記されているものだけを載せている。引用した文言がそのページにまだあるかは毎週確認している。実験的・アルファ・ベータの対応は「プレビュー」として別に数える。
出典付きの対応情報はまだ集めていない。普及していないという意味ではない。
動き
Datatracker の revision 履歴、このサイトの日次 run が書いた解説、draft 名を挙げた ML の件名。
このサイトの解説
evidence-binding の著者らは、停止された先行アクターに関する記述を RFC 8693 第4.1節と矛盾しないよう限定することにした。
New I-D: draft-thaha-wimse-agent-evidence-binding-00 (evidence binding for AIMS audit)
解説を読む
Shameer は Mikhail の二点の指摘を受け入れた。Serving Party が先行アクターの停止を理由に呼び出しを拒否できないという記述は広すぎた。RFC 8693 第4.1節が排除しているのは入れ子の act クレームをその判断に用いることであり、別途検証された委任トークンの利用ではない。文言は「先行アクターがその後停止されたことを、入れ子の act クレームに基づいて理由に呼び出しを拒否することはできない」に改められる。「完全でも証拠でもない」という履歴に関する表現は、「それ自体では完全であること、あるいはいずれかのホップが権限を保持または縮小したことを立証しない」に置き換えられる。どちらの修正も SCITT ドラフトと Evidence Binding ドラフトの次版に反映される。このメッセージ自体にドラフト本文は含まれていない。
- 入れ子の act クレームではなく検証済み委任トークンを用いて、停止された先行アクターを理由に呼び出しを拒否できるか判断する Serving Party。
- 関連: OAuth WG:
draft-ietf-oauth-transaction-tokens. 弱い関連のみ。いずれもホップ間の委任コンテキストを扱うが、資料に直接の言及はない。
AIMS と MBA のスレッドで、有効期限は「到達時点で無効」とする排他的ルールに揃え、信頼ドメインをまたぐ場合に限り委任主体の値の書き換えを許す方向で合意した。
Subject: AIMS-00: multi-hop delegation context across agent, tool and resource boundaries
解説を読む
参加者は「到達時点で無効」の境界規則を採用することで一致した。年齢が S に等しい状態は失効扱いとなり、permit は有効期限の時点以降は使用できない。S = L = 300,000 ms の例では、クロックスキューと猶予がゼロの前提で、新規受理は as-of + S + L より厳密に前に制限される。ただし受理済みの処理の完了までは制限しない。MBA に対して同じ検証ハーネスを at-or-past の期待値で実行すると、22 ケース中 15 件が一致し 7 件が相違した。相違は主に MBA が等値で包含的に比較する箇所であり、欠陥ではなく規約との差異とされている。別件として、Marc と Kieran は、委任主体の値は同一信頼ドメイン内では同一に保ち、ドメインをまたぐ場合は書き換えを認めることで合意した。Marc は、その対応関係を書き換えを行うサーバーの改ざん検知可能な監査記録に残すことを PR #176 で提案する意向である。
- permit やトークンの有効期限検査で、境界との等値を失効とみなすか判断する実装者。
- 委任主体の識別子を書き換えつつ監査可能性を保つ必要があるドメイン間エージェントゲートウェイ。
Mikhailは、過去のアクターが停止されたことを理由に呼び出しを拒否できないとする記述の修正を、エビデンス束縛ドラフトの著者に求めた。
New I-D: draft-thaha-wimse-agent-evidence-binding-00 (evidence binding for AIMS audit)
解説を読む
KieranはRFC 8693 Section 4.1により、入れ子のactクレーム内の過去のアクターはアクセス制御の判断に使えないという読みを認め、著者は-02でこれを取り入れるとしている。Mikhailは、SCITT -02の本文が依然として、過去のアクターが停止されたことを理由にServing Partyが呼び出しを拒否できないと記している点を指摘した。別途検証された委任トークンは別の根拠となる。draft-asor-wimse-agent-delegation-chain-03形式のチェーンはホップごとに検証され、ステップ7では、受け入れたステータス応答がいずれかのトークンを失効としていれば、ステータスリストの鮮度の範囲内で拒否される。そこで、拒否できないのは入れ子のactクレームに基づく場合に限るという文言と、履歴が完全でも証拠でもないという表現の修正を提案している。
flowchart LR A[Token with nested act claims] --> B[Serving party reads top-level claims and current actor only] C[Delegation chain tokens] --> D[Verify each hop] D --> E[Check status list answer] E -->|any token revoked| F[Deny]
- 上流のアクターが後から停止される、複数ホップのエージェント呼び出しの監査やServing Partyのポリシーを設計する場合。
- ホップごとの権限を、act クレーム(帰属のみ)から確認するか、ステータス参照を持つ別途検証された委任トークンから確認するかを選ぶ場合。
- 関連: OAuth WG:
draft-ietf-oauth-status-list. 委任チェーンドラフトのステータス参照と鮮度は、ステータスリストの応答に対して確認される。
AIMS のドメイン間ギャップの記述：発行者の信頼は認可を決めないこと、判断には有効期限があることを限定する文を加える方向で一致
解説を読む
このスレッドは、信頼ドメイン間の信頼に関するギャップを AIMS に記録するという David Croston の提案の続きで、機構に依存しない性質の一覧（二者間の設定なしに他ドメインの発行者を信頼できる、発行者は自身の名前についてのみ発言できる、検証者が受け入れるドメインを選ぶ、失効の時間的上限）が示されている。Jiahui Miao は、他ドメインの発行者を受け入れてもそれだけでは操作の認可は確立されないという限定的な性質を加えた。ShaoBao Li は、判断は観測時点で成立し、証拠の失効後は成立しないという時間面を加えた。Cliff は、ギャップ記述に一文、残り（「不許可」ではなく「未判定」と記録する規則を含む）を Section 10.4 に置くことに同意した。Sriram Shankarlingam も賛成し、自身の DNS リンクトークンは何も許可しないと述べた。複数のメッセージが著者自身のドラフトや適合性テストを引用している。
- 二者間の信頼バンドル交換がない組織間でエージェントをフェデレーションする場合。
- 権限を判定できず拒否した場合と、操作が許可されず拒否した場合を監査で区別する必要がある場合。
- 関連: OAuth WG:
draft-ietf-oauth-spiffe-client-auth. 関連は緩やか（ワークロード識別子と OAuth クライアントの結び付け）で、資料は引用していない。
短い返信：act は帰属情報であり、ポリシー入力ではない。evidence-binding の著者が -02 で反映する
New I-D: draft-thaha-wimse-agent-evidence-binding-00 (evidence binding for AIMS audit)
解説を読む
件名は draft-thaha-wimse-agent-evidence-binding-00 の告知だが、ファイルにあるのは Mikhail への Kieran の返信のみである。Kieran は先の「ポリシー入力」という説明が誤りだったと認めた。RFC の Section 4.1 は過去の行為者をアクセス制御の判断から除外しており、過去の行為者を拒否リストに載せることはそれと矛盾するためである。方向 (a) が正しい読みで、Shameer と Shaibi が -02 に取り込む。ホップごとの権限には別途検証された証拠が必要である。告知本文自体はファイルに含まれない。
AIMS の委任スレッド：信頼ドメインをまたぐ場合、対応関係が署名された記録にあれば委任対象の識別子は異なってよい
解説を読む
Kieran Sweeney は、「sub の保持」は同じバイト列ではなく同じプリンシパルを指すと明確化した。同一信頼ドメイン内では全ホップで値が同一（sub は固定、行為者は client_id と act）。信頼ドメインをまたぐ場合は、identity chaining による書き換えは、書き換えた当事者が旧値・新値・自身の識別子を署名対象に記録するなら許容される。AS が対応関係を保持するだけでは AIMS Section 11 には不十分である。Marc は PR #176 に同趣旨の二つの修正を提案する。また、鮮度の境界を「期限以降は拒否」に改めることでも合意し、21 件の境界ベクターと 10 月 23 日の文言が変わり、ちょうど S+L で受理されていたケースは拒否になる。
sequenceDiagram participant A as Domain A AS participant B as Domain B AS participant L as Signed audit record A->>B: token with sub value X B->>B: transcribe X to Y B->>L: record old X, new Y, own identity B->>B: issue token with sub Y
- identity chaining で信頼ドメインをまたぐエージェントチェーンで、監査者が記録だけから元のユーザーを復元する必要がある場合。
- S+L の失効受理境界を実装する検証者が、ちょうど期限の入力を受理するか判断する場合。
- 関連: OAuth WG:
draft-ietf-oauth-identity-chaining. 信頼ドメイン間で書き換えられる識別子は OAUTH-ID-CHAIN の Section 2.5 として議論されている。
Marc は、sub が各ホップで保存されるとは、トラストドメインをまたいでも同じ値という意味かを問うている。
Subject: AIMS-00: multi-hop delegation context across agent, tool and resource boundaries
解説を読む
Marc は、sub は各ホップで Principal であり元の委任対象のままである、という Kieran の発言を引用している。そのうえで、保存とは、ホップがトラストドメインをまたいで転記された識別子（OAUTH-ID-CHAIN の 2.5 節）を受け取る場合も含め、すべての当事者で同じ sub の値を意味するのかを問う。もう一つの解釈は、各値が同じ User を指し、発行した認可サーバーが 11 節のためにその対応を保持していれば足りるというものである。Nik が AIMS の issue #88 と #90 について、値が当事者間で異なりうる 10.10 節の文案を提案しており、それが Kieran の性質と食い違わないようにするための質問だという。このメッセージには回答は含まれていない。
- 下流の認可サーバーが同じユーザーに対して別の識別子を発行する、複数ドメインにまたがるエージェント配備。
- 関連: OAuth WG:
draft-ietf-oauth-identity-chaining. このメッセージは、トラストドメイン間で転記される識別子について OAUTH-ID-CHAIN の 2.5 節を引用している。
- 実質的な変更IETF WIMSE
AIMS 監査記録向けの AER-1 マッピングで、拒否された判断と評価できなかった判断を区別する方針が固まった。
draft-zambo-aer1-wimse-mapping-01: AER-1 as a candidate format for AIMS Section 11 audit records
解説を読む
draft-zambo-aer1-wimse-mapping のスレッドで Girish Konda は、提供側の理由がコミットされるハッシュの外にあるため、拒否レシートではポリシーによる拒否と確認を完了できなかった場合を区別できないと指摘した。-02 では、コミットされる decision_reason メンバー（denied または not_evaluated）と decision_reason_detail が追加された。Konda はさらに、到達不能または古い入力の後に fail-closed で拒否した場合も denied と記録されてしまうと指摘した。著者はこれに同意し、-03 では、判断が依存する入力を確定できなかった場合は fail-closed の規則で拒否しても not_evaluated とする。この理由は監査の読み手のためにコミットされ、呼び出し元には返されない。-03 は投稿ツールの再開後の 11 月 15 日に投稿される。
- AIMS Section 11 向けに改ざん検知可能な監査ログを作成する環境では、ポリシーによる拒否と、ポリシー源や状態源に到達できない、または古い場合とを区別する必要がある。
- fail-closed のポリシー判断点は、呼び出し元には一様なエラーを返しつつ、拒否の理由を記録に残せる。