新しい提案 11月13日
Agent Passport の著者が、累積上限・RAR による付与・制約種別ごとの委任レシート縮小規則について -01 の方針を示した。 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日に自身のサイドミーティングを開く予定である。
New draft: Agent Passports and Delegation Receipts (draft-le-agent-passport-00) (2 new messages)
影響を受ける人 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 が著者の委任ドラフトである。著者名のみに基づく推定である。 編集上の変更 11月13日
OAuth 2.1 で Dick と Torsten を著者欄から謝辞へ移す PR が出された。 PR の本文は、Aaron が文書に対して他の誰よりもはるかに多く貢献しており、著者表記もそれを反映すべきだと主張している。不完全な例としてスクリーンショットが添付されている。仕様の本文やプロトコルの挙動は変わらない。議論や結果は資料に含まれていない。
oauth-wg/oauth-v2-1#283: move Dick and Torsten to the acknowledgements
議論 11月12日
AAT-02のスレッドで、行為束縛を持つ葉と別の承認証明を参照する葉を分けて比較し、共有リプレイ状態も記録すべきだとの議論がある。 Mohamad Yossifは、チェーンの葉が特定の1リクエストへの束縛を自身で表現する必要はなく、別の証明のダイジェストを保持するか、jtiで参照すればよいと主張している。draft-yossif-psea-03は、承認者の登録済みデバイスがRFC 8785形式のリクエストのSHA-256に対して署名する証明であり、検証者はリプレイを拒否すると説明している。比較表では「トークン内では表現できない」と「参照により表現できる」を別項目にすることを提案している。Imanはこれに同意し、行為識別子、承認のjti、証明への参照は区別して保持すべきだとしている。またDR-C7が確認するのは同一検証者への2回目の提示のみだと指摘している。さらに、1つの証明を2つの強制点の2つの葉から提示し、完了するのは高々1つであることを確認する新しいテストを提案している。ローカルのリプレイキャッシュが別々では、これは示せない。スレッドにドラフト本文の変更はない。
AAT -02 announcement (2 new messages)
影響を受ける人 エージェント向け認可トークンの作成者が、リクエスト単位の承認をトークン内に持たせるか、外部の証明を参照させるかを決める場合。 同一の検証ドメインに複数の強制点を置く運用者が、リプレイ状態をそれらの間で共有する必要があるかを判断する場合。 議論 11月11日
Kieran が draft-le-agent-passport-00 に回答し、共有上限には集計役が一人必要であり、RAR でルートの受領証を発行できると述べた。 このメールは、新しい Agent Passports and Delegation Receipts ドラフトの未解決の2点について Ben に返信したものであり、資料にあるのは Kieran の返信のみでドラフト本体は含まれない。依拠当事者（RP）間の共有上限の集計について、累積上限には全ての行使を観測する書き込み元が一つ必要であり、別々の RP では合計を保持できないため、受領証が一つの RP を指名するか、呼び出し経路上のいずれかの当事者が累計を保持する必要があるとしている。RAR については、authorization_details を付与に使うことに同意し、既に RAR を扱う AS ならルートの受領証を発行できるとしている。最初に揃えるべきは制約種別ごとの包含規則であり、asor、AAT、Hulea がそれぞれ独自の規則を持つこと、Niki が IETF 127 までに比較を申し出ていることを述べている。
New draft: Agent Passports and Delegation Receipts (draft-le-agent-passport-00)
影響を受ける人 既に RAR に対応しており、authorization_details を使ってルートの委任受領証を発行したい AS。 複数の RP にまたがるエージェントシステムで、共有の支出上限や呼び出し上限をどこで集計するかを決める設計者。 関連: IETF WIMSE : draft-hulea-wimse-agent-mandate. 独自の包含規則を持つドラフトの一つとして名前が挙がっている。 関連: IETF WIMSE : draft-asor-wimse-agent-delegation-chain. 独自の包含規則を持つドラフトの一つとして名前が挙がっている。 議論 11月11日
authorization-evidence で任意の承認者側署名が何を証明すべきかについて、仕組みを選ぶ前に要件を議論している。 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 署名の記録との循環依存を避けるための署名対象バイトの明示的な境界も求めた。比較用のテストケースも提案し、表示の出所が確立されていない有効な署名は別の結果として扱うべきだとした。草案本文の変更はない。
draft-liu-oauth-authorization-evidence-02: an approver-side signature for 9.4
仕組み 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. エージェントの操作に対する署名付き認可証拠レコードを扱う点で共通するが、メール中に言及はなく、主題上の関連にとどまる。 議論 11月11日
draft-liu-oauth-authorization-evidence-02 の 9.4 について、承認者側署名の要件を方式に依存しない形で列挙する案が出された。 Mohamad は GitHub リポジトリへの追加を依頼し（アカウントは MohamadKhalilYossif）、要件を先に定めることに同意している。9.4 については、方式を名指しせず、承認者側署名が満たすべき短い規範的な一覧を提案している。内容は、開示されるバイト列そのものまたはそのダイジェストを対象とすること、登録時に承認者へ束縛された資格情報で作成されること、属する承認を識別できることの3点である。PSEA を含む既存の仕事は参考文献（informative reference）とする。これはリストではなくプルリクエストで送るとしている。メール上の提案であり、ドラフト本文にはまだ反映されていない。
draft-liu-oauth-authorization-evidence-02: an approver-side signature for 9.4
影響を受ける人 エージェントの動作に対する人の承認フローを実装しており、承認者の署名が何を対象とすべきかを知りたい実装者。 要件についてプルリクエストを通じて議論に参加したい、または追いたいレビュアー。 関連: IETF WIMSE : draft-munoz-wimse-authorization-evidence. 署名付き認可証跡という近い題材だが、資料上は両者の関連は示されておらず、比較のための参考にとどまる。 議論 11月11日
Kieran が credential-delegation -02 へのコメントに回答し、累積上限には書き込み元を一つにする必要があること、-02 は一時停止と復元に触れていないことを述べた。 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時間の上限は露出を抑えるが閉じるものではないと認めている。
draft-sweeney-wimse-credential-delegation-02
影響を受ける人 検証者ごとの集計に頼っており、累積上限が別々の検証者をまたいでは強制されないことを知る必要がある運用者。 他所で発行された委任トークンを検証するが、-02 がステータス機構を定めていないため自分で選ぶ必要がある検証者。 関連: IETF WIMSE : draft-sweeney-wimse-credential-delegation. 議論されている -02 の本体のドラフトである。 議論 11月11日
委任チェーン系ドラフトを11月16日のサイドミーティングで比較する予定であり、経路上で最小の del_max_depth が実効上限になるとされた。 Kieran は、子トークンの del_max_depth が親より小さい場合は絞り込みであり検証者はそれに従うべきで、したがって各ホップの実効上限は経路上の最小値になるという Niki と Rob の見解に同意している。これは葉が上限にあるかどうかとは別の問題であり、別々に決めるべきだとしている。比較表に「正確な単一リクエストへの束縛」の行を加えることにも同意しており、自身の -02 は DS で各呼び出しをトークン内の操作と照合するが、葉を一つのリクエストのダイジェストに束縛する制約はないため、現状の記載は「トークン内では表現できない」になるとしている。また 9.8 の鮮度の上限を -02 の Section 7 と同じ用語で記述することにも同意し、Section 5.5 がチェーン形式を参照で取り込んでいるため、DS から離れて検証されるトークンについての -02 の記載は暫定として扱うよう求めている。引用された Niki のメッセージは、11月16日（月）11:15〜12:15 PST に Continental 7 と Webex でサイドミーティングを開き、委任チェーン系ドラフト間の整合を議題とすることを知らせている。
AAT -02 announcement
影響を受ける人 子トークンが del_max_depth を絞り込む場合に実効的な深さ上限をどう計算するかを決める、委任チェーン検証者の実装者。 チェーン系ドラフトを比較しており、11月16日のサイドミーティングへの参加を考えている著者やレビュアー。 関連: IETF WIMSE : draft-sweeney-wimse-credential-delegation. Kieran が述べる -02（Section 5.5、7）はこのドラフトである。 関連: IETF WIMSE : draft-asor-wimse-agent-delegation-chain. 項目3で、制約種別ごとに独自の包含規則を持つドラフトの一つとして挙げられている。 実質的な変更 11月10日
oauth-delegate-sd-jwt で、cnf、exp、nbf などのセキュリティクレームが delegate_payload からベースの KB-SD-JWT ペイロードへ移り、意味も定義される。 #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 の説明のみで、差分は確認できていない。
oauth-wg/oauth-delegate-sd-jwt#15: Move security claims to base KB-SD-JWT payload and define claim semantics
影響を受ける人 委任されたプレゼンテーションの cnf や有効期限を、委任固有の展開処理なしに既存の SD-JWT KB 検証で確認したいライブラリ実装者。 クレデンシャルを別のホルダーへ再委任するエージェントが、audience と nonce の意味を明確にする必要がある場合。 議論 11月10日
AUDIT BoF の提案者が OAuth WG に再利用可能な認可レコード形式を作る予定があるか尋ね、ある参加者が AUDIT WG 設立に繰り返し反対した。 Henk Birkholz は、OAuth WG が自律エージェントの認可と委任を対象に再チャータされたことに触れ、提案中の AUDIT WG が再利用できる具体的なレコード形式やログアーティファクトを作る予定があるかを尋ねた。IETF 127 の BoF は既存形式をできるだけ再利用する方針だという。Heime.Jorgen は、実行前の結合がない事後記録はリプレイや TOCTOU 攻撃を招き、チャーターは RFC 5434 の基準を満たさないとして繰り返し反対し、実行前シールや実行ノンスのための拡張スロットを求めた。Mirja Kuehlewind は、反対意見は記録済みであり繰り返す必要はないと返した。この資料では OAuth WG の参加者による Henk の質問への回答はなく、ドラフト本文も関与しない。
OAUTH record formats & the AUDIT BoF (4 new messages)
影響を受ける人 エージェントの認可・委任ドラフトの著者が、自分たちのレコードを監査証拠として使えるようにするよう求められる可能性がある場合。 関連: IETF WIMSE : draft-munoz-wimse-authorization-evidence. エージェント操作の署名付き認可証拠レコードは、AUDIT BoF が問うレコード形式に該当する。 議論 11月10日
認可サーバーの承認記録は OAuth、承認者の署名は RATS に置き、AUDIT がその参照方法を規定する分担案がメーリングリストに投稿された。 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 の元の質問は確認できない。
OAUTH record formats & the AUDIT BoF
仕組み 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 から参照するのかを知りたい場合。 議論 11月10日
authorization-evidence ドラフトの著者は、-02 が承認者側署名の仕組みを意図的に未定義とし、まず証拠モデルでの合意を優先すると回答した。 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 リポジトリへの参加も提案した。ドラフト本文の変更はない。
回复：draft-liu-oauth-authorization-evidence-02: an approver-side signature for 9.4
影響を受ける人 エージェントの操作に対するユーザー承認を記録する AS が、サーバーだけでなく本人が承認したことを後から示す必要がある場合。 承認者が署名したダイジェストを、AS が記録した disclosure オブジェクトと照合したい検証者。 関連: IETF WIMSE : draft-munoz-wimse-authorization-evidence. エージェント操作に対する署名付き認可証拠レコードを定めており、同じ問題領域を扱う。 実質的な変更 11月9日
この PR は SD-JWT VC の型を発行者が vct と aka_vcts で表明したものに限定し、extends に基づく照合を削除する。 -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 月末に日付付きドラフトを引用する予定であることを述べている。
oauth-wg/oauth-sd-jwt-vc#457: Clarify that the types of an SD-JWT VC are those asserted in vct and aka_vcts
影響を受ける人 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 を照合し、型の拡張は帯域外の知識として扱うと述べている。 新しい提案 11月9日
PoI Core の著者が、Proof-of-Intent Envelope にデバイスバインドの証明として PSEA トークンを載せる方針に同意した。 このメッセージは、新規ドラフト 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 のサンプルトークンを求めている。まだ仕様化されておらず、初期段階の整合の議論である。
New Draft: draft-williams-oauth-poi-core-00 (Proof-of-Intent Core)
仕組み 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）。 新しい提案 11月9日
承認者自身の署名を持つ PSEA トークンを authorization_evidence の任意メンバーとして加える提案で、AS が提示したと記録する内容に承認者の鍵の署名を付ける。 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 に対する実例の提供を申し出ている。
draft-liu-oauth-authorization-evidence-02: an approver-side signature for 9.4
仕組み 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. エージェント操作に対する署名付き認可証跡レコードを定義する別ドラフトだが、このメッセージでは言及されていない。 議論 11月9日
AUDIT BoF の提案者が、AUDIT で再利用できる認可状態の記録フォーマットを OAuth WG が作成する予定かを尋ねている。 AUDIT BoF の提案者を代表して Henk が、OAuth WG が自律エージェントの認可と委任を含むようにチャーターを改定したことは、IETF 127 の AUDIT BoF と相性が良いと述べている。AUDIT WG が再利用できる具体的な記録フォーマットを OAuth WG が作る予定があるかを尋ね、BoF の方針は既存の記録フォーマットをできるだけ再利用することだとしている。WG の専門家にクロスレビューと意見を求めている。回答は含まれず、文書の変更もない。
OAUTH record formats & the AUDIT BoF
影響を受ける人 誰がどの操作を認可したかを監査に使えるようにしたい、エージェント認可ドラフトの著者。 議論 11月9日
AAT のスレッドは del_max_depth の意味を一つにまとめる方向で進み、IETF 127 までに委任チェーン系ドラフト三件の比較が用意される。 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 は比較表の作成とサイドミーティングを確認した。ソースは途中で切れているため、以前のメッセージは一部しか見えない。
AAT -02 announcement
影響を受ける人 ルートの最大深さにあるリーフを有効とするか判断する必要がある、委任チェーン検証器の実装者。 より広い委任許可の中で、人による承認を一つの具体的な操作に束縛したい運用者。 失効状態をどの程度新しく保つべきかを定める必要がある、実施ポイントの実装者。 関連: 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 形式をそのまま採用している。 議論 11月8日
週次ダイジェスト: client-id-metadata-documentのissue大量整理、ID-JAGの新規issue2件、sd-jwt-vcのPR複数。 このダイジェストは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の内容はダイジェストからは分からない。
Weekly github digest (OAuth Activity Summary)
影響を受ける人 client ID metadata documentを実装する認可サーバーの開発者は、クライアント認証とresponse_typesの扱いの規則がまだ変わりつつあるかを把握できる。 DPoPの利用を予定しているID-JAGグラントの実装者は、jwt-dpopの欠落とクライアント認証に関する#159と#160を注視すべきである。 議論 11月8日
Proof-of-Intent Core ドラフトのアテステーションに PSEA トークンを使う案が提案された。 このメッセージは 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 についてこれ以上のことは述べない。
New Draft: draft-williams-oauth-poi-core-00 (Proof-of-Intent Core)
影響を受ける人 特定の操作（例えば支払い）についてユーザー検証付きの承認をリソースサーバーが求める場合に、独自のアテステーション形式と既存の EAT プロファイルのどちらを使うか選ぶ場面。 ドラフト固有のアテステーション形式ではなく、共有された適合テストケースに基づいて検証実装を作りたい実装者。 編集上の変更 11月8日
Transaction Tokens ドラフトの JWT Claims レジストリ登録に、必須の req_wl クレームを追加する PR。 投稿者は、req_wl が必須クレームであるにもかかわらず、IANA の節の JWT Claims Registry Contents には tctx と rctx しか載っていないことに気付いた。この PR はその登録を追加する。IANA 考慮事項の修正であり、トークン形式や処理は変わらない。
oauth-wg/oauth-transaction-tokens#374: Register the req_wl claim in the JWT Claims registry
実質的な変更 11月7日
RFC 10070 が発行され、アサーションベースのクライアント認証とグラントにおけるオーディエンス値について RFC 7521、7522、7523、9126 を更新した。 RFC Editor が RFC 10070 を告知した。Jones、Campbell、Mortimore、Skokan による Proposed Standard で、draft-ietf-oauth-rfc7523bis-11 に基づく。OAuth 2.0 のクライアントアサーション認証およびアサーションベースの認可グラントにおけるオーディエンス値の扱いについて RFC 7523、7521、7522、9126 を更新し、従来のオーディエンス要件にあったセキュリティ上の脆弱性に対処する。告知文には新しいオーディエンスの規則が書かれておらず、必要とされる具体的な値はこの資料からは分からない。
RFC 10070 on Updates to OAuth 2.0 JSON Web Token (JWT) Client Authentication and Assertion-Based Authorization Grants
影響を受ける人 private_key_jwt のクライアントアサーションや JWT ベアラーグラントを受け付け、許容するオーディエンス値を見直す必要がある認可サーバー。 クライアントアサーションを生成し、設定するオーディエンス値を確認する必要があるクライアントライブラリ。 新しい提案 11月7日
人間が取引内容のハッシュに署名し、リソースサーバーが認可サーバーを介さず検証する方式を提案する新規ドラフト draft-williams-oauth-poi-core-00 は Proof-of-Intent を導入する。人間は、RFC 8785 JCS で正規化した取引パラメーターの SHA-256 ハッシュにコミットする Proof-of-Intent Envelope（PoIE）に署名し、リソースサーバー（RS）は署名を検証してその操作だけを実行する。セッションのログイン時に認可サーバー（AS）が RFC 7800 の cnf クレームで短命の Ephemeral Intent Key を証明し、その後はクライアントが RS のチャレンジにローカルで署名するため、実行時のパスに AS は入らない。クライアント側の Signing Vault が RS の署名付き表示情報をユーザーに提示する。RS はセッション鍵による所持証明、プラットフォーム生体認証、FIDO2 クロスプラットフォームハードウェアトークンの三段階の保証レベルから一つを要求する。著者は、承認の結果として AS がより広いスコープのアクセストークンを発行する draft-rosenberg-oauth-aauth と対比している。マルチホップのエスカレーションと並行性を扱う補助ドラフトがあり、参照実装も示されている。
New Draft: draft-williams-oauth-poi-core-00 (Proof-of-Intent Core)
仕組み sequenceDiagram
participant C as Client
participant AS as Authorization Server
participant RS as Resource Server
participant H as Human via Signing Vault
C->>AS: Session login
AS-->>C: Ephemeral Intent Key certified via cnf
C->>RS: Request action
RS-->>C: Signed challenge with display facts
C->>H: Show RS-signed facts
H-->>C: Sign PoIE over hash of transaction
C->>RS: PoIE
RS->>RS: Verify signature and execute that action only 影響を受ける人 請求書の支払いを行うエージェントで、ユーザーが特定の受取人と金額を承認し、エージェントが再利用可能な昇格トークンを保持しない場合。 リソースサーバーが、取引ごとに AS を呼び出さずに、重要な操作の承認を検証したい場合。 価値の高いエージェント操作に対して、WebAuthn によるハードウェア裏付けの承認を求める運用。 関連: IETF WIMSE : draft-hulea-wimse-agent-mandate. どちらもエージェント操作に対する検証可能な人間の認可を扱うが、資料に直接の関連は示されておらず、主題上の参照にとどまる。 議論 11月7日
ゲートウェイ事業者が Identity Continuation Assertion ドラフト (-02) の WG 採用を支持し、未解決の issue 二件に賛成した。 MCP ゲートウェイをエージェントホストと上流 API の間で運用する Runlayer の担当者が、サービス境界をまたぐ IdP 認可の継続を必要とする運用のために -02 の WG 採用を支持した。issue #145 に賛成し、エラーレスポンス (§5.5.6, §6.3) でレート、ファンアウト、ホップ数、アクター系譜の深さの各失敗を区別し、クライアントが回復動作を選べるようにすることを求めた。RAS が CAI も兼ねるゲートウェイでは、受け入れドメインの信頼境界は妥当だとした (§8.1)。また、永続的なルートからの定期的な継続を許容することを条件に、IdP が強制するソースホップ年齢の上限 (#142) を支持した。このメッセージでドラフト本文の変更はない。
New I-D: Identity Continuation Assertion for OAuth 2.0 Token Exchange (request for review)
影響を受ける人 継続が拒否された際に、バックオフ、ファンアウト削減、再認証のどれを行うべきかをエージェントのクライアントに伝える必要がある MCP ゲートウェイ。 長期間有効なルートから定期的にエージェントジョブを実行し、それを妨げないホップ年齢の上限を必要とする運用。 議論 11月7日
Cred 委任ドラフトについて、ユーザー承認の証跡をルートから分離し、停止中の委任に対する検証側の扱いを定めるよう求めるレビュー このメッセージは、Kieran Sweeney による draft-sweeney-wimse-credential-delegation-02 の告知を引用し、Rob Zagarella の返信を加えたものである。引用された告知によれば、Delegation Server（DS）がユーザーの預けた認証情報を保持し、エージェントは委任トークンの下でそれを代理行使する。-02 の変更点には、サブ委任の交換、トークンに含まれる順位、DS を唯一の書き込み元とする delegation_constraints クレーム（max_lifetime、max_subtree）による累積上限がある。DS の外で検証されるトークンには draft-asor-wimse-agent-delegation-chain の agent_delegation 形式をそのまま採用し、失効は「無効化であって終了ではない」とし、トークンの上限を 1 時間とする。Zagarella の返信は二点を述べる。-03 のユーザー発行ルートでは、誰が発行したかと、自然人が承認したという証跡を分け、後者は方式と保証レベル（amr 値など）のみとして生体データは含めないこと。Section 7 では、停止中に行われた操作を検証側がどう扱うか、復元された委任が同一の許可か新規の許可かを明記することである。
draft-sweeney-wimse-credential-delegation-02
影響を受ける人 DS の外にいる検証側が、ユーザー発行ルートを実在の人間が承認したかどうかを判断する必要がある DS 運用者。 委任が復元される直前の操作について、失効や停止の判断を比較する検証側。 関連: IETF WIMSE : draft-sweeney-wimse-credential-delegation. このスレッドでレビューされているのが当該ドラフトである。 関連: IETF WIMSE : draft-asor-wimse-agent-delegation-chain. Cred -02 は DS の外で検証されるトークンにその agent_delegation 形式をそのまま採用している。 議論 11月7日
AAT、Cred、Asor の著者が del_max_depth の意味を一つにすることで一致し、レビュアーがダイジェストに束縛された末端制約の比較を求める これは告知ではなくスレッドであり、取得できた本文は途中で切れている。引用されたメッセージによれば、del_max_depth には一ホップの差がある。del_max_depth が 8 のルートの下で、AAT は del_depth 8 の末端を受理し（テストベクター J.10.f）、Asor -03 の文面は拒否する。Niki Aimable Niyikiza はさらに二つ目の違いを挙げる。保持者が del_max_depth 2 で委任した場合、AAT は深さ 3 のトークンを拒否するが、Asor は深さをルートの 8 とだけ照合する。Niyikiza は共通定義が保持者による上限を維持すべきだとし、Rob Zagarella も、そうでなければ保持者が自身の先の委任を絞れなくなるとして同意する。Sweeney は Asor のレジストリ項目に傾くが、ベクターの整合の方を重視する。Sweeney と Niyikiza は、AAT Section 9.8 の補助文書で、実施点の失効状態がどれだけ新しくなければならないかを明記すべきという点でも一致している。Zagarella は、予定されている制約の比較に、各ドラフトが末端をリクエスト全体のダイジェストに束縛できるかを記録すること、また鮮度の上限を Cred -02 Section 7 と同じ表現で述べることを求めている。
AAT -02 announcement
影響を受ける人 AAT や Asor の委任チェーンを実装し、深さ制限の挙動をライブラリ間で揃えたい実装者。 承認を特定の受取人と金額など一つの正確な操作に束縛し、チェーン上でそれがより広い許可の範囲内にあることを示す必要がある運用。 関連: IETF WIMSE : draft-asor-wimse-agent-delegation-chain. その del_max_depth の意味とレジストリ項目が AAT との相違点である。 関連: IETF WIMSE : draft-sweeney-wimse-credential-delegation. 深さの意味と失効の鮮度の上限について Cred -02 の Section 5.5 と 7 が参照されている。 新しい提案 11月6日
新規の個人ドラフトが Agent Passport と Delegation Receipt を定義し、Token Exchange で発行する draft-le-agent-passport-00 は二種類の署名付きオブジェクトを定義する。Agent Passport は、エージェントの鍵（cnf）を責任を負う組織とビルドのダイジェストに結び付ける JWT である。Delegation Receipt はユーザーからエージェント、サブエージェントへ続く連鎖で、各段は鍵に束縛され、前の段より権限を狭めることしかできない。依拠当事者は連鎖を検証し、ユーザー自身のアクセス権との共通部分を取る。ルートの receipt は RFC 8693 の Token Exchange で取得し、passport を actor token とし、新しい requested_token_type urn:ietf:params:oauth:token-type:agent-delegation を用いる。ステータスは Token Status List ドラフトで表す。未解決の論点は、付与を RFC 9396 の authorization_details の type として表すべきかどうかである。著者は IETF 127 でのサイドミーティングと IPR 開示にも触れ、draft-klrc-aiagent-auth や AAuth を補完するものだと述べている。
New draft: Agent Passports and Delegation Receipts (draft-le-agent-passport-00)
仕組み sequenceDiagram
participant U as User
participant A as Agent
participant AS as Authorization Server
participant RP as Relying Party
A->>AS: Token Exchange, actor_token = Agent Passport
AS-->>A: root Delegation Receipt (agent-delegation type)
A->>A: sub-agent receipt, narrower than parent
A->>RP: passport and receipt chain
RP->>RP: verify chain, intersect with user access 影響を受ける人 RAR に対応済みの認可サーバーが、エージェントへの委任を authorization_details として発行したい場合 組織をまたいで、サブエージェントの権限がユーザーの権限の部分集合であることを依拠当事者が検証する必要がある場合 関連: OpenID : openid/aauth. 著者は、このドラフトは AAuth を補完するものだと述べている。 議論 11月6日
amr-values の議論では、広すぎる bg 値、sna の独立登録、構造化された amr_details クレームが論点になっている Ankit は、Bjorn Hjelm の指摘が issue になったと述べている。device identifier を独立した値とすること（issue 14）と、geo-location を認証手段ではなく文脈として扱うこと（issue 15）である。引用されたやり取りで Bjorn は、bg は sna と変わらず、sna は Number Verify を指す用語としては紛らわしいこと、また device recognition は意味が広すぎることを指摘している。Shankar は bg が広すぎるとして sna を別途登録することを支持し、amr 自体は変えずに、method、channel、mechanism を持つ任意の amr_details 補助クレームを提案している。これにより、メールで配送された OTP のような関係を表現できる。Mike Jones は、ワーキンググループでの議論なしに amr の構造や順序の意味を変えることに異議を述べている。PR #9 と、同期パスキー向けの新しい値 mdc を加える PR #10 が出ている。資料は途中で切れている。
Review of draft-skyfire-oauth-amr-values
影響を受ける人 電話番号をアカウント識別子として使うモバイル中心のサービスが、キャリア支援による検証をその他のバックグラウンド確認と区別する必要がある場合 議論 11月6日
Rob Zagarella による Skyfire の amr-values と id-verification の実装者レビューから、bg、idv_time、RFC 8176 との重複に関する issue が生まれた Ankit は、Rob の指摘のうち二点が issue になったと報告している。結合された bg を device identifier と geo-location の二つの issue に分けること、そして検証時刻を表す idv_time の意味である。引用されたレビューは、新しい amr 値ごとに、既存の RFC 8176 の値（face と facliv など）を特殊化するのか、拡張するのか、無関係なのかを一行で示すことと、facliv の定義を求めている。Rob は後に、ISO/IEC 30107-3 が受動的・能動的ライブネスを正式に区分しているわけではないと認め、facliv は顔のライブネスが行われたことのみを意味し、細かな区別はプロファイルに委ねるのがよいと述べている。Mike Jones は amr の値の間で重複があるのは通常のことだと述べ、call を PR #7 で削除し、明確化のために issue #8 を作成した。資料は途中で切れている。
Implementer review of draft-skyfire-oauth-amr-values-01 and draft-skyfire-oauth-id-verification-01
影響を受ける人 顔照合と能動的ライブネスチャレンジを記録する実装者が、どの amr 値を出力すべきかを決める場合 議論 11月6日
sd-jwt-vc-23 への IESG 投票で二つの SHOULD が問われ、著者は一方を外し他方に説明を加えると回答した Éric Vyncke は -23 に DISCUSS を入れた。型照合（2.2.2.2 節）とステータス確認（2.4 節）がなぜ MUST ではないのか、また型照合の SHOULD は BCP 14 上は相互運用性の要件ではないのではないか、と指摘している。著者は、型照合の記述は遅い段階で追加され、DCQL や OpenID4VP などの上位層を助ける意図であり、BCP 14 の用語を避けるほうがよいと回答した。ステータスについては、Verifier がオフラインの場合があるため MUST にせず、確認しない場合の影響の説明を加えると述べた。COMMENT では、RFC 7800 の正式な更新が欠けているという DISCUSS への同意と、RFC 6890 への規範的参照を IANA の IPv4・IPv6 特殊用途レジストリに置き換える提案もある。-25 の差分は最初の二点に対応している。
Éric Vyncke's Discuss on draft-ietf-oauth-sd-jwt-vc-23: (with DISCUSS and COMMENT)
影響を受ける人 aka_vcts で認証情報の型を照合するウォレットや Verifier のライブラリが、その規則がプロトコル上の要件かどうかを知る必要がある場合 オフラインになり得る Verifier が、status クレームを持つ認証情報をどう扱うかを決める場合 議論 11月6日
Skyfire の KYAPay ドラフトに対するレビュー指摘が GitHub の issue として管理されるようになった Ankit は、Jean Diaconu のレビューで残っていた指摘を issue として列挙している。内容は、一つのリクエスト内の別々の KYA トークンと PAY トークンの関係（トークンのドラフトでは iss と sub の両方が等しい場合に限り同一の開始者を指すとされている）、サイトが直近の人間による確認を求められる Human in the Loop、AML methods ドラフトのベンダーページへの参照および誤り・陳腐化・機微情報を含むアサーションである。引用されたやり取りでは、Mike Jones が PR #49 で aid と sti を明確化し、リプレイ対策として jti と短い有効期間に言及したこと、verifier の説明の不明瞭さが issue になったこと、token-exchange の例を作り直していることが読み取れる。引用部分は途中で切れている。
Review of draft-skyfire-oauth-kyapay-*