IETF 123 OAuth WG Session 1
identity

IETF 123: OAuth WG Session 1 サマリー（日本時間24日）

Nat 2025/07/25 No Comments

概要

日本時間7月24日、IETF 123 Madrid でOAuth WGの第１セッションが行われました。事前に発表されたアジェンダは以下のとおりですが、Chairs update のあとにAIについてのセッションが挿入されました。また、Chairs Update としては以下のことが報告されました。

  • Published RFCs
    • RFC 9728 – OAuth 2.0 Protected Resource Metadata – Mike, Phil, Aaron.
  • RFC Editor Queue
    • Selective Disclosure for JWTs (SD-JWT)
    • OAuth 2.0 for Browser-Based Applications
  • Waiting for Write-Up
    • Cross-Device Flows: Security Best Current Practice
    • Token Status List

アジェンダ

主な議題

主な議題は、OAuthプロトコルの最新の状況とセキュリティに関する議論です。具体的には、AIエージェント認証における新たな課題、特に特権の高いサービスアカウントからの脱却とユーザーを代表するトークンの取得について検討されています。また、SD-JWT (Selective Disclosure JWT) の進捗状況と、分散型識別子 (DID) の包含に関する継続的な議論に焦点を当てています。さらに、 audience値の曖昧さによる既知のセキュリティ脆弱性を修正する取り組みや、セキュリティBCP (Best Current Practice) の更新、特にオーディエンスインジェクション攻撃とミックスアップ攻撃の亜種に対する対策が議論されました。最後に、OAuthアイデンティティと認可のドメイン間連携、およびSpiffyクレデンシャルを利用したOAuthクライアントの自動登録に関する提案も紹介されています。

なお、本日も日本時間の夜９時半から第２セッションが行われます。

IETF 123: OAuthに関するブリーフィングドキュメント (2025年7月24日)

（以下、NotebookLMによるまとめにちょっと手を入れたものです。）

1. AIエージェント認証の課題

Jonathan Rosenberg と Pat Whiteは、AIおよびAIエージェントの出現によって生じる新たな認証課題について、OAuthコミュニティからの支援を求めました。

  • 課題1：AIチャットボット・音声ボットの特権問題
    • 顧客サポート用ボット（チャットボットや音声ボット）は、ユーザーに代わってAPIを呼び出し、アクションを実行します（例：処方箋の再注文）。
    • 現在、これらのボットは通常、高い権限を持つサービスアカウントで構築されています。「今日、ほとんどのものはこれらのボット用のサービスアカウントで構築されており、ご存知の通り、通常はかなり高い特権を持っています。なぜなら、会社に電話をかけてくるあらゆるユーザーに代わって操作できる必要があるからです。」
    • 大規模言語モデル（LLM）の導入により、ボットが「幻覚」を起こしたり、誤った情報に基づいてAPI呼び出しを決定するリスクが高まります。
    • 目標は、「神のようなサービスアカウント」から脱却し、ボットにユーザー自身を代表するトークンのみを付与する認証フレームワークを開発することです。
    • 公衆交換電話網（PSTN）経由でユーザーが本人確認（SSNの下4桁、住所など）を行う場合に、その情報を使用してユーザーのトークンを取得する方法が課題となります。
    • （崎村の感想）これって、CIBA使えばよいのではないの？
  • 課題2：自律型AIエージェントの権限昇格
    • UIを持たない自律型エージェント（例：取引ボット）が、特定の状況下で権限を一時的に昇格させる必要がある場合（例：緊急メールへの返信のためにメール閲覧権限を一時的に昇格）。
    • 「ボットは、必要なことを行うための適切な権限を持つトークンを要求できる必要があります。」
    • 「ボットが、人間による承認のためにユーザーに送り返される、何らかの権限昇格を要求する必要があるということです。」これは、限定された時間と期間で行われるべきです。
    • （崎村の感想）これって、CIBA使えばよいのではないの？
  • 関連するセキュリティ問題：AI確認フロー (Human-in-the-Loop)
    • AIエージェントがAPIを呼び出す前に、人間による確認と承認が必要なシナリオ。「AIエージェントがAPIを呼び出したいが、うまくやることを信用できないという問題です。人間と相談して、人間が操作を承認し、それからAPIが呼び出されることを望みます。」
    • これはOAuthに隣接する問題として認識されており、”draft-rose-check-00″としてドラフトが提出されました。Tim は、これがOAuthの範囲内であると主張しました。
  • OAuthコミュニティからのフィードバック
    • Jeff Lombardo (AWS)は、既存のOAuth機能（特にClient Initiated Backchannel Authorization: CIBA）がこの問題の多くに対処できる可能性を指摘しました。「神のようなトークンを与えないと言ったとき、これこそがOAuthが作られた理由だと思います。」
    • Hannes Tschofenigは、エージェントがトークンを直接操作すべきではなく、認証インフラストラクチャから分離すべきであるという点で、興味深い見解を示しました。「理想的には、エージェントはトークンに一切触れるべきではありません。神のようなトークンでも、一時的なトークンでも、いかなるトークンにも。」

2. SD-JWT VC（Selective Disclosure JSON Web Token Verifiable Credentials）

Brian Campbellは、SD-JWT VCの進捗状況と、DID（Decentralized Identifiers）の取り扱いに関する重要な議論について説明しました。

  • SD-JWT VCの概要
    • 検証可能なクレデンシャルをJSONペイロードで表現するためのデータ形式、検証、および処理ルールを定義します。
    • SD-JWT形式と既存のJWTコンテンツルールおよび拡張性モデルに基づいています。
    • OpenID Connectに類似したSD.VC発行者メタデータと鍵解決技術を記述します。
    • W3Cの検証可能なクレデンシャルデータモデル（VCDM）1.1または2は利用せず、必須でも禁止でもありません。連携して使用する場合はOpenID for Verifiable Presentations はSD-JWT-VC-LDを参照します。
  • 最近の変更点 (Draft 9 & 10)
    • 主に編集上の更新、エンコーディングの修正、例の更新。
    • 発行者署名鍵検証セクションが「発行者署名メカニズム」に改称され、署名鍵検証オプションの拡張ポイントが明確に定義されました。
    • ウェブベースのメタデータ解決（よく知られたURIとJWKSを使用）とインラインX.509バリアント（x5c JWSヘッダーを使用）の2つの一般的なメカニズムが定義されました。
    • 許容されるメカニズムは検証者のポリシー（信頼されたCAリストなど）に依存することが明確化され、1つのメカニズムの検証で十分とされました。
  • DIDのSD-JWT VC仕様への包含に関する議論
    • 非包含の理由（Brian Campbellの主張）:
      • 複雑性と認知的オーバーヘッド: DIDメソッドのレジストリには200以上のメソッドがあり、ほとんどの開発者がすべてを実装するのは現実的ではありません。これにより、相互運用性が損なわれます。「200以上のDIDメソッドの普及は、ほとんどの開発者にとって、ほとんどの平均的な開発者にとって、実装するのが合理的ではありません。」
      • 評判リスク: 200もの統一されていないDIDメソッドを含めることは、標準化トラックIETF文書の信頼性と真剣さを損なう可能性があります。「200の適切に管理されていない、特定のコミュニティの幅広い合意を得ていないDIDメソッドを含めることによる、標準化トラックIETF文書の信頼性と認識される真剣さへの潜在的な損害。」
      • スコープの逸脱: DIDに関するガイダンスは、この作業部会や文書の専門知識とスコープを超えています。特定のプロファイルがDIDメソッドの選択とポリシーを定義すべきです。
    • 包含の必要性（MarcusとStefanの主張）:
      • 過去4回の議論で、DIDサポートを削除することに大きな反対意見がありました。
      • 「この変更を元に戻すべきです。」
      • Stefanは、DIDに関する以前の記述が、拡張機能の使用方法を説明するために要求されたものであり、削除は逆行であると主張しました。
      • 200のDIDメソッドをすべて実装する必要はなく、ヨーロッパレベルでDIDメソッドの標準化が進められています。「200の非標準化されたDIDメソッドに関する情報を繰り返し言うのはやめてください。欧州レベルのSan JC19で標準化プロジェクトが進行中です。そこで明示的にこれらのDIDメソッドを標準化します。」
      • DIDサポートは以前は必須であり、その後オプションになった経緯があります。オプション機能であるため、実装を望まない開発者に負担をかけるべきではありません。
    • 投票結果:文書にDIDを含めるかどうかについて、投票が行われました。
      • 賛成：7票、反対：14票、意見なし：9票。
      • 結果として、DIDを主要文書に含めないことが決定されました。提唱者は、DID作業のためのプロファイルまたは独立したRFCを公開すべきです。「そのオプションは提唱者によって採用されるべきです。このRFCを今日持っているもので公開し、DID作業のためのプロファイルを開始し、それも公開してください。」

3. RFC 7523 BIS の更新

Mike Jonesは、RFC 7523 bisの更新状況、特に既知のセキュリティ脆弱性への対処について説明しました。

  • 目的: 承認システムを対象とした曖昧なオーディエンス値が悪用される脆弱性に対処すること。
  • 対象となるRFC: 7521, 7522, 7523, 9126（Push Authorization Requests）を更新します。
  • アプローチの変更: 以前は7523を完全に置き換えることを想定していましたが、IETF 122での議論の結果、既存のRFCへのポイント更新に焦点を当てることになりました。「7523を置き換えるのではなく、ポイント更新を行うことになったのです。」
  • 主な変更点:
    • 署名済みJWT要求形式への更新を削除（既に「正しいことをすべき」とされているため）。
    • 脆弱性を説明したシュトゥットガルト大学の論文への参照を追加。
    • IETFのプロセスを迅速化（セキュリティ修正のため）することがDebの支援を受けて確認されました。
  • 未解決の課題:
  • 明示的なタイピング（Explicit Typing）: 承認サーバーが古い7523と更新された7523を区別できるように、明示的なタイプを必須とするか否かについて議論があります。
  • SAML認証グラント: オーディエンス制限に関する特定の言語の調整。
  • 単一文字列オーディエンスの強制: 現在の仕様ではオーディエンス値は単一文字列であるべきとしていますが、Kubernetesのような既存の実装が配列を使用しているため、変更の必要性について議論があります。「オーディエンス値は単一文字列でなければならないとされていますが、Kubernetesはオーディエンス値に配列しか使用しないコードを持っています。」
  • グラントオーディエンスチェックの微妙な点。
  • 文書のタイトル: 現在のタイトル（”7523 BIS”）の変更提案があり、Mike SchwarzやBrian Campbellから新しいタイトルの提案があります。
  • 今後のステップ: 継続的な議論、課題の解決、ドラフトの公開、そして最終的なワーキンググループ最終コールを目指します。セキュリティ修正であるため、迅速な公開が目標です。

4. OAuthセキュリティBCPの更新

PedramとKaiuanは、OAuthセキュリティBCP（Best Current Practice）の更新状況について発表しました。この更新は、新たに発見された2つの攻撃に対処することを目的としています。

  • 更新の背景:
    • BCPの最終化後に発見された2つの新しい攻撃（オーディエンスインジェクション攻撃とMix-Up攻撃の亜種）に対応するため。
    • IETF 122での議論の結果、新しいRFCとしてBCP 240に追加し、新しい攻撃に関する考慮事項のみを含めることが決定されました。
  • オーディエンスインジェクション攻撃 (Pedram)
    • 攻撃の概要: 攻撃者がクライアント認証アサーションを取得し、クライアントになりすます方法の詳細な説明。具体的なエンドポイント（プッシュ認証エンドポイント、デバイス認証エンドポイントなど）のリストも提供されています。
    • 根本原因と対策: 攻撃はクライアントによってのみ防止可能であり、単一のオーディエンス値（ASの発行者識別子またはターゲットエンドポイントの正確なURI）を使用することを推奨します。
  • Mix-Up攻撃の亜種 (Kaiuan)
    • 動機: Google、Microsoft、Amazon、Samsungなどの主要ベンダーを含むプラットフォームに影響を与える、新しいMix-Up攻撃の亜種が広範囲に存在すること。「ほぼすべての場所で蔓延している新しいMix-Up攻撃の亜種を発見しました。」これは、プラットフォーム設定における明確な標準や慣行の欠如に起因しています。
    • 攻撃の焦点: 複数のIDPと連携する単一のアプリではなく、多数の統合アプリと連携する「統合プラットフォーム」に焦点を当てています。
    • 攻撃の亜種:Cross-Flow Account Takeover (C-FAT): 被害者の承認コードが攻撃者に漏洩する。
    • Code Injection (CI): 攻撃者のコードが被害者に注入される。
    • 根本原因: OAuthクライアントが統合アプリを区別する際に曖昧さがあること（セッションやリダイレクトURIのみに依存するなど）。
    • 「共有発行者」の概念: 2つの統合アプリが同じ認証サーバーを合法的に共有できる場合（例：同じプラットフォーム上の2つのDropbox統合）。この場合、発行者識別子だけでは各統合を一意に識別できません。
    • 対策: OAuthクライアントは、各統合アプリを「明確なリダイレクトURI」で区別すべきです。これは、OAuthを開始したアプリと完了するアプリが同じであることを強制します。この防御策は多くの企業に採用されています。
  • 今後のステップ:
  • この文書をワーキンググループドラフトとするためのさらなる議論（特に議長とのオフラインでの調整）。
  • 仮想中間会議を開催し、詳細な議論を行う可能性。
  • 参加者からの文書レビューとフィードバックが求められています。

5. JWT Security BCPの更新

Yaronと Mike Jonesは、RC8725 JWT Security BCPの更新について発表しました。これも、新たに発見された攻撃に対処するものです。

  • 更新の動機: 2023年夏のBlack Hatで公開された攻撃や、清華大学の研究者によるCVEなど、JOTに対する多数の新しい攻撃が発見されたため。
  • 提案される変更点（5つのプルリクエスト）:
  • パスワードベースの鍵生成における反復回数の上限: サービス拒否攻撃を防ぐため。
  • JWS/JWEの混同: 検証者がJWSを期待しているにもかかわらずJWEを受け入れてしまうケースに対処するため。「これは、JWEが公開鍵で暗号化されており、検証者が公開鍵を秘密鍵と一緒に保管している場合に特に発生します。」JWSであることを確認する規範的言語を追加します。
  • 大文字・小文字の区別: 「none」アルゴリズムのブロックリストを回避するために大文字・小文字を操作する攻撃に対処するため。防御的なコーディング（ブロックリストの代わりに許可リストを使用）を推奨します。
  • 圧縮の悪用: JWEでサポートされている圧縮機能が悪用される可能性に対処するため。
  • JSONシリアライズされたJWSの拒否: 標準では許可されていないにもかかわらず、一部の検証者がJSONシリアライズされたJWSを受け入れてしまう問題に対処するため。
  • 今後のステップ: 文書は良好な状態であり、できるだけ早く作業グループに採用され、進捗させることを望んでいます。Aaron and Denny Pinkasからのレビューが既に受領されています。Brian Campbellは、さらなる更新が必要になる可能性があり、PFB(Password Based Key Derivation Function 2)アプローチアルゴリズムの廃止や、「none」アルゴリズムの非推奨化に関する既存の文書との連携など、より大きな作業になる可能性があることを指摘しました。

6. OAuth IDと認証のドメイン間連携

Brian Campbellは、RFC 8693（トークン交換）とRFC 7523（アサーションフレームワーク）を組み合わせて、エンドユーザーの操作なしにドメイン間でIDと認証情報を維持する一般的なパターンを記述するドラフトについて説明しました。

  • 目的: 2つの既存のRFCをプロファイリングし、多くの場所で実際に行われているものの、多くの人にとって理解が難しい方法で、ドメイン間でIDと認証情報を維持する方法を説明すること。
  • 主なアプローチ: ローカルなRFC 8693トークン交換を使用してトークンを取得し、RFC 7523のクロスドメインアクセス許可取得を容易にします。
  • 最近の変更点 (Draft 05): 主に編集上の更新と、ローカルASがサポートするトークンタイプを記述するためのメタデータの追加。
  • 未解決の課題: 4つの未解決の課題がありますが、そのほとんどは編集上のものです。1つは、アサーションプロファイルでのMikeの変更を反映させることに関するものですが、影響は小さいと予想されます。
  • ワーキンググループ最終コールへの提案: 文書はワーキンググループ最終コール（WGLC）の準備ができており、迅速な進捗が期待されています。「ワーキンググループの最終コールを検討してください。」
  • Aaron Perkiの関連作業 (Identity Assertion Authorization Grant):Brianは、Brian自身の文書と関連するAaron Perkiの作業（Identity Assertion Authorization Grant）についても言及しました。これは、Brianの文書のより具体的で意味のあるユースケースのためのプロファイルです。
  • この作業は、Agentic AIのユースケース、特に企業環境での関連性が高まっています。エンドユーザーの明示的な許可なしに、ユーザーに代わってOAuthベースのシステムがアクセス・トークンを取得できるようにします。
  • 「Agentic AIの出現よりずっと前からこの作業は始まりましたが、エンタープライズの文脈でのAgentic AIのユースケースに特に関連性があり、意味のあるものとなります。ここでは、エンドユーザーの同意は実質的に雇用契約を通じて提供され、各トランザクションでエンドユーザーの同意を得る必要はありません。」
  • Aaronのブログ投稿と図が示され、AIエージェントがエンタープライズIDPからログインし、SSOトークンを使用してSlackなどのアプリケーションにクロスドメインでアクセスする方法が示されました。
  • コミュニティからの反応: WGLCの提案に対して、異論はほとんどありませんでした。この作業は重要であり、企業環境に直接関連しています。

7. OAuthクライアントIDプレフィックス

Brian Campbellは、Aaron、Daniel、Josephが取り組んでいる「OAuthクライアントIDプレフィックス」ドラフトについて説明しました。

  • 目的: クライアントがメタデータを公開するためのシンプルで実用的な方法を提供し、クライアントの事前登録なしに承認サーバーがクライアントIDを確立できるようにします。これは、オープンソースのチャットアプリと自己ホスト型サーバーの接続や、MastodonやWordPressのような自己ホスト型サービスに接続するアプリなど、事前登録が非現実的な多くのケースで役立ちます。
  • 以前のドラフトとの関係: 以前の「クライアントIDメタデータドキュメント」ドラフトから分割され、名称変更されました。
  • コンセプト:
    • クライアントは、クライアント登録ボキャブラリ（動的クライアント登録で定義されたフィールド）を使用して、JSONドキュメントを安定したURLに公開します。
    • 承認リクエストでは、そのURLをクライアントIDとして渡します。
    • 承認サーバーは、そのURLからJSONドキュメントを取得し、それを使用してクライアントのアイデンティティ（構成パラメータ、認証用の公開鍵など）を確立します。
    • これは、事前登録を必要としないクライアントオンボーディングの代替アプローチを提供します。
  • AIとの関連性: このアプローチは、Agentic AIにも役立ちます。Agentic AIは、リソースにアクセスするソフトウェアという点では新しい問題ではありませんが、その規模と潜在的な問題は、事前登録が多くの展開における障害となるという、これまでも課題だった問題を浮き彫りにします。
  • 議論と課題:
    • 欠点: 事前登録のメリット（例：リダイレクトURIの検証）が失われる可能性。解決策として、クライアントIDとドキュメントのハードな関連付けや、ユーザーに検証済みURLを表示することなどが検討されています。
    • 信頼管理: OpenID Federationとの類似性が指摘され、OpenID Federationが複雑な信頼管理メカニズムを導入している理由（大規模な展開での自動化、信頼マークなど）が強調されました。このドラフトでは、そのような信頼管理メカニズムが不足している点が課題として挙げられました。
  • 今後のステップ: 文書はまだWGLCの準備ができていないと判断されました。さらなる議論と課題の解決のために、中間会議が開催される予定です。

8. Spiffy Credentialsを用いたOAuthクライアント登録

Pieter Kasselmanは、Spiffy Credentialsを用いたOAuthクライアントの自動登録に関する2つのドラフトについて発表しました。

  • 自動クライアント登録の必要性:
  • 運用の課題: クライアントとシークレットの手動管理、シークレットのローテーション、安全な保管には時間がかかり、エラーが発生しやすく、ダウンタイムにつながる可能性があります。「クライアントやシークレットの管理、シークレットのローテーション、安全な保管には多くの時間がかかり、手作業になりがちです。または、従うべき多くのプロセスを作成する必要があります。」
  • 異種環境: 異なる組織や技術スタックで手動作業を行う場合、開発者とID管理者の間での多くの調整とオーバーヘッドが発生します。
  • 指数関数的な成長: ワークロードの増加、特にAIの貢献により、クライアントとシークレットが指数関数的に増加し、大規模組織での管理が困難になっています。
  • Spiffyの紹介:
    • Spiffy（Secure Production Identity Framework For Everyone）は、ワークロードにシークレットをプロビジョニングすることなく、クレデンシャルをブートストラップすることで、この「底辺の亀問題」を解決することを目的としています。
    • アッテステーション（Attestation）と継続的なライフサイクル管理を通じて機能します。
    • 大規模に展開でき、オープンソースおよび商用ソリューションが利用可能です。
    • Spiffyは、クライアントの管理責任をプラットフォームレベルに移行させ、ワークロードを重視することで、OAuth展開のメリットをもたらします。これにより、OAuthサーバーはクレデンシャル発行、ライフサイクル管理、ID証明を行うSpiffyインフラストラクチャに依存できます。
  • 提案される2つのアプローチ:
    • 1. 最初に登録する (Register on First Use) アプローチ:
      • クライアントがSpiffyクレデンシャルを提示すると、認証サーバーは発行者を既に信頼しているため、クレデンシャルを検証し、そのクライアントIDを自動的に信頼・登録します。
      • 追加の登録プロトコルは不要で、効率的で低遅延です。
      • クライアントクレデンシャルフローに適しています。
      • リダイレクトフローには追加のメタデータ管理戦略が必要です（BrianやAaronの以前の作業との連携の可能性も示唆されました）。
    • 2. ソフトウェアステートメントとしてのSpiffy JWTの使用 (Dynamic Client Registration):
      • Spiffy JWTを動的クライアント登録プロトコルの一部としてソフトウェアステートメントとして使用します。
      • 新しいプロトコルは不要で、既存の動的クライアント登録と互換性があります。
      • MCP (Mobile Connect Profile)に採用された動的クライアント登録にとって有用です。
      • JWTのみをサポートしますが、他のクレデンシャルタイプに一般化することも可能です。
  • 今後のステップ:
    • クライアントの自動登録がOAuthコミュニティにとって興味深いものであるかどうかの意見を求めます。
    • Spiffyアプローチが興味深いものであるかどうかを議論します。
    • 興味がある場合は、コメント、課題、PRを通じて参加を呼びかけます。
    • これにより、シンプルでスケーラブルかつ安全なクライアント登録メカニズムが提供され、シークレットの増殖問題からの脱却につながります。
  • コミュニティからの反応:
    • SpiffyがOAuth展開で採用されている場合、登録プロセスを簡素化できるという点で、この作業は非常に関連性が高いと見られています。
    • Jeff Lombardo (AWS)は、この作業部会が取り組むべきだと賛成しました。
    • Mike Jonesは、「自動クライアント登録」という用語がOpenID Federationで既に明確に定義されているため、別の用語を使用することを提案しました。
    • Josephは、リダイレクトフローと非リダイレクトフローへの分類が正確ではない可能性を指摘し、プッシュ認証リクエスト（PAR）を使用した場合にリダイレクトフローでも最初のケースに該当する可能性があるとコメントしました。
    • Tony Nadlinは、文書が信頼ドメインの確立方法について説明していないこと、およびSpiffyを特定のインスタンスで使用する方法について懸念を示しました。
    • Brian Campbellは、自身が発表した「クライアントIDプレフィックス」の作業とのオーバーラップを認識しており、連携の必要性を強調しました。
Pin

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。