議論 11月13日
evidence-binding の著者らは、停止された先行アクターに関する記述を RFC 8693 第4.1節と矛盾しないよう限定することにした。 Shameer は Mikhail の二点の指摘を受け入れた。Serving Party が先行アクターの停止を理由に呼び出しを拒否できないという記述は広すぎた。RFC 8693 第4.1節が排除しているのは入れ子の act クレームをその判断に用いることであり、別途検証された委任トークンの利用ではない。文言は「先行アクターがその後停止されたことを、入れ子の act クレームに基づいて理由に呼び出しを拒否することはできない」に改められる。「完全でも証拠でもない」という履歴に関する表現は、「それ自体では完全であること、あるいはいずれかのホップが権限を保持または縮小したことを立証しない」に置き換えられる。どちらの修正も SCITT ドラフトと Evidence Binding ドラフトの次版に反映される。このメッセージ自体にドラフト本文は含まれていない。
New I-D: draft-thaha-wimse-agent-evidence-binding-00 (evidence binding for AIMS audit)
影響を受ける人 入れ子の act クレームではなく検証済み委任トークンを用いて、停止された先行アクターを理由に呼び出しを拒否できるか判断する Serving Party。 関連: OAuth WG : draft-ietf-oauth-transaction-tokens. 弱い関連のみ。いずれもホップ間の委任コンテキストを扱うが、資料に直接の言及はない。 議論 11月13日
AIMS と MBA のスレッドで、有効期限は「到達時点で無効」とする排他的ルールに揃え、信頼ドメインをまたぐ場合に限り委任主体の値の書き換えを許す方向で合意した。 参加者は「到達時点で無効」の境界規則を採用することで一致した。年齢が S に等しい状態は失効扱いとなり、permit は有効期限の時点以降は使用できない。S = L = 300,000 ms の例では、クロックスキューと猶予がゼロの前提で、新規受理は as-of + S + L より厳密に前に制限される。ただし受理済みの処理の完了までは制限しない。MBA に対して同じ検証ハーネスを at-or-past の期待値で実行すると、22 ケース中 15 件が一致し 7 件が相違した。相違は主に MBA が等値で包含的に比較する箇所であり、欠陥ではなく規約との差異とされている。別件として、Marc と Kieran は、委任主体の値は同一信頼ドメイン内では同一に保ち、ドメインをまたぐ場合は書き換えを認めることで合意した。Marc は、その対応関係を書き換えを行うサーバーの改ざん検知可能な監査記録に残すことを PR #176 で提案する意向である。
Subject: AIMS-00: multi-hop delegation context across agent, tool and resource boundaries
影響を受ける人 permit やトークンの有効期限検査で、境界との等値を失効とみなすか判断する実装者。 委任主体の識別子を書き換えつつ監査可能性を保つ必要があるドメイン間エージェントゲートウェイ。 議論 11月13日
IETF 127 ハッカソンの WIMSE エージェント呼び出しチェーン相互運用計画に対し、失効とフェイルクローズを中心とした異常系シナリオが提案された。 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 は、確定した失効、期限切れのステータスキャッシュ、利用不能なステータスサービスをログ上で区別すること、また失効した認可では効果が生じる前に操作が阻止されることを求めている。
IETF 127 Hackathon: WIMSE interop scenarios for agent call chains (5 new messages)
仕組み 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 への移行にアイデンティティチェーニングを用いる。 議論 11月12日
credential-delegation の-03では、累積予算の集計の限界と、ユーザー発行グラントのステータス所在を扱う予定である。 CalebはKieranのレビュー項目1、4、6と、ユーザー発行ルートをチェーン形式と組み合わせるjti-as-rootの形を受け入れた。-03に向けて、検証者ごとに保持する集計は検証者単位の合計しか制限せず、全体では制限できないため、累積予算には全ての行使を見る単一の書き込み元が必要であることに同意している。また、ユーザーはステータスエンドポイントを運用できないため、グラントがステータスの所在を示す必要があるという指摘も認め、本文を用意するとしている。引用された先行メッセージでは、Robがルートの発行者と、人が承認したことの証拠を分けるよう提案し、Section 7に停止中の行為を検証者がどう見るか、復旧した委任が同一のグラントかを記すよう求めた。Kieranは-02のSection 7は失効のみを扱うと述べている。
draft-sweeney-wimse-credential-delegation-02
影響を受ける人 複数の検証者にまたがる累積の支出や呼び出し予算を強制する委任クレデンシャルサービスを構築する場合。 ステータスエンドポイントを置くサーバーがない、ユーザー直接発行の委任ルートを発行する場合。 議論 11月12日
複数ホップ委任のスレッドで、状態の経過時間と許可の有効期限に排他的な「at-or-past」規則を使う方向で合意した。 Mikhailは10月23日の例を排他的な限界値に改めることに同意した。すなわち、経過時間がSに等しい状態は古いものとして扱い、許可は有効期限の時点以降は使えず、発行には発行時刻より後の許可期限が必要である。最終発行時点でSを強制し、許可の有効期間をLで制限すれば、ゼロのクロックスキューと猶予を仮定して、新規の受理は元のas-of + S + Lより厳密に前に限られる。ただし受理済みの作業の完了は制限されない。MBAのコミットea1a149に対して同じハーネスを再実行すると22件中15件が一致し7件が異なった。差異はMBAが等値を包含的に比較する箇所にあり、欠陥ではなく規約との違いだと述べている。引用されたMarcのメッセージでは、信頼ドメインをまたぐ際に委任された主体の値を変換して記録する場合、変換前後の値とサーバーの識別子を改ざん検知可能な監査記録に残せばよいかをKieranに確認し、PR #176への二つの修正を提案している。
Subject: AIMS-00: multi-hop delegation context across agent, tool and resource boundaries
影響を受ける人 許可やミッション束縛認可の期限検査を実装する際、有効期限と等しい時点を期限切れとして扱う必要がある場合。 古さと期限のテストベクターを書き、独立した実装が等値の境界で同じ結果になるようにする場合。 リクエストが信頼ドメインをまたぐ際にサーバーが書き換える主体識別子をどう記録するかを決める場合。 議論 11月12日
Mikhailは、過去のアクターが停止されたことを理由に呼び出しを拒否できないとする記述の修正を、エビデンス束縛ドラフトの著者に求めた。 KieranはRFC 8693 Section 4.1により、入れ子のactクレーム内の過去のアクターはアクセス制御の判断に使えないという読みを認め、著者は-02でこれを取り入れるとしている。Mikhailは、SCITT -02の本文が依然として、過去のアクターが停止されたことを理由にServing Partyが呼び出しを拒否できないと記している点を指摘した。別途検証された委任トークンは別の根拠となる。draft-asor-wimse-agent-delegation-chain-03形式のチェーンはホップごとに検証され、ステップ7では、受け入れたステータス応答がいずれかのトークンを失効としていれば、ステータスリストの鮮度の範囲内で拒否される。そこで、拒否できないのは入れ子のactクレームに基づく場合に限るという文言と、履歴が完全でも証拠でもないという表現の修正を提案している。
New I-D: draft-thaha-wimse-agent-evidence-binding-00 (evidence binding for AIMS audit)
仕組み 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. 委任チェーンドラフトのステータス参照と鮮度は、ステータスリストの応答に対して確認される。 議論 11月11日
AIMS のドメイン間ギャップの記述：発行者の信頼は認可を決めないこと、判断には有効期限があることを限定する文を加える方向で一致 このスレッドは、信頼ドメイン間の信頼に関するギャップを AIMS に記録するという David Croston の提案の続きで、機構に依存しない性質の一覧（二者間の設定なしに他ドメインの発行者を信頼できる、発行者は自身の名前についてのみ発言できる、検証者が受け入れるドメインを選ぶ、失効の時間的上限）が示されている。Jiahui Miao は、他ドメインの発行者を受け入れてもそれだけでは操作の認可は確立されないという限定的な性質を加えた。ShaoBao Li は、判断は観測時点で成立し、証拠の失効後は成立しないという時間面を加えた。Cliff は、ギャップ記述に一文、残り（「不許可」ではなく「未判定」と記録する規則を含む）を Section 10.4 に置くことに同意した。Sriram Shankarlingam も賛成し、自身の DNS リンクトークンは何も許可しないと述べた。複数のメッセージが著者自身のドラフトや適合性テストを引用している。
AIMS -01: upstream authorities for Workload Identity Certificates (trust between trust domains) (6 new messages)
影響を受ける人 二者間の信頼バンドル交換がない組織間でエージェントをフェデレーションする場合。 権限を判定できず拒否した場合と、操作が許可されず拒否した場合を監査で区別する必要がある場合。 関連: OAuth WG : draft-ietf-oauth-spiffe-client-auth. 関連は緩やか（ワークロード識別子と OAuth クライアントの結び付け）で、資料は引用していない。 議論 11月11日
短い返信：act は帰属情報であり、ポリシー入力ではない。evidence-binding の著者が -02 で反映する 件名は draft-thaha-wimse-agent-evidence-binding-00 の告知だが、ファイルにあるのは Mikhail への Kieran の返信のみである。Kieran は先の「ポリシー入力」という説明が誤りだったと認めた。RFC の Section 4.1 は過去の行為者をアクセス制御の判断から除外しており、過去の行為者を拒否リストに載せることはそれと矛盾するためである。方向 (a) が正しい読みで、Shameer と Shaibi が -02 に取り込む。ホップごとの権限には別途検証された証拠が必要である。告知本文自体はファイルに含まれない。
New I-D: draft-thaha-wimse-agent-evidence-binding-00 (evidence binding for AIMS audit)
議論 11月11日
AIMS の委任スレッド：信頼ドメインをまたぐ場合、対応関係が署名された記録にあれば委任対象の識別子は異なってよい Kieran Sweeney は、「sub の保持」は同じバイト列ではなく同じプリンシパルを指すと明確化した。同一信頼ドメイン内では全ホップで値が同一（sub は固定、行為者は client_id と act）。信頼ドメインをまたぐ場合は、identity chaining による書き換えは、書き換えた当事者が旧値・新値・自身の識別子を署名対象に記録するなら許容される。AS が対応関係を保持するだけでは AIMS Section 11 には不十分である。Marc は PR #176 に同趣旨の二つの修正を提案する。また、鮮度の境界を「期限以降は拒否」に改めることでも合意し、21 件の境界ベクターと 10 月 23 日の文言が変わり、ちょうど S+L で受理されていたケースは拒否になる。
Subject: AIMS-00: multi-hop delegation context across agent, tool and resource boundaries (2 new messages)
仕組み 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 として議論されている。 議論 11月11日
AAT、Asor、Cred -02 の著者が、子トークンのより小さい del_max_depth を尊重すべきことで一致し、IETF 127 前に制約を比較する 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 日にサンフランシスコでサイドミーティングを開く。
AAT -02 announcement (2 new messages)
影響を受ける人 減衰する委任トークンの実装者が、最大深度にある末端を受理すべきか知る必要がある場合。 受取人と金額のように、承認を一つの具体的な操作に束縛する必要がある人間承認のフロー。 関連: OAuth WG : draft-ietf-oauth-transaction-tokens. 資料中では参照されていない。 議論 11月11日
Cred 委任 -02 のレビュー：-03 に向けた論点はユーザー発行ルート、集計モード、失効ステータス 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 で一時停止と復元を扱うことを提案した。
draft-sweeney-wimse-credential-delegation-02 (2 new messages)
仕組み 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. 資料中では言及されていない。 議論 11月10日
agent-mandate ドラフトでは、未使用トークンの除外を、確認がないことではなく積極的な証拠がある場合に限るべきだとの指摘 Dmitri Chistyakov が draft-hulea-wimse-agent-mandate-01 の Section 9.5 にコメントした。同ドラフトは、解決できないステータスを不確定として扱い既定で拒否するが、トークンが未使用のまま失効した場合は RP が累積上限への寄与を削除してもよい(MAY)としている。寄与はトークン発行時に記録される(Section 10.2)が、トークンが未使用だったことを RP がどう知るのかは書かれていない。実行確認の欠如や遅延から未使用と判断すると、実際に実行された操作の寄与を削除してしまい、予算が過小に数えられ、後続のリクエストが sum_max の検査を誤って通過し得る。提案は、RP のポリシーまたは Trust Framework で信頼される積極的な証拠(例えばリソースサーバーがそのトークンを受理していないと述べる声明)がある場合に限って削除を認め、確認の欠如は証拠に当たらないとするものである。証拠がなければ寄与は記録されたままとなり、期間ウィンドウから外れるまで不要な拒否が生じ得る。送信者は、このメッセージが AI の支援を受けて作成されたと述べている。これはレビューコメントであり、ドラフト本文の変更ではない。
draft-hulea-wimse-agent-mandate-01, Section 9.5: tokens that "expire unused"
仕組み 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 に定める場合。 議論 11月10日
レビュアーが、5.4節のエントリは効果発生時ではなく評価時点のみを表すと明記するよう求めている Cliff は、Marc の不正形式のケースと併せて、任意の decision.evaluatedAt フィールドを追加することに賛成している。ただし、評価時点での鮮度と効果発生時点での鮮度の差は、これだけでは解消しないと指摘している。レコードには既に effect.interval.openedAt があるため、読み手は効果開始時点での入力の経過時間を計算できる。そこで、5.4節に「エントリは評価時点のみを表す」という一文を加えることを求めている。また、standing が evaluatedAt 時点では新鮮だが openedAt 時点では maxAge を超えているテストレコードを、整形式として受理するよう求めている。投稿はドラフト名を示しておらず、スレッドの前後の文脈も含まれないため、元の提案は一部しか分からない。
A principal-standing name for the 5.4 closed set
影響を受ける人 判断レコードを検証する実装者は、効果発生時点で入力が古い場合に、そのレコードを不正形式として扱うのか、参考情報にとどめるのかを知る必要がある。 レコードから行為を再構成する監査担当者は、evaluatedAt を効果発生時点の鮮度の証拠とみなさず、effect.interval.openedAt から効果開始時点の入力の経過時間を計算したい。 議論 11月9日
監査記録のテストコーパス：ちょうど maxAge の入力は失効扱いとし、任意の decision.evaluatedAt を提案 Sankalp Gilda は鮮度の境界を「期限以降は失効」とすることに同意した。draft-gilda-audit-agent-audit-record の次の改版では、入力の経過時間が maxAge 未満の間のみ有効とし、ちょうど maxAge のテストレコード FR2 は拒否ケースになる。記録には decision.reportedAt しかないため、任意の decision.evaluatedAt を提案し、存在すればそこで、なければ reportedAt で経過時間を測る。境界の両側のテストレコードも追加する。Marc はこれを支持し、公開コミットメントに基づく standing は判断時点での経過時間に依存すると述べ、evaluatedAt が reportedAt よりスキュー許容を超えて後なら不正として拒否する案を加えた。Girish の「撤回されたプリンシパル」の文言は Section 5 に入る。
A principal-standing name for the 5.4 closed set (2 new messages)
影響を受ける人 証拠が最大経過時間ちょうどの場合の結果を定める必要がある監査記録検証の実装者。 報告が遅れ、報告時点で測ると古く見えてしまう判断ポイント。 議論 11月9日
AAT、Asor、Cred-02 の著者らが del_max_depth の意味の一本化と制約比較を IETF 127 に向けて進めている。 このスレッドでは、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 までに比較を用意し、サンフランシスコでのサイドミーティングを確認した。
AAT -02 announcement
影響を受ける人 ルートの最大深さにある末端を受理するか拒否するかを決める必要がある、エージェント委任の実装者。 委任トークンの失効を、執行点で一定時間内に確実に反映させたい運用者。 特定の受取人と金額のような単一の操作に委任トークンを束縛する必要がある、人間承認ワークフロー。 議論 11月9日
Kathleen による draft-ietf-wimse-wpt のレビューは、jti の再利用検査がなぜ RECOMMENDED なのかと、衝突耐性のあるクレーム名の意味を問うている。 このレビューは主に編集上の指摘であり、実装者向けの明快な手引きだと評価している。Key Characteristics の段落を分けることを求めている。セキュリティの観点では、WPT の有効期間内に jti が未使用であることの検査が、なぜ MUST ではなく RECOMMENDED なのかを問う。また、example.com/myclaim のようなクレーム名について、衝突耐性という語は通常ハッシュ関数に使われるため、何を意味するのかを尋ねている。まだ本文の変更はない。
Review of draft-ietf-wimse-wpt
影響を受ける人 ドラフトが推奨にとどめている WPT の jti 再利用検出を、強制するかどうか判断する実装者。 議論 11月9日
Marc は、sub が各ホップで保存されるとは、トラストドメインをまたいでも同じ値という意味かを問うている。 Marc は、sub は各ホップで Principal であり元の委任対象のままである、という Kieran の発言を引用している。そのうえで、保存とは、ホップがトラストドメインをまたいで転記された識別子（OAUTH-ID-CHAIN の 2.5 節）を受け取る場合も含め、すべての当事者で同じ sub の値を意味するのかを問う。もう一つの解釈は、各値が同じ User を指し、発行した認可サーバーが 11 節のためにその対応を保持していれば足りるというものである。Nik が AIMS の issue #88 と #90 について、値が当事者間で異なりうる 10.10 節の文案を提案しており、それが Kieran の性質と食い違わないようにするための質問だという。このメッセージには回答は含まれていない。
Subject: AIMS-00: multi-hop delegation context across agent, tool and resource boundaries
影響を受ける人 下流の認可サーバーが同じユーザーに対して別の識別子を発行する、複数ドメインにまたがるエージェント配備。 関連: OAuth WG : draft-ietf-oauth-identity-chaining. このメッセージは、トラストドメイン間で転記される識別子について OAUTH-ID-CHAIN の 2.5 節を引用している。 議論 11月9日
Kathleen による mTLS ドラフトのレビューは、経路検証と名前だけでなく鍵ペアによる認証も扱うよう求め、WGLC が可能との見解を示している。 このレビューは、序論の第一文に at the transport layer を加えることを提案している。3.2 節の前に、証明書に結び付いた鍵ペアでワークロードを認証することについての節（ワークロードが期待される鍵ペアと照合する場合のプロビジョニングを含む）を追加することも勧めている。5.1 節では、サーバーがワークロード識別子の名前だけでなく、資格情報と鍵ペアで認証されるよう文言を改めることを提案している。さらに、mTLS を行うサーバーは、クライアント証明書チェーン、トラストドメイン、Workload Identifier に加えて鍵ペアも検証しなければならない（MUST）とする案を示している。これらの変更により、WGLC が可能になると見ている。
Review of https://datatracker.ietf.org/doc/draft-ietf-wimse-mutual-tls/
影響を受ける人 証明書チェーンや識別子の検査に加え、証明書の鍵の所有証明も認証の一部であると仕様に明記してほしい mTLS の実装者。 議論 11月9日
個人ドラフトでは、ちょうど maxAge の古さの入力を失効扱いにする方針で、著者は任意の decision.evaluatedAt を提案している。 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 ドラフトの本文変更もない。
A principal-standing name for the 5.4 closed set
影響を受ける人 監査・エビデンス検証器の実装者が、maxAge ちょうどの入力を受理するか判断する場合。 判定結果の報告が遅れる判定点で、報告時刻ではなく評価時点で経過時間を検査する必要がある場合。 編集上の変更 11月9日
Kathleen による identifier-04 のレビューの指摘は一点のみで、credentials を WIMSE workload credentials と明記するよう求めている。 唯一の指摘は 5 節の最終段落に関するものである。末尾の credentials を WIMSE workload credentials に改め、[WIMSE-CREDENTIALS] の資格情報形式を指すことを読者に分かるようにすることを提案している。それ以外は良く書けた文書と評価している。用語の修正であり、プロトコルの変更はない。
Review of draft-ietf-wimse-identifier-04
議論 11月8日
WIMSE 週次 GitHub ダイジェスト：HTTP-Sig のテストベクターと nonce の例、共有トラストアンカーに関する issue が新規に立ち、綴り修正の PR が出た ダイジェストによると、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 は綴りの誤り三件を修正する。ダイジェストにはタイトルとコメント数しかなく、提案された文言や決定内容は読み取れず、ドラフト本文の変更もない。
Weekly github digest (WIMSE Weekly GitHub Activity Summary)
影響を受ける人 WIMSE の HTTP メッセージ署名を実装し、相互運用性の検証用にテストベクターを待っている実装者は、issue #419 を追うとよい。 複数のトラストドメインがルート CA を共有している環境の運用者は、name-constrained な発行 CA が必須になるかどうかについて issue #416 と #370 を追うとよい。 実質的な変更 11月7日
AIMS 監査記録向けの AER-1 マッピングで、拒否された判断と評価できなかった判断を区別する方針が固まった。 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 日に投稿される。
draft-zambo-aer1-wimse-mapping-01: AER-1 as a candidate format for AIMS Section 11 audit records
影響を受ける人 AIMS Section 11 向けに改ざん検知可能な監査ログを作成する環境では、ポリシーによる拒否と、ポリシー源や状態源に到達できない、または古い場合とを区別する必要がある。 fail-closed のポリシー判断点は、呼び出し元には一様なエラーを返しつつ、拒否の理由を記録に残せる。 議論 11月7日
AAT と Asor のドラフトで del_max_depth の意味が異なり、保持者が自身より下の深さに上限を設けられる共通定義にする方向で議論されている。 このスレッドは IETF 127 に向けて委任制約のドラフトを比較している。AAT は del_depth がルートの del_max_depth と等しい末端を受理する（テストベクター J.10.f）が、asor -03 は拒否する。Azat の実装報告による二つ目の差異として、ルートの del_max_depth が 8 で保持者が 2 で委任した場合、AAT は深さ 3 を拒否するが Asor は 8 に対してのみ検査する。Niki は共通定義でこの上限を維持すべきだと述べ、Rob Zagarella の新しい返信も同意した。Zagarella はさらに、比較表に各ドラフトが正確なリクエストのダイジェストに末端を束縛できるかを記録すること、および AAT Section 9.8 の補足文書で失効の鮮度の上限を Cred -02 Section 7 と比較可能な形で示すことを求めた。提示された資料は途中で切れている。
AAT -02 announcement
影響を受ける人 オフラインで検証可能な委任チェーンを実装する者は、相互運用性の問題を避けるため、ドラフト間で深さ制限の挙動が同一である必要がある。 新たな人間承認を必要とする環境では、一つの正確なリクエストに束縛された末端が求められる。 議論 11月7日
Rob Zagarella が draft-sweeney-wimse-credential-delegation-02 にコメントし、ユーザー発行ルートでの人間承認の証跡の分離と、停止・復元時の挙動の明確化を提案した。 このスレッドには Kieran Sweeney による -02 の告知が含まれる。このドラフトは、Delegation Server がユーザーの預けた資格情報を保持し、エージェントが委任トークンの下でそれを代理で行使するプロファイルである。主な変更は、サブ委任の交換、トークン内の順位、DS を単一の書き込み元とする累積上限（max_lifetime、max_subtree）、draft-asor-wimse-agent-delegation-chain の agent_delegation 形式を採用したチェーン検証プロファイル、および失効を「閉鎖ではなく無効化」とする整理である。新しい返信で Zagarella は、-03 でルートの発行者と、自然人の承認の証跡（方法と保証レベルのみ）を分けることを提案した。また Section 7 に、停止中の操作が検証側にどう見えるか、復元された委任が同一の許可か新規かを明記し、1時間の上限は露出の上限として示すよう求めた。
draft-sweeney-wimse-credential-delegation-02
影響を受ける人 ユーザーが上流の資格情報を預け、それを露出させずにエージェントへ委任させるエージェント基盤。 Delegation Server から離れた検証側が、ユーザー発行ルートに対する人間承認の証跡を確認する場所が必要となる場合。 関連: OAuth WG : draft-ietf-oauth-transaction-tokens. どちらも呼び出しチェーン上で委任された権限を扱うが、資料に明示的な関連は無く、関連は弱い。 議論 11月7日
http-signature-08 の独立したテストベクターが投稿され、送信側 MUST NOT のパラメータは受信者が拒否すべきとの回答があった Jiahui Miao は draft-ietf-wimse-http-signature-08 向けに、正例 6 件と負例 22 件のテストベクターを投稿した（s2s-protocol リポジトリの issue #419）。各負例はドラフトの MUST に対応付けられ、鍵、署名ベース、固定時計が含まれる。質問は二つで、keyid/alg パラメータを検証者が拒否すべきか無視すべきか、および 64 ビットの最小値を満たさない Section 3.7 の例の nonce に編集上の注記が要るかである。Yaron は、セキュリティ RFC の MUST NOT は受信者が拒否すべきであり、その注記を加える issue を起こしたと回答し、一部のベクターは修正が必要かもしれないと述べた（詳細は issue）。nonce の質問にはこの返信では答えていない。
Test vectors for draft-ietf-wimse-http-signature-08 — request for review
影響を受ける人 不正なリクエストを拒否する相互運用テストを求める WIMSE HTTP メッセージ署名の実装者。 禁止されたシグネチャパラメータを拒否するか無視するか決める検証者。 議論 11月6日
workload-creds に対し、可読性向上の編集提案と、exp の有効期間・deny-list 表現・9.6節の mTLS についての指摘があった。 レビュアーは、抽象で、クレデンシャルがワークロードのアイデンティティを「表す」ではなく「に紐づく」と書き換えることを提案している。WIT（HTTP などのアプリケーション層）と WIC（mTLS などのトランスポート層）の使い分けを、根拠付きの2つの推奨パターンとして書き直すことも提案している。5章には、ロードバランサーで TLS が終端する場合にアプリケーション層のクレデンシャルが改変されずに維持される必要があることの説明を加えるよう提案している。5.1節については、一部で既に5分程度の有効期間が使われていることから exp の「数時間」という目安を短くすべきか、また jti の説明がなぜ allow-list ではなく deny-list なのかを質問している。9.2節には、exp を短くすることがその問題の緩和策であると明記するよう提案している。規範的な修正は9.6節のみで、WIT と PoP を送る「サーバー認証 TLS」接続の要件に mTLS も明記するというものである。WG からの応答はこの資料には含まれていない。
Review of draft-ietf-wimse-workload-creds
影響を受ける人 WIT の有効期間を決める実装者は、WG が exp の「数時間程度」という目安を短くするかどうかに注目するとよい。 サービス間で mTLS 経由で WIT を送る運用者にとっては、9.6節が mTLS をチャネル要件の充足として明記すれば有益である。 議論 11月6日
AIMS -01 のギャップ文に二つの限定文を置き、規則は 10.4 節に置く方向で議論が収束した。 Lee（draft-li-rttp-iqa-addressing の著者）と Jiahui Miao は、AIMS のギャップ文に限定文を一つ置き、判定不能な状態での挙動は受け入れ側ドメイン自身の評価を述べる 10.4 節に置くことで合意した。第一の文は、他ドメインの発行者を受け入れても当該操作の認可が成立するわけではないと述べる。第二の文は、観測された証拠に基づく判定は観測時点で成立し、証拠が失効した後はそれだけでは成立しないと述べる。Lee は自身のドラフトの閉じた五値の拒否語彙と observation_as_of_ms を根拠に挙げている。これは一参加者の提案であり、WG の決定ではない。メッセージは途中で切れており、引用された他ドラフトや適合性サイトは未検証である。
AIMS -01: upstream authorities for Workload Identity Certificates (trust between trust domains)
影響を受ける人 AIMS で認可が未決定のとき、他のトラストドメインの発行者による証明書を検証側がどう扱うかを決める場面。 依拠した証拠の経過時間を含むクロスドメイン受け入れの監査記録を設計する場面。 議論 11月6日
Kathleen Moriarty による workload-creds のレビューは文言の明確化と数点のセキュリティ面の提案を含み、Yaron が issue #418 として登録した。 レビューは、アブストラクトを、クレデンシャルがアイデンティティを表すのではなく紐づくものだと言い換えることを提案する。序文では、WIT は HTTP などのアプリケーション層向け、WIC は主に mTLS のトランスポート層向けだと直接述べることも提案する。5 節ではロードバランサでの TLS 終端がアプリケーション層クレデンシャルを使う理由になると説明することを勧める。5.1 節では exp の「数時間」という目安をより短くすべきか、また deny-list ではなく allow-list としない理由を尋ねる。9.6 節では、サーバー認証のみの TLS に加えて mTLS も許容することを提案する。メッセージは途中で切れており、以降のコメントは確認できない。Yaron は s2s-protocol の issue #418 として登録した。これらは提案であり、採用された変更ではない。
Review of draft-ietf-wimse-workload-creds
影響を受ける人 TLS を終端するロードバランサがある環境で WIT と WIC のどちらを使うか選ぶ場面。 WIT の有効期間や、deny-list と allow-list のどちらでステータスを管理するかを決める場面。 関連: OAuth WG : draft-ietf-oauth-status-list. レビューは WIT のトークンステータスにおける deny-list と allow-list を問題にしており、Token Status List が扱う領域に近い。ただし資料は両ドラフトを結びつけていない。 編集上の変更 11月6日
http-signature の序文について、適用範囲の明示とアプリケーション層で保護する理由の説明を求める文言修正の提案があった。 レビュアーは、この草案が WGLC を過ぎていることを認めた上で、残りの部分は非常に良いと評価している。序文の最初の文に「HTTP」を加え、適用範囲を一文で示すよう提案している。また、序文のアプリケーション層での保護の根拠の説明も書き換えを提案している。新しい文案では、プロキシやミドルボックスで TLS セッションが終端・再開されても、HTTP 署名と JWT により経路全体で一貫した識別子とクレデンシャルを使えることを動機としている。プロトコルの変更提案はなく、WG からの応答もこの資料には含まれていない。
Review of draft-ietf-wimse-http-signature
編集上の変更 11月6日
Kathleen Moriarty による http-signature のレビューは、HTTP を明記した冒頭文と、アプリケーション層保護の理由の明確化を求めており、issue #417 として登録された。 レビューはドラフトが明快で良好な状態だとしている。序文の最初の文に HTTP を加えることを提案し、デプロイ先がアプリケーション層の保護を好む理由の段落の書き換えも提案する。提案文は、TLS がプロキシやミドルボックスなどで終端・再開される複数ホップになり得ること、HTTP 署名と JWT を用いれば経路全体で一貫した識別子とクレデンシャルを保てることを述べる。文言の変更のみでプロトコルは変わらない。Yaron は s2s-protocol の issue #417 として記録した。
Review of draft-ietf-wimse-http-signature