今週の要点

Ben Le は Kieran Sweeney への返信で、-01 では累積上限を持つレシートは依拠当事者を一つだけ指名しなければならず、その当事者がレシートとすべての子レシートの合計を単独で数えると述べた。単一の指名がない上限付きレシートは無効となる。複数の依拠当事者間で合計を共有することは対象外であり、呼び出し経路上の他の当事者が合計を保持する可能性は未決である。付与には RFC 9396 の authorization_details タイプを定義し、RAR 対応の認可サーバーがルートレシートを直接発行できるようにする。エージェントがパスポートをアクタートークンとしてレシートを得る場合は Token Exchange を使い続ける。さらに制約種別ごとの包含規則表(host、port、methods、paths、tools、max_body_bytes、max_calls、max_spend、exp、aud)を示した。子が親を縮小したといえるのはすべての規則を満たす場合のみであり、未知のメンバーや比較できないものは拒否される。-01 にはチェーン当たり 8 レシートという固定上限のみがあり、深さのクレームはない。IETF 127 に先立ち、11月16日の Niki 主催のサイドミーティングに参加し、17日に自身のサイドミーティングを開く予定である。

• RAR に対応済みの認可サーバーは、新しい authorization_details タイプを使ってエージェント向けのルート委任レシートを発行できる。
• エージェントのチェーンに累積の支出上限や呼び出し回数上限を適用する依拠当事者は、レシート内で指名された唯一のカウンターとなる必要がある。
• 複数のエージェント委任ドラフトを実装する者は、制約種別ごとの縮小規則表を共通のテストベクトルの出発点にできる。

• 関連: IETF WIMSE: draft-asor-wimse-agent-delegation-chain. スレッドで、比較対象となる独自の包含規則を持つドラフトとして挙げられている。
• 関連: IETF WIMSE: draft-hulea-wimse-agent-mandate. スレッドで、縮小規則の比較対象として Hulea の名で挙げられている。
• 関連: IETF WIMSE: draft-sweeney-wimse-credential-delegation. スレッドで返信している Kieran Sweeney が著者の委任ドラフトである。著者名のみに基づく推定である。

Shameer は Mikhail の二点の指摘を受け入れた。Serving Party が先行アクターの停止を理由に呼び出しを拒否できないという記述は広すぎた。RFC 8693 第4.1節が排除しているのは入れ子の act クレームをその判断に用いることであり、別途検証された委任トークンの利用ではない。文言は「先行アクターがその後停止されたことを、入れ子の act クレームに基づいて理由に呼び出しを拒否することはできない」に改められる。「完全でも証拠でもない」という履歴に関する表現は、「それ自体では完全であること、あるいはいずれかのホップが権限を保持または縮小したことを立証しない」に置き換えられる。どちらの修正も SCITT ドラフトと Evidence Binding ドラフトの次版に反映される。このメッセージ自体にドラフト本文は含まれていない。

• 入れ子の act クレームではなく検証済み委任トークンを用いて、停止された先行アクターを理由に呼び出しを拒否できるか判断する Serving Party。

• 関連: OAuth WG: draft-ietf-oauth-transaction-tokens. 弱い関連のみ。いずれもホップ間の委任コンテキストを扱うが、資料に直接の言及はない。

Alexander Pelov は、独立した複数の実装（実験的な WIT-SVID 対応の SPIRE、go-spiffe、Cofide の PoC、Python 実装）を用いた相互運用シナリオを実施する予定である。シナリオは workload-creds-03、wpt-02、http-signature-08、identifier-04、Txn-Token、アイデンティティチェーニングを二つの信頼ドメインにまたがって使い、ログには共通のトランザクション ID を記録する。正常系では Txn-Token を各ホップの証明に束縛し、Txn-Token 自体はドメイン外に出さない。Ben Le（draft-le-agent-passport）と Iman は、到達不能なステータスリスト、委任後の失効、権限が拡大する委任、二つのサービスにまたがる累積上限、プロキシによるリクエスト書き換え、ツール定義のダイジェスト変化といったケースを追加した。Iman は、確定した失効、期限切れのステータスキャッシュ、利用不能なステータスサービスをログ上で区別すること、また失効した認可では効果が生じる前に操作が阻止されることを求めている。

sequenceDiagram
 participant A as Agent A (domain A)
 participant B as Agent B
 participant R as Receiving hop
 A->>B: delegate
 B->>R: first call
 R-->>B: accepted
 Note over A: A is revoked
 B->>R: next call
 R-->>B: rejected (fail closed)

• 他実装と比較できる共通の異常系テストケースを求める WIT/WPT や Txn-Token の実装者。
• ステータスリストに到達できない場合や、チェーン途中で委任元エージェントが失効した場合のフェイルクローズ方針を定める運用者。

• 関連: OAuth WG: draft-ietf-oauth-transaction-tokens. シナリオでは Txn-Token を各ホップの証明に束縛し、ドメイン内にとどめている。
• 関連: OAuth WG: draft-ietf-oauth-identity-chaining. 信頼ドメイン B への移行にアイデンティティチェーニングを用いる。

PR の本文は、Aaron が文書に対して他の誰よりもはるかに多く貢献しており、著者表記もそれを反映すべきだと主張している。不完全な例としてスクリーンショットが添付されている。仕様の本文やプロトコルの挙動は変わらない。議論や結果は資料に含まれていない。

CalebはKieranのレビュー項目1、4、6と、ユーザー発行ルートをチェーン形式と組み合わせるjti-as-rootの形を受け入れた。-03に向けて、検証者ごとに保持する集計は検証者単位の合計しか制限せず、全体では制限できないため、累積予算には全ての行使を見る単一の書き込み元が必要であることに同意している。また、ユーザーはステータスエンドポイントを運用できないため、グラントがステータスの所在を示す必要があるという指摘も認め、本文を用意するとしている。引用された先行メッセージでは、Robがルートの発行者と、人が承認したことの証拠を分けるよう提案し、Section 7に停止中の行為を検証者がどう見るか、復旧した委任が同一のグラントかを記すよう求めた。Kieranは-02のSection 7は失効のみを扱うと述べている。

• 複数の検証者にまたがる累積の支出や呼び出し予算を強制する委任クレデンシャルサービスを構築する場合。
• ステータスエンドポイントを置くサーバーがない、ユーザー直接発行の委任ルートを発行する場合。

Mohamad Yossifは、チェーンの葉が特定の1リクエストへの束縛を自身で表現する必要はなく、別の証明のダイジェストを保持するか、jtiで参照すればよいと主張している。draft-yossif-psea-03は、承認者の登録済みデバイスがRFC 8785形式のリクエストのSHA-256に対して署名する証明であり、検証者はリプレイを拒否すると説明している。比較表では「トークン内では表現できない」と「参照により表現できる」を別項目にすることを提案している。Imanはこれに同意し、行為識別子、承認のjti、証明への参照は区別して保持すべきだとしている。またDR-C7が確認するのは同一検証者への2回目の提示のみだと指摘している。さらに、1つの証明を2つの強制点の2つの葉から提示し、完了するのは高々1つであることを確認する新しいテストを提案している。ローカルのリプレイキャッシュが別々では、これは示せない。スレッドにドラフト本文の変更はない。

• エージェント向け認可トークンの作成者が、リクエスト単位の承認をトークン内に持たせるか、外部の証明を参照させるかを決める場合。
• 同一の検証ドメインに複数の強制点を置く運用者が、リプレイ状態をそれらの間で共有する必要があるかを判断する場合。

Mikhailは10月23日の例を排他的な限界値に改めることに同意した。すなわち、経過時間がSに等しい状態は古いものとして扱い、許可は有効期限の時点以降は使えず、発行には発行時刻より後の許可期限が必要である。最終発行時点でSを強制し、許可の有効期間をLで制限すれば、ゼロのクロックスキューと猶予を仮定して、新規の受理は元のas-of + S + Lより厳密に前に限られる。ただし受理済みの作業の完了は制限されない。MBAのコミットea1a149に対して同じハーネスを再実行すると22件中15件が一致し7件が異なった。差異はMBAが等値を包含的に比較する箇所にあり、欠陥ではなく規約との違いだと述べている。引用されたMarcのメッセージでは、信頼ドメインをまたぐ際に委任された主体の値を変換して記録する場合、変換前後の値とサーバーの識別子を改ざん検知可能な監査記録に残せばよいかをKieranに確認し、PR #176への二つの修正を提案している。

• 許可やミッション束縛認可の期限検査を実装する際、有効期限と等しい時点を期限切れとして扱う必要がある場合。
• 古さと期限のテストベクターを書き、独立した実装が等値の境界で同じ結果になるようにする場合。
• リクエストが信頼ドメインをまたぐ際にサーバーが書き換える主体識別子をどう記録するかを決める場合。

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 に記録するという David Croston の提案の続きで、機構に依存しない性質の一覧（二者間の設定なしに他ドメインの発行者を信頼できる、発行者は自身の名前についてのみ発言できる、検証者が受け入れるドメインを選ぶ、失効の時間的上限）が示されている。Jiahui Miao は、他ドメインの発行者を受け入れてもそれだけでは操作の認可は確立されないという限定的な性質を加えた。ShaoBao Li は、判断は観測時点で成立し、証拠の失効後は成立しないという時間面を加えた。Cliff は、ギャップ記述に一文、残り（「不許可」ではなく「未判定」と記録する規則を含む）を Section 10.4 に置くことに同意した。Sriram Shankarlingam も賛成し、自身の DNS リンクトークンは何も許可しないと述べた。複数のメッセージが著者自身のドラフトや適合性テストを引用している。

• 二者間の信頼バンドル交換がない組織間でエージェントをフェデレーションする場合。
• 権限を判定できず拒否した場合と、操作が許可されず拒否した場合を監査で区別する必要がある場合。

• 関連: OAuth WG: draft-ietf-oauth-spiffe-client-auth. 関連は緩やか（ワークロード識別子と OAuth クライアントの結び付け）で、資料は引用していない。

このメールは、新しい Agent Passports and Delegation Receipts ドラフトの未解決の2点について Ben に返信したものであり、資料にあるのは Kieran の返信のみでドラフト本体は含まれない。依拠当事者（RP）間の共有上限の集計について、累積上限には全ての行使を観測する書き込み元が一つ必要であり、別々の RP では合計を保持できないため、受領証が一つの RP を指名するか、呼び出し経路上のいずれかの当事者が累計を保持する必要があるとしている。RAR については、authorization_details を付与に使うことに同意し、既に RAR を扱う AS ならルートの受領証を発行できるとしている。最初に揃えるべきは制約種別ごとの包含規則であり、asor、AAT、Hulea がそれぞれ独自の規則を持つこと、Niki が IETF 127 までに比較を申し出ていることを述べている。

• 既に RAR に対応しており、authorization_details を使ってルートの委任受領証を発行したい AS。
• 複数の RP にまたがるエージェントシステムで、共有の支出上限や呼び出し上限をどこで集計するかを決める設計者。

• 関連: IETF WIMSE: draft-hulea-wimse-agent-mandate. 独自の包含規則を持つドラフトの一つとして名前が挙がっている。
• 関連: IETF WIMSE: draft-asor-wimse-agent-delegation-chain. 独自の包含規則を持つドラフトの一つとして名前が挙がっている。

Mohamad Khalil Yossif は、9.4節の as_signature は AS が承認を記録したことを示すだけで、承認者本人が承認したことは示さないと指摘した。その上で、承認者の署名を生成する一手段として draft-yossif-psea（RATS の EAT プロファイルで、ユーザー検証後に RFC 8785 のバイト列の SHA-256 に署名する）を挙げ、authorization_evidence の任意メンバーとして載せる案を示した。ただし信頼できる表示は範囲外であるため9.5節の問題は解消しないとも述べた。著者の Dapeng は、同草案は仕組みを意図的に未定としており、要件の追加や既存の IETF 成果の参照はあり得るが、現段階では問題定義と証拠モデルについてワーキンググループ内で合意することが優先だと返答した。続いて Iman が、署名付き声明に含めるべき項目として、目的、決定、開示内容の正確なバイト列または正規化ダイジェスト、承認された権限の範囲、承認の発生を挙げた。さらに、承認者と署名用クレデンシャルとの信頼できる結び付け、audience と鮮度の検証、AS 署名の記録との循環依存を避けるための署名対象バイトの明示的な境界も求めた。比較用のテストケースも提案し、表示の出所が確立されていない有効な署名は別の結果として扱うべきだとした。草案本文の変更はない。

sequenceDiagram
 participant A as Approver device
 participant AS as Authorization server
 participant V as Verifier
 AS->>A: Show disclosure and bounds
 A->>A: User verification, sign digest of canonical bytes
 A->>AS: Approver proof
 AS->>V: authorization_evidence with as_signature and optional proof
 V->>V: Compare digest, check binding, audience, freshness

• エージェントの操作に対するユーザー承認を記録する AS で、承認が AS の記録だけでなく本人によるものであることを示す手段が必要な場合。
• 検証者が、有効な承認者署名と、本人が実際に画面で見た内容の証明とを区別する必要がある場合。

• 関連: IETF WIMSE: draft-munoz-wimse-authorization-evidence. エージェントの操作に対する署名付き認可証拠レコードを扱う点で共通するが、メール中に言及はなく、主題上の関連にとどまる。

Mohamad は GitHub リポジトリへの追加を依頼し（アカウントは MohamadKhalilYossif）、要件を先に定めることに同意している。9.4 については、方式を名指しせず、承認者側署名が満たすべき短い規範的な一覧を提案している。内容は、開示されるバイト列そのものまたはそのダイジェストを対象とすること、登録時に承認者へ束縛された資格情報で作成されること、属する承認を識別できることの3点である。PSEA を含む既存の仕事は参考文献（informative reference）とする。これはリストではなくプルリクエストで送るとしている。メール上の提案であり、ドラフト本文にはまだ反映されていない。

• エージェントの動作に対する人の承認フローを実装しており、承認者の署名が何を対象とすべきかを知りたい実装者。
• 要件についてプルリクエストを通じて議論に参加したい、または追いたいレビュアー。

• 関連: IETF WIMSE: draft-munoz-wimse-authorization-evidence. 署名付き認可証跡という近い題材だが、資料上は両者の関連は示されておらず、比較のための参考にとどまる。

件名は draft-thaha-wimse-agent-evidence-binding-00 の告知だが、ファイルにあるのは Mikhail への Kieran の返信のみである。Kieran は先の「ポリシー入力」という説明が誤りだったと認めた。RFC の Section 4.1 は過去の行為者をアクセス制御の判断から除外しており、過去の行為者を拒否リストに載せることはそれと矛盾するためである。方向 (a) が正しい読みで、Shameer と Shaibi が -02 に取り込む。ホップごとの権限には別途検証された証拠が必要である。告知本文自体はファイルに含まれない。

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 として議論されている。

Kieran は Caleb と Rob に回答している。Caleb の指摘のうち 1、4、6（ユーザー発行トークンのリマップ、深さ0の値、「user-issued」）は妥当としている。ユーザー発行のルートをチェーン形式とどう組み合わせるかは Rafael とまだ調整が必要で、Caleb の jti をルートとする案は具体的な提案だとしている。累積キーごとのモードマーカーは -03 で提案する予定である。累積上限には全ての行使を観測する書き込み元が一つ必要であり、検証者ごとに保持する集計では検証者ごとの合計しか抑えられないと注意しており、これは Section 5.5 にも既に書かれている。-02 は DS が発行していないトークンのステータス機構を定めておらず、Section 7 はオフライン検証者が失効を知るのは参照するステータス機構によるとだけ述べている。Rob の、ルートの発行者と人が承認した証拠を分けるという指摘は有用としている。Section 7 は失効のみを扱い、一時停止と復元には触れておらず、1時間の上限は露出を抑えるが閉じるものではないと認めている。

• 検証者ごとの集計に頼っており、累積上限が別々の検証者をまたいでは強制されないことを知る必要がある運用者。
• 他所で発行された委任トークンを検証するが、-02 がステータス機構を定めていないため自分で選ぶ必要がある検証者。

• 関連: IETF WIMSE: draft-sweeney-wimse-credential-delegation. 議論されている -02 の本体のドラフトである。

Kieran は、各ホップでの有効な最大深度は経路上で最小の del_max_depth であること、およびこの上限は「最大深度にある末端」の扱い（AAT J.10.f は del_depth がルートの最大値に等しい末端を受理し、Asor -03 は拒否する）とは別に決めるべきだと述べた。Rob Zagarella は三つのドラフトの比較表に、末端を単一リクエストのダイジェストに束縛できるかを記録するよう求め、Kieran は Cred -02 では現状トークンで表現できないと答えた。Cred -02 の Section 5.5 はチェーン形式を参照で取り込むため、DS 外で検証する場合の記載は暫定である。Rob は AAT Section 9.8 の失効鮮度の上限を Cred -02 Section 7 と同じ表現で示すことも求めた。Niki は 11 月 16 日にサンフランシスコでサイドミーティングを開く。

• 減衰する委任トークンの実装者が、最大深度にある末端を受理すべきか知る必要がある場合。
• 受取人と金額のように、承認を一つの具体的な操作に束縛する必要がある人間承認のフロー。

• 関連: OAuth WG: draft-ietf-oauth-transaction-tokens. 資料中では参照されていない。

Kieran の -02 告知は、ユーザーが預けた資格情報を保持する Delegation Server（DS）を置き、エージェントが委任トークンのもとで代理実行する構成を説明している。追加点は、サブ委任の交換（5.4.1）、トークン内の順位、DS のみが書き込む max_lifetime と max_subtree を持つ delegation_constraints、Asor の agent_delegation 形式をそのまま採用するチェーン検証プロファイル（5.5）、revoked_count は無効化であって完結ではないとする失効の記述、ML-DSA の許可である。Caleb Dayton は、ユーザー発行トークンの claim 再マッピング、jti をルートレシートとする案、単一書き込み元と委任先保持の集計を区別するモード指示、DS がない場合の状態確認手段など六点を指摘した。Kieran は鍵ごとのモード指示に同意しつつ、検証者ごとの集計では検証者をまたいだ総量は抑えられないと注意し、DS が発行していないトークンのステータス機構は -02 に定めがないと述べた。Rob Zagarella は、ルートの発行者と人間の承認の証拠を分けること、および Section 7 で一時停止と復元を扱うことを提案した。

sequenceDiagram
 participant U as User
 participant DS as Delegation Server
 participant AG as Agent
 participant UP as Upstream resource
 U->>DS: deposit credential
 DS->>AG: delegation token
 AG->>DS: exercise under token
 DS->>UP: call with deposited credential
 DS->>AG: result and receipt

• ユーザーが OAuth 資格情報をプロキシに預け、エージェントが上流トークンを保持しないエージェント基盤。
• DS から離れた検証者が、累積上限を超えたか判断する場合。

• 関連: OAuth WG: draft-ietf-oauth-identity-chaining. 資料中では言及されていない。

#3 と #10 を修正する PR #15 は、セキュリティおよび有効性に関するクレーム (cnf、exp、nbf など) を delegate_payload からベースの KB-SD-JWT ペイロードへ移す。これにより標準的な JWT / SD-JWT ライブラリは、delegate payload を先に展開せずにそれらを評価できる。複数の delegate_payload エントリがある場合は、ベース KB-SD-JWT のセキュリティクレームを共有する。また、cnf、iat、exp、nbf、aud、nonce、sd_hash、issuer_jwt_hash が、新しい Delegate Holder への委任時にどう解釈されるか、およびその後の Delegate Holder や検証者にどう解釈されるかを定める節を追加し、Verification の節も更新する。入手できたのは PR の説明のみで、差分は確認できていない。

• 委任されたプレゼンテーションの cnf や有効期限を、委任固有の展開処理なしに既存の SD-JWT KB 検証で確認したいライブラリ実装者。
• クレデンシャルを別のホルダーへ再委任するエージェントが、audience と nonce の意味を明確にする必要がある場合。

Henk Birkholz は、OAuth WG が自律エージェントの認可と委任を対象に再チャータされたことに触れ、提案中の AUDIT WG が再利用できる具体的なレコード形式やログアーティファクトを作る予定があるかを尋ねた。IETF 127 の BoF は既存形式をできるだけ再利用する方針だという。Heime.Jorgen は、実行前の結合がない事後記録はリプレイや TOCTOU 攻撃を招き、チャーターは RFC 5434 の基準を満たさないとして繰り返し反対し、実行前シールや実行ノンスのための拡張スロットを求めた。Mirja Kuehlewind は、反対意見は記録済みであり繰り返す必要はないと返した。この資料では OAuth WG の参加者による Henk の質問への回答はなく、ドラフト本文も関与しない。

• エージェントの認可・委任ドラフトの著者が、自分たちのレコードを監査証拠として使えるようにするよう求められる可能性がある場合。

• 関連: IETF WIMSE: draft-munoz-wimse-authorization-evidence. エージェント操作の署名付き認可証拠レコードは、AUDIT BoF が問うレコード形式に該当する。

Dmitri Chistyakov が draft-hulea-wimse-agent-mandate-01 の Section 9.5 にコメントした。同ドラフトは、解決できないステータスを不確定として扱い既定で拒否するが、トークンが未使用のまま失効した場合は RP が累積上限への寄与を削除してもよい(MAY)としている。寄与はトークン発行時に記録される(Section 10.2)が、トークンが未使用だったことを RP がどう知るのかは書かれていない。実行確認の欠如や遅延から未使用と判断すると、実際に実行された操作の寄与を削除してしまい、予算が過小に数えられ、後続のリクエストが sum_max の検査を誤って通過し得る。提案は、RP のポリシーまたは Trust Framework で信頼される積極的な証拠(例えばリソースサーバーがそのトークンを受理していないと述べる声明)がある場合に限って削除を認め、確認の欠如は証拠に当たらないとするものである。証拠がなければ寄与は記録されたままとなり、期間ウィンドウから外れるまで不要な拒否が生じ得る。送信者は、このメッセージが AI の支援を受けて作成されたと述べている。これはレビューコメントであり、ドラフト本文の変更ではない。

sequenceDiagram
 participant RP
 participant RS as Resource server
 RP->>RP: record contribution when token is issued
 Note over RP: token expires, no confirmation seen
 RP->>RS: ask whether the token was ever accepted
 RS-->>RP: never accepted, stated after expiry
 RP->>RP: remove contribution
 Note over RP: without this statement the contribution stays

• 委任トークンを用いて AI エージェントの期間ごとの支出や操作回数の上限を強制する RP で、実行確認が遅延または欠落し得る場合。
• トークンが一度も受理されなかったことを誰が証明できるかを Trust Framework に定める場合。

Mohamad は Henk への返信で、RATS の EAT プロファイルである draft-yossif-psea を挙げている。このドラフトでは、登録済みの認証器が、ユーザー検証の後に、操作内容を RFC 8785 で正規化した形式の SHA-256 に対して承認者として署名する。公開されたテストケースは独立した検証器1つで再現されている。この署名は埋め込むのではなく引用して使う想定だと述べている。また、draft-liu-oauth-authorization-evidence は認可サーバーから見た承認を RAR に記録し、9.4 節で承認者側の署名を推奨していること、Konrad Gruszka の decision receipts ではこの署名が未定義のままであることを指摘している。そのうえで、vCon について Mirja が述べた分担、つまり認可サーバーの記録は OAuth、承認者の署名は RATS に置き、AUDIT が記録から両者を参照する方法を規定する、という案を示している。議論の投稿であり、ドラフト本文の変更はない。入手できたのは引用部分のみで、Henk の元の質問は確認できない。

flowchart LR
  A[Approver authenticator] -->|signs SHA-256 of RFC 8785 action| S[PSEA record in RATS]
  AS[Authorization server] -->|RAR approval record| R[OAuth record]
  AUDIT[AUDIT profile] -->|references| S
  AUDIT -->|references| R

• リスクの高い操作について人による承認の監査証跡が必要で、認可サーバー側のログとは別にユーザー署名の記録がある運用。
• RAR を使った承認フローの実装者が、承認者側の署名を OAuth で規定するのか RATS から参照するのかを知りたい場合。

Mohamad Khalil Yossif は、draft-liu-oauth-authorization-evidence-02 の 9.4 節では as_signature が示すのは AS が承認を記録したことであって承認者が承認したことではない、と指摘していた。さらに、承認者の認証器が disclosure オブジェクトの RFC 8785 (JCS) バイト列の SHA-256 に署名する EAT プロファイル draft-yossif-psea を、authorization_evidence の任意メンバーとして運ぶ案を示した。信頼できる表示は範囲外のため 9.5 節の問題は解決しないとも述べている。著者の Dapeng は、9.4 節は推奨を述べるだけで仕組みは意図的に未定義であり、必要なら要件を定めるか既存の IETF 成果を参照できると回答した。現時点では問題定義と証拠モデルについてWGの収束を優先するとし、GitHub リポジトリへの参加も提案した。ドラフト本文の変更はない。

• エージェントの操作に対するユーザー承認を記録する AS が、サーバーだけでなく本人が承認したことを後から示す必要がある場合。
• 承認者が署名したダイジェストを、AS が記録した disclosure オブジェクトと照合したい検証者。

• 関連: IETF WIMSE: draft-munoz-wimse-authorization-evidence. エージェント操作に対する署名付き認可証拠レコードを定めており、同じ問題領域を扱う。

Cliff は、Marc の不正形式のケースと併せて、任意の decision.evaluatedAt フィールドを追加することに賛成している。ただし、評価時点での鮮度と効果発生時点での鮮度の差は、これだけでは解消しないと指摘している。レコードには既に effect.interval.openedAt があるため、読み手は効果開始時点での入力の経過時間を計算できる。そこで、5.4節に「エントリは評価時点のみを表す」という一文を加えることを求めている。また、standing が evaluatedAt 時点では新鮮だが openedAt 時点では maxAge を超えているテストレコードを、整形式として受理するよう求めている。投稿はドラフト名を示しておらず、スレッドの前後の文脈も含まれないため、元の提案は一部しか分からない。

• 判断レコードを検証する実装者は、効果発生時点で入力が古い場合に、そのレコードを不正形式として扱うのか、参考情報にとどめるのかを知る必要がある。
• レコードから行為を再構成する監査担当者は、evaluatedAt を効果発生時点の鮮度の証拠とみなさず、effect.interval.openedAt から効果開始時点の入力の経過時間を計算したい。

-25 以降、第 2.2.2.2 節は、クレデンシャルの型は vct の値であるか aka_vcts に列挙されたものであると定めている。この PR は第 5.4 節に残っていた二点を削除する。一つは、Consumer が Type Metadata の extends プロパティでも型を照合してよいとする MAY、もう一つは vct の型が aka_vcts の各型を extends すべきとする SHOULD で、型は他の一つの型しか extends できないため、無関係な型が並ぶ場合には満たせない。extends は継承する Type Metadata を決めるだけになる。第 5.4 節は、拡張した型を aka_vcts に列挙するという第 2.2.2.2 節の推奨を参照し、第 7.7 節は aka_vcts の型を vct の型と同様に発行者が表明したものと記述する。後続の MUST NOT は変更されない。PR は、新しい要件はないこと、OpenID4VP 1.1 は既に vct と aka_vcts で vct_values を照合していること、ISO/IEC 18013-5 が 11 月末に日付付きドラフトを引用する予定であることを述べている。

• vct_values を照合する検証者は、Type Metadata の extends から追加の型を推定してはならず、どちら側がメタデータを取得したかで結果が変わらなくなる。
• 検証者が要求する親の型を extends している型の発行者は、その親の型を aka_vcts に列挙すべきである。
• 型の照合を本文書に委ねている ISO/IEC 18013-5 の mdoc プロファイル。

• 関連: OpenID: openid/OpenID4VP. PR は、OpenID4VP 1.1 が既に vct と aka_vcts で vct_values を照合し、型の拡張は帯域外の知識として扱うと述べている。

利用できるのはコミットタイトルのみで、23件中8件は一覧に含まれないため、全体像は部分的である。タイトルからは、CredentialItem.format を credential_format に改名したこと、フォーマット附属書を credential_types の配列化に合わせたことが読み取れる。また、mdoc ではなくウォレットが issuer 署名か device 署名かを選ぶと明記したこと、定義が認める場合に代替のデータ要素を返せるようにしたこと、support_no_cryptographic_binding の DocRequestInfo へのマッピングを削除したことも読み取れる。SD-JWT VC のパス意味論は issue #52 に委ねられ、KB-JWT の提案が反映された。ISO 18013-5 の Document 型をバイト列として再定義するのをやめ、authority key identifier には RFC 5280 の名称を用い、RFC 7515 を規範的参照に追加した。残りはレビュー対応と整備のコミットである。ワイヤ形式への正確な影響は、タイトルだけでは確認できない。

• dchp を追跡するウォレット開発者は、credential_format への名称変更と、配列となった credential_types に対応する必要がある。
• mdoc レスポンスの実装者は、issuer 署名か device 署名かをウォレットが選ぶことを把握する必要がある。

このメッセージは、新規ドラフト draft-williams-oauth-poi-core-00 に関するスレッドでの Paul Williams の返信である。Mohamad Khalil Yossif は、PoI Core の attestation が draft-yossif-psea（RATS の EAT プロファイルで、登録済みオーセンティケーターがユーザー検証後に、アクションパラメーターの RFC 8785 形式の SHA-256 に署名する）に近いと指摘していた。Paul は両者が補完的であることに同意している。PoIE の attestation ブロックはメディアタイプで拡張可能とし、デバイスバインドの Tier 2 と Tier 3 のアサーションでは PSEA を主要プロファイルとする。一方、Tier 1 のメモリ上の Web Crypto セッション鍵はハードウェアエンクレーブから切り離したままにする。役割分担は次のとおりである。PSEA はデバイスバインドの署名を担い、PoI Core は二段階のチャレンジフロー（HTTP 403 とステップアップのネゴシエーション）と、IdP 証明および PoP チェーンによる Tier 1 ブラウザー鍵を定義する。表示の完全性は、リソースサーバーが不透明な ID を署名付きの display_facts に解決することで扱う。Paul は application/psea+jwt トークンを PoIE のノードアサーションスキーマに入れる試行を提案し、conformance suite のサンプルトークンを求めている。まだ仕様化されておらず、初期段階の整合の議論である。

sequenceDiagram
 participant C as Client
 participant RS as Resource Server
 participant A as Authenticator
 C->>RS: Request action
 RS-->>C: HTTP 403 step-up challenge
 RS-->>C: Opaque ID resolved to signed display_facts
 C->>A: Parameters plus display_facts
 A-->>C: PSEA token signed after user verification
 C->>RS: Retry with PoIE carrying PSEA token

• 特定の高額なアクションについて人間の承認を求め、ユーザーに提示した正確なパラメーターに結び付いた署名付き証明を必要とするリソースサーバー。
• 承認のリスクレベルに応じて、ブラウザーのみのセッション鍵とハードウェアに裏付けられたオーセンティケーターを使い分けたい運用者（Tier 1 と Tier 2、3）。

Mohamad が draft-liu-oauth-authorization-evidence-02 にコメントしている。第 9.4 節は、as_signature は AS が承認を記録したことしか証明せず、それ以上が必要な運用では承認者側の署名を追加すべき（SHOULD）としている。AUDIT リストで報告された、本人に提示されていない文面にサーバーが署名しても -02 の検査を通ってしまう事例を挙げている。提案は draft-yossif-psea の利用で、これは RATS の EAT プロファイルであり、承認者の登録済み認証器がユーザー検証の後、RFC 8785 のバイト列の SHA-256 に署名する。そのバイト列を disclosure オブジェクトの JCS 形式にすれば、検証者はダイジェストを disclosure と比較できる。PSEA は信頼できる表示を対象外とするため、第 9.5 節は解決しない。任意メンバーの提案文と Appendix B に対する実例の提供を申し出ている。

sequenceDiagram
  participant P as Approver
  participant AS as Authorization server
  participant V as Verifier
  AS->>P: show disclosure object
  P->>AS: PSEA token signed over SHA-256 of JCS bytes
  AS->>V: authorization_evidence with as_signature and optional PSEA token
  V->>V: compare PSEA digest with disclosure digest

• 侵害された、または不注意な認可サーバーに対しても、エージェントの操作に対する人の承認を証明できなければならない運用。
• 承認された文面が記録された disclosure と一致することを確認する監査担当者。

• 関連: IETF WIMSE: draft-munoz-wimse-authorization-evidence. エージェント操作に対する署名付き認可証跡レコードを定義する別ドラフトだが、このメッセージでは言及されていない。

Sankalp Gilda は鮮度の境界を「期限以降は失効」とすることに同意した。draft-gilda-audit-agent-audit-record の次の改版では、入力の経過時間が maxAge 未満の間のみ有効とし、ちょうど maxAge のテストレコード FR2 は拒否ケースになる。記録には decision.reportedAt しかないため、任意の decision.evaluatedAt を提案し、存在すればそこで、なければ reportedAt で経過時間を測る。境界の両側のテストレコードも追加する。Marc はこれを支持し、公開コミットメントに基づく standing は判断時点での経過時間に依存すると述べ、evaluatedAt が reportedAt よりスキュー許容を超えて後なら不正として拒否する案を加えた。Girish の「撤回されたプリンシパル」の文言は Section 5 に入る。

• 証拠が最大経過時間ちょうどの場合の結果を定める必要がある監査記録検証の実装者。
• 報告が遅れ、報告時点で測ると古く見えてしまう判断ポイント。

このスレッドでは、AAT の Niki と Cred-02 の Kieran が、レジストリ上の各名前は単一のエントリにすべきだという点で一致しており、残る論点は del_max_depth の解釈である。ルートの del_max_depth が 8 の場合、AAT は del_depth 8 の末端を受理する（テストベクタ J.10.f）が、Asor 形式は拒否する。さらに Niki は、保持者が del_max_depth 2 で再委任した場合、AAT は深さ 3 のトークンを拒否するが、Asor はルートの 8 に対してのみ検査すると指摘し、共通定義はこの上限を維持すべきだとする。Rob もこれを支持する。Kieran は Asor のエントリに傾いているが、どちらに決まるかよりテストベクタの調整を重視している。Niki はこの上限の事例を追加する。Kieran は、チェーン全体の予算には Cred-02 の Delegation Server の台帳のような単一の書き込み元が必要であり、オフライン減衰とは補完関係にあるとする。失効については、AAT 9.8 節の補助文書で、Cred-02 の 7 節と比較できる形で執行点の鮮度の上限を明記するよう求めている。Rob は、各ドラフトが要求全体のダイジェストに束縛された末端を表現できるかを比較表に記録するよう求めている。Niki は IETF 127 までに比較を用意し、サンフランシスコでのサイドミーティングを確認した。

• ルートの最大深さにある末端を受理するか拒否するかを決める必要がある、エージェント委任の実装者。
• 委任トークンの失効を、執行点で一定時間内に確実に反映させたい運用者。
• 特定の受取人と金額のような単一の操作に委任トークンを束縛する必要がある、人間承認ワークフロー。

このレビューは主に編集上の指摘であり、実装者向けの明快な手引きだと評価している。Key Characteristics の段落を分けることを求めている。セキュリティの観点では、WPT の有効期間内に jti が未使用であることの検査が、なぜ MUST ではなく RECOMMENDED なのかを問う。また、example.com/myclaim のようなクレーム名について、衝突耐性という語は通常ハッシュ関数に使われるため、何を意味するのかを尋ねている。まだ本文の変更はない。

• ドラフトが推奨にとどめている WPT の jti 再利用検出を、強制するかどうか判断する実装者。

AUDIT BoF の提案者を代表して Henk が、OAuth WG が自律エージェントの認可と委任を含むようにチャーターを改定したことは、IETF 127 の AUDIT BoF と相性が良いと述べている。AUDIT WG が再利用できる具体的な記録フォーマットを OAuth WG が作る予定があるかを尋ね、BoF の方針は既存の記録フォーマットをできるだけ再利用することだとしている。WG の専門家にクロスレビューと意見を求めている。回答は含まれず、文書の変更もない。

• 誰がどの操作を認可したかを監査に使えるようにしたい、エージェント認可ドラフトの著者。

AAT、Asor の agent_delegation 形式、Cred -02（Delegation Server 方式）の整合が議論されている。Niki は、ルートより小さい del_max_depth を設定した保持者（ルート 8、保持者 2）は配下全体の深さを制限できるべきで、深さ 3 のトークンは拒否されると主張する。Asor はルートの 8 に対してのみ深さを検査する。Kieran は、del_depth がルートの最大値に等しいリーフを AAT（J.10.f）は受理し、Asor の意味論では拒否される点を指摘し、テストベクターの調整を求めている。Rob はこの制限を維持すべきだとし、各ドラフトがリクエストのダイジェストにリーフを束縛できるかを比較表に記録するよう求めた。Kieran と Rob は、AAT 第 9.8 節の補足文書に失効状態の鮮度の上限を明記することを望んでおり、Cred -02 第 7 節と比較できる表現が望ましいとしている。Niki は比較表の作成とサイドミーティングを確認した。ソースは途中で切れているため、以前のメッセージは一部しか見えない。

• ルートの最大深さにあるリーフを有効とするか判断する必要がある、委任チェーン検証器の実装者。
• より広い委任許可の中で、人による承認を一つの具体的な操作に束縛したい運用者。
• 失効状態をどの程度新しく保つべきかを定める必要がある、実施ポイントの実装者。

• 関連: IETF WIMSE: draft-asor-wimse-agent-delegation-chain. agent_delegation 形式と del_max_depth のレジストリ項目が、AAT との比較対象になっている。
• 関連: IETF WIMSE: draft-sweeney-wimse-credential-delegation. Cred -02 は Delegation Server の台帳と失効の限界の観点で議論され、DS 外で検証されるトークンには Asor 形式をそのまま採用している。

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 節を引用している。

このレビューは、序論の第一文に at the transport layer を加えることを提案している。3.2 節の前に、証明書に結び付いた鍵ペアでワークロードを認証することについての節（ワークロードが期待される鍵ペアと照合する場合のプロビジョニングを含む）を追加することも勧めている。5.1 節では、サーバーがワークロード識別子の名前だけでなく、資格情報と鍵ペアで認証されるよう文言を改めることを提案している。さらに、mTLS を行うサーバーは、クライアント証明書チェーン、トラストドメイン、Workload Identifier に加えて鍵ペアも検証しなければならない（MUST）とする案を示している。これらの変更により、WGLC が可能になると見ている。

• 証明書チェーンや識別子の検査に加え、証明書の鍵の所有証明も認証の一部であると仕様に明記してほしい mTLS の実装者。

Sankalp Gilda は Wes、Blake、Kieran、Girish への返信で、鮮度の境界は「ちょうど到達した時点で失効」であることに同意している。つまり入力の経過時間が maxAge 未満である間のみ有効とする。draft-gilda-audit-agent-audit-record の次の改訂版（-03 の次）にこれを明記し、ちょうど maxAge の古さの入力を持つテストレコード FR2 は拒否ケースになる。さらに、任意の decision.evaluatedAt を設けることを提案している。存在する場合はそこで経過時間を測り、なければ decision.reportedAt で測る。報告が遅れる判定点について、境界の両側にテストレコードを追加する予定である。Girish の文言「an issuer or a principal whose standing is withdrawn」は Section 5 に取り入れ、撤回されたプリンシパルのレコードも追加する。また Wes に、-06 の Section 3 と 3.2 の本文を送るよう依頼している。-05/-06 がどのドラフトを指すかはメッセージからは分からず、WG ドラフトの本文変更もない。

• 監査・エビデンス検証器の実装者が、maxAge ちょうどの入力を受理するか判断する場合。
• 判定結果の報告が遅れる判定点で、報告時刻ではなく評価時点で経過時間を検査する必要がある場合。

唯一の指摘は 5 節の最終段落に関するものである。末尾の credentials を WIMSE workload credentials に改め、[WIMSE-CREDENTIALS] の資格情報形式を指すことを読者に分かるようにすることを提案している。それ以外は良く書けた文書と評価している。用語の修正であり、プロトコルの変更はない。

このダイジェストはGitHub上の活動一覧のみで、仕様本文は含まれない。draft-ietf-oauth-client-id-metadata-documentでは11件のissueがクローズされた。内訳には、private_key_jwtにおけるtoken_endpoint_auth_method（#100）、token_endpoint_auth_method省略時のガイダンス（#92）、未対応メタデータ値（#71）、ASのエラー返却（#85）、ルートパスのURL禁止（#86）、logo_uriのdata URI（#19）が含まれる。新規issue #131は、response_typesの積集合により、本来使えるトークンエンドポイントのグラントが拒否されると指摘している。PRは3件作成され、PR #99（Add Client Authentication section）にコメントが付いた。oauth-identity-assertion-authz-grantでは、mcguinnessが#160（sender-constrained ID-JAGは必須のクライアント認証を置き換えるべきでない）と#159（7.2節と8節がjwt-bearerを要求しjwt-dpopに言及していない）を起票した。oauth-sd-jwt-vcでは新規PRが7件あり、PR #450（Mike Bishop's ballot）にコメントが付いた。oauth-v2-1のPR #268（OAuth 2.0クライアントと2.1クライアントの併存対応）には3件のコメントがあった。oauth-transaction-tokensでは新規PRが1件あった。クローズの理由やPRの内容はダイジェストからは分からない。

• client ID metadata documentを実装する認可サーバーの開発者は、クライアント認証とresponse_typesの扱いの規則がまだ変わりつつあるかを把握できる。
• DPoPの利用を予定しているID-JAGグラントの実装者は、jwt-dpopの欠落とクライアント認証に関する#159と#160を注視すべきである。

このメッセージは draft-williams-oauth-poi-core-00 の著者に宛てたもので、新規ドラフト告知のスレッドに付いている。送信者は、PoI Core のアテステーションが RATS の EAT プロファイルである draft-yossif-psea のトークンに近いと述べている。PSEA では、登録済みの承認者の認証器が、ユーザー検証の後に、対象操作のパラメーターを RFC 8785 で正規化した形の SHA-256 に対して署名する。送信者は 31 件の公開適合テストケースと、それを再現する独立した検証実装が一つあると述べている。PSEA は、リソースサーバーが承認を要求する方法やクライアント鍵の証明方法を定めていないが、PoI Core はその両方を定めている。そのため送信者は、PoIE が独自のアテステーションを定める代わりに PSEA トークンを運ぶ案を示し、適合するか確認する意向を著者に尋ねている。ドラフト本文は資料に含まれないため、PoI Core についてこれ以上のことは述べない。

• 特定の操作（例えば支払い）についてユーザー検証付きの承認をリソースサーバーが求める場合に、独自のアテステーション形式と既存の EAT プロファイルのどちらを使うか選ぶ場面。
• ドラフト固有のアテステーション形式ではなく、共有された適合テストケースに基づいて検証実装を作りたい実装者。

ダイジェストによると、draft-ietf-wimse-s2s-protocol に新規 issue が五件立っている。うち二件は draft-ietf-wimse-http-signature-08 に関するもので、テストベクターの要望（#419、コメント四件）と、例中のサンプル nonce が例示用でありエントロピーの下限を満たさないという注記の提案（#420）である。他の二件は HTTP-Sig と workload-creds の各ドラフトに対する編集上のコメントの追跡用 issue（#417、#418）である。#416 は、トラストドメイン間でトラストアンカーを共有する場合に name-constrained な発行 CA を必須とすることを提案している。同じ作成者が #370（trust root の重複、workload-creds と mutual-tls のラベル付き）と arch の PR #142（Terminology）にもコメントしている。#414（Reconcile Coexistence）にはコメントが一件付き、PR #415 は綴りの誤り三件を修正する。ダイジェストにはタイトルとコメント数しかなく、提案された文言や決定内容は読み取れず、ドラフト本文の変更もない。

• WIMSE の HTTP メッセージ署名を実装し、相互運用性の検証用にテストベクターを待っている実装者は、issue #419 を追うとよい。
• 複数のトラストドメインがルート CA を共有している環境の運用者は、name-constrained な発行 CA が必須になるかどうかについて issue #416 と #370 を追うとよい。

投稿者は、req_wl が必須クレームであるにもかかわらず、IANA の節の JWT Claims Registry Contents には tctx と rctx しか載っていないことに気付いた。この PR はその登録を追加する。IANA 考慮事項の修正であり、トークン形式や処理は変わらない。