IETF 123 Madrid OAuth WG Day 2 Summary
Authorization Events FAPI identity IETF

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

Nat 2025/08/01 No Comments

なんか時間が経ってしまって、もはや記憶がぼやけておりますが…。以下、NotebookLMにまとめてもらったのを書き直しながら思い出せるか…。（年取ると忘れっぽくなって嫌ですね…。）

概要

日本時間7月25日、IETF 123 Madrid でOAuth WGの第2セッションが行われました。事前に発表されたアジェンダは以下のとおりです。

以下、主要なテーマ、重要なアイデア、および事実をまとめています。(Thanks NotebookLM!)

1. トークンステータスリスト (Token Status List)

  • スケーラブルな失効メカニズム: トークンステータスリストは、スケーラブルな失効メカニズムとして設計されており、プライバシー特性、理解のしやすさ、実装の容易さに重点が置かれています。JOSEおよびCOSEベースのクレデンシャル形式との互換性も備えています。
  • 幅広い参照とテスト: 現在、ISO mDL ,DOCで参照されており、欧州のARFでもステータスメカニズムの一つとして挙げられています。多数のテストイベントやハッカソンでテストされており、結果は良好です。
  • 拡張点とレジストリの確立: 本ドラフトは単一のメカニズムにとどまらず、ステータスメカニズム全般の拡張点とレジストリを確立します。
  • 主要な変更点:
    • 以前のIETF以降、主に編集上の変更が3つのリビジョンで行われました。
    • 大きな変更点として、クライアントからステータスリストトークンを要求する際のリクエストヘッダーAcceptが「must」から「should」に緩和されました。
    • 定義されたKey Usage の OIDフィールドが、このドラフトによって作成されるIANAレジストリ内の他のメカニズムで使用できるようになりました。
  • 現状: 全ての未解決の問題とプルリクエストは組み込まれました。現在はシェパードレビューの進行を待っており、迅速化のためのガイダンスを求めています。

2. バックエンドアテステッドクライアント認証 (Backend Attested Client Authentication)

  • 目的: 従来の機密クライアントによる認証では限界があったため、フロントエンドインスタンスがアテステーション（証明）を取得し、それを認証サーバーへのクライアント認証として直接使用できるメカニズムを確立します。
  • フローの概要: クライアントインスタンスがアテステーションキーを生成し、バックエンドとのプロトコル（ドラフトのスコープ外）を実行してJWT形式のアテステーションを取得します。このクライアントアテステーションとその証明は、認証サーバーとの認証に共同で利用されます。
  • IETF 122以降の変更点:
    • クライアントID処理、クライアントアテステーションの使用法、および一般的な言語の明確化。
    • OAuthエラー応答値の追加。
    • 最も重要な変更点として、チャレンジ取得のためのHTTP OPTIONSメカニズムを廃止し、HTTP POST動詞を使用する専用のチャレンジエンドポイントに移行しました。これにより、ブラウザ環境における複数のプリフライトリクエストの問題が解決されます。
    • セキュリティと実装に関する考慮事項の更新（リプレイ保護、JTIの使用など）。
  • DPoPとの最適化に関する議論:
    • このクライアント認証メカニズムをDPoP（Demonstration of Proof-of-Possession）と組み合わせて使用する場合、認証サーバーは3つのJWT（クライアントアテステーション、クライアントアテステーションPoP、DPoP証明）を検証する必要があります。
    • Client Attestation PoPとDPoP証明のキーが同じである場合、DPoP証明をClient Attestatiion PoPの代わりに使用する最適化の可能性が議論されました。これにより、リクエストヘッダーが削減され、効率性が向上します。
    • セキュリティ上の懸念については、同じエンティティに署名されたメッセージを送るために同じキーを再利用することに問題はないという意見が表明されました。
    • この最適化は必須ではなく、クライアントはDPoPの有無にかかわらず機能するように準備する必要があります。
  • 未解決の主要な問題:
    • チャレンジエンドポイントは解決済みと見なされており、DPoP最適化の採用に関するフィードバックが求められています。リソースサーバーでのアテステーションヘッダーの使用については、ドラフトで言及が少ないため、詳細を拡充するか、完全に削除するかのフィードバックが求められています。

3. トランザクショントークン (Transaction Tokens)

  • 目的: アクセストークンを維持し、コンテキスト（サブジェクト、コンテキスト、承認詳細）を保持しながら、所与の信頼境界内でトークン交換を可能にするメカニズムです。アクセストークンの漏洩リスクを低減し、よりきめ細かい認可の展開を可能にします。
  • IETF 122以降の変更点:
    • スコープの一貫性: トランザクショントークンが元のアクセストークンよりも広いスコープを持つことがないよう、文言が厳密化されました。
    • 認証と認可の区別: トランザクショントークンは認証構造ではなく、認可構造であることが明確化されました。
  • HTTPヘッダー形式に関する課題:
    • IANAのレビュー担当者からのフィードバックにより、既存のHTTP構造化ヘッダータイプがどれもこの目的に適さないと結論付けられました。
    • 結果として、非構造化ヘッダーとして維持されることになりましたが、これにより将来的な問題のリスクがなくなりました。
    • 議論では、将来的にHTTPワーキンググループに新しい構造化ヘッダーの要求を出す可能性も示唆されましたが、これはこの仕様の進行を妨げるものではないとされました。
  • 現状: 開発者は主要な未解決の問題はないと認識しており、HTTPヘッダー形式の問題も解決済みとされています。WGLCに進む準備ができています。

4. Spiffeクライアント認証 (Spiffe Client Authentication)

  • 背景: Spiffe（Secure Production Identity Framework For Everyone）は、クラウドネイティブ環境でワークロードのアイデンティティを確立・検証するためのフレームワークです。現在、ワークロードは他のワークロードとの通信にSpiffeのSVID（SPIFFE Verifiable Identity Document, X.509証明書またはJWT (巻末にメモを置いておきます)）を使用していますが、認証サーバーとの認証には手動でプロビジョニングされ、長期間有効なクライアントIDとクライアントシークレットが必要です。
  • 提案の目的: Spiffeによって自動的にプロビジョニングおよびローテーションされる短命の証明書とキー証明機能を持つSVIDを、認可サーバーへの認証手段として使用できるようにします。これにより、既存のインフラストラクチャを活用し、保護すべきシークレットを減らすことができます。
  • 提案内容:
    • JWT SVIDにはRFC 7523のクライアント認証部分を、X.509 SVIDにはRFC 8705のMTLSクライアント認証をプロファイリングします。
    • 認可サーバーは、Spiffeの仕様であるSpiffeバンドルエンドポイント（JWKSと同様）からキーを取得してSVIDを検証します。
  • 主要な議論点:
    • issクレームの要件: SpiffeのJWT SVIDにはデフォルトでissクレームが含まれないため、RFC 7523のissクレームの要件を緩和できるか、あるいはSpiffeユーザーにissクレームの有効化を要求すべきかが議論されました。これにより、OpenID Connect Discoveryベースのキー配布メカニズムを推奨できる可能性も浮上しました。
    • オーディエンスの扱い: Spiffeで特定のオーディエンスを持つJWTを取得できることが確認され、RFC 7523およびRFC 25 BISに基づくと、認証サーバーがオーディエンスとなることが想定されています。
    • 単一ドラフト vs 分割ドラフト: JWT SVIDとX.509 SVIDの両方を単一のドラフトで扱うか、それぞれの特性に応じて個別のドラフトに分割すべきかについて、議論の余地があるとの意見が出ました。
    • 現状: 新しいドキュメントであり、レビューとフィードバックが求められています。

5. リフレッシュトークンと同意の有効期限 (Refresh Token Expiration and Consent Expiration)

  • 目的: リフレッシュトークンの有効期限とユーザーの同意の有効期限という、2つの異なるが関連する概念に関するメカニズムを導入します。これにより、ユーザーへの事前通知や、クライアントによるトークンの積極的なローテーションが可能になります。
  • ユースケース:
    • 同意の有効期限: Googleのクライアントからの要望として、同意期限が切れる前にユーザーに事前に通知し、サービス中断を防ぐ目的があります。
    • リフレッシュトークンローテーション: クライアントがトークンを頻繁に使用しない場合（例：ユーザーがサイトにアクセスしたときのみ）、積極的なローテーションが必要かどうかを知る必要が生じます。
  • 提案内容: トークンエンドポイントの応答に、2つの新しいパラメータrefresh_token_expires_inとconsent_expires_inを追加します。これらは異なる値を持つことができます。
  • 主要な議論点:
    • 時間限定トークン要求パラメータ: クライアントが時間限定トークンを要求するためのパラメータ（認可フロー要求やトークンエンドポイント要求など）を定義する必要があるか。
    • expires_in vs expires_at: 現在のRFC 6749はアクセストークンにexpires_in（相対時間）を使用していますが、expires_at（絶対時間）の利便性（クライアントがシステム時間をチェックする必要がない、ローカルキャッシュの可能性）が議論されました。もしexpires_atが採用される場合、アクセストークンにも一貫性のためexpires_atを追加すべきかどうかが検討されます。
    • 同意に関する用語: 「同意 (consent)」という用語はOAuthのベース仕様に明示的に定義されていないため、この概念をパラメータ名に導入することの適切性が議論されました。代替案として「許可 (grant)」などの用語が示唆されました。
    • 実装ノート: 認証サーバーが同意の有効期限をどのように処理するかに関する非規範的な実装ノートを追加すべきか。
  • 現状: ドラフトは存在し、フィードバックとレビューが求められています。特に、同意に関する用語やexpires_atの使用、およびグラント管理APIとの関連性について懸念が表明されています。

6. ブラウザレスアプリ間フェデレーション (Browserless App-to-App Federation)

  • 背景: OAuthのRC8252（アプリ対ウェブ）とJoseph Heenan (Authlete社CTO) の「アプリ対アプリ」のブログで提案されたモデルは、クライアントアプリと認可サーバーアプリが同じ信頼ドメインに属する場合に効果的です。しかし、複数の信頼ドメインにまたがるフェデレーションシナリオ（例：学術機関や多国籍企業）では、中間リダイレクトのためにブラウザが必要となり、ユーザーエクスペリエンスの低下や潜在的な問題（Cookieの問題、ディープリンクのプロンプトなど）が生じます。
  • 問題点:
    • ブラウザを介したリダイレクトは、ユーザーエクスペリエンスを悪化させる（遅延、途切れ途切れ、タブの散乱）。
    • 異なるブラウザ（Web Viewなど）が使用されると、Cookieの不整合などでフローが中断する可能性がある。
  • 提案の目的: ブラウザを介さずに、アプリが自身のユーザーエージェントとなり、直接リダイレクトを処理することで、複数の信頼ドメインにまたがるフェデレーションを実現します。
  • 提案内容:
    • クライアントアプリが自身のユーザーエージェントとなり、HTTPクライアントとしてリダイレクトを追跡します。
    • 各URLを検出し、デバイス上にそのURLに対応するアプリが存在するかどうかを確認します。存在する場合は、そのアプリに直接コールします。
    • ユーザー認証アプリがユーザーを認証し、操作を承認した後、ディープリンクURLを2つのアプリ間で共有し、ユーザー認証アプリはベストプラクティスに反して、このネイティブコールバックURLを信頼し、リダイレクトURLと共にコールバックを返します。
    • 信頼の確立には、OpenID Federationや自動クライアント登録（←OpenID Federation の Automatic Registrationとは別物なので名前を変えるべきだとの指摘が入った）、または閉じたエコシステムでの事前登録された信頼が利用できます。
  • 主要な議論点:
    • 認証サーバー側の振る舞い: 認証サーバーがユーザーとの対話なしに連続した30xリダイレクトを返すシナリオの実現可能性。
    • セキュリティに関する考慮事項: ブラウザを使用しないことによるユーザーのセキュリティ意識（どのオリジンで認証しているか）の低下の懸念。提案は、ユーザーインタラクションが発生しないリダイレクトチェーンに焦点を当てています。
    • フォールバックオプション: ブラウザレスでの実現が不可能な場合に備え、ブラウザへのフォールバックオプションを常に提供します。
  • 現状: OSWで発表され、アクティブなユースケースが存在します。セキュリティ分析のため、シュトゥットガルト大学との共同作業を計画しており、フィードバックとサポートを求めています。認証サーバーがこのプロファイルをサポートすることを宣言するためのメタデータオプション（ネイティブ認証エンドポイントの宣言）も提案されました。

7. クライアント拡張クレーム (Client Extension Claims)

  • 背景: OAuthにおけるセキュリティメカニズム（MTLS、DEOP、Private Key JWTなど）の使用に関する情報を、アクセストークンペイロードに含めることで、リソースサーバーがこれらの情報を政策決定に利用できるようにします。現在、これらの情報はHTTPヘッダー（DPoPなど）や、トークンの種類（IDトークンとアクセストークン）、認可グラントフローの種類（Device Code、Client Credentialsなど）、クライアント認証方法など、様々な場所に散在しており、複雑な処理が必要です。
  • 問題点:
    • トークンの種類（IDトークンかアクセストークンか）の判別が複雑。
    • 使用された認可グラントフローに関する情報が不足。
    • キーバインディング（PKCE、RAR、 JAR）に関する情報が不足。
    • クライアント認証方法（Private Key JWT、MTLS）に関する情報が不足。
    • これらの情報がHTTPヘッダーに分散しており、バックエンドのポリシー決定ポイントがペイロードにしかアクセスできない場合に問題が生じる。
  • 提案内容: アクセストークンのペイロードに4つの新しいクレームを導入します。
    • gty (Grant Type): 使用されたグラントフローのタイプを記述する単一の文字列。
    • cxt (Client Extension Type): Pixie、DPoP、JARなど、使用されたクライアント認証拡張方法の組み合わせを記述する文字列の配列。
    • ccr (Client Credential Reference): ユーザーのACRクレームに相当するもので、ASとARSの間で信頼を伝達するための名前空間を提供します。
    • cmr (Client Method Reference): クライアント認証方法（MTLSなど）を記述し、IANAレジストリで値を登録する予定です。
  • 利点:
    • 新しいリクエストパラメータを導入しないため、認証サーバーは既存のAPIを変更することなく、これらのクレームを返すことができます。
    • 認証サーバーのメタデータにruntime_type_extensionを導入することで、これらの機能のサポートを宣言できます。
  • 主要な議論点:
    • Vectors of Trustとの類似性: Trust Decisionの様々な要素を表す既存のメカニズムであるVectors of Trust（RFC 8584）との関連性。
    • gty値の標準化: OktaやAuth0など、すでにgtyのようなクレームを使用しているベンダーが存在するが、その値が異なる可能性があるため、標準化の必要性。
  • レビューアの募集: ドキュメントのレビューとフィードバックが求められています。

8. 認可レイヤーでのステップアップ認証 (Step-up Authentication at the Authorization Layer)

  • 背景: RFC 9470（ステップアップ認証）は、リソースプロバイダがクライアントに、より強力な認証を要求するために、WWW-Authenticateヘッダーを通じて追加情報（例：異なるACR）を返すメカニズムを提供しました。しかし、これは認証レイヤーに焦点を当てており、認可レイヤー（アクセス制御の判断）で同様のシグナルを送る機能は不足しています。
  • 問題点:
    • リソースプロバイダがクライアントに、なぜ先に進めないのか、より詳細な情報（例：特定の要件や条件）を伝える手段が不足している。
    • FAPI 2.0やSmart on FHIRのようなフレームワークは、クライアント認証の要件やRich Authorization Request (RAR)をサポートしているが、リソースサーバーがクライアントを次の段階に導くためのより詳細なシグナルを送る機能が必要。
    • Shared Signal Framework (SSF)の登場により、リソースプロバイダの決定が動的に変化する可能性があるため、クライアントに最新の情報を伝える必要が生じる。
  • 提案内容:
    • 認可レイヤーでのシグナル伝達を可能にするため、特定のエラーコードとチャレンジを導入します。
  • 特定のチャレンジ:
    • リソースサーバーがクライアントに、自身のOAuth 2.0 Protected Resource Metadataを参照するように指示する機能。
    • クライアントに、次に何をすべきかをRAR（Rich Authorization Request）形式でガイドする機能。
  • 応答のエンベロープ: 認可に関連するため、RARのauthorization_details形式を応答のエンベロープとして使用します。これにより、既存のRAR仕様に準拠した形式で、支払いに関する特定の要件などの情報をクライアントに伝えることができます。
  • メリット:
    • クライアントがリソースサーバーからの詳細なガイダンスを受け取り、適切な認可リクエストを構築し、新しいアクセストークンを取得できるようになります。
    • FAPI 2.0、Smart on FHIR、MCPなどの既存の仕様との連携を強化します。
  • 主要な議論点:
    • HTTPステータスコード 401 vs 403: RFC 9470が401を使用しているのに対し、本提案は認可に関連する問題として403の使用を提案しています。しかし、OAuthフレームワークやFAPI 2.0では401の使用が形式化されており、一部のサーバーは403を最終的な状態と見なす可能性があるため、この点についてフィードバックを求めています。
    • ペイロードとヘッダー: 情報をペイロードに含めるか、ヘッダーに含めるか（例：JWTをヘッダーに含める）について議論がありました。
    • GNAPとの整合性: GNAP（General Authorization and Negotiation Protocol）との整合性も検討事項です。
  • 現状: OSWで発表された以前の複雑なソリューションから合理化されました。フィードバックとレビューを求めています。

9. プッシュ型クライアント登録 (Pushed Client Registration)

  • 背景: OAuthはクライアントIDを中心に構築されていますが、SPAやネイティブアプリインスタンスのようなエフェメラル（一時的）なクライアントには、従来の永続的なクライアントIDの概念が必ずしも当てはまりません。これまでの解決策（動的登録、OpenID Federationなど）には、登録後のクライアントIDのライフサイクル管理（例：大量の未使用クライアントIDの蓄積）といった課題がありました。
  • 問題点:
    • エフェメラルなクライアントに対するクライアントIDの適切な管理とライフサイクル。
    • 動的登録後の余分なクライアントIDのクリーンアップの必要性。
    • クライアントのメタデータホスティングの必要性。
  • 提案内容: PAR（Pushed Authorization Requests）を基盤とし、クライアントIDを明示的に使用せず、動的に自身を認証する方法を提案します。
    • PARリクエスト: クライアントはPARリクエストを行い、client_idパラメータに「dynamic」のような特別なキーワードを使用します。この際、クライアントメタデータドキュメントもプッシュします。
    • PAR応答: 認証サーバーはクライアントIDを返さず、通常のrequest_uriのみを返します。
    • 認可エンドポイント: クライアントはrequest_uriを使用して認可エンドポイントにアクセスし、ここでもclient_idとして「dynamic」キーワードを使用します。
    • トークンエンドポイント: 認証コードを取得した後、クライアントはトークンエンドポイントにリクエストを行い、再度client_idとして「dynamic」キーワードを使用し、元のプッシュされた認可リクエストで導入されたキーの証明を提供します。
  • メリット:
    • 動的登録の余分なラウンドトリップを削減し、残存するクライアントIDを削除する必要がなくなります。
    • クライアントメタデータをホストする必要がなく、インスタンス固有の情報をプッシュできます。
    • クライアントアテステーションやソフトウェアステートメントなど、クライアントの信頼インフラストラクチャに結合できる情報をプッシュできます。
  • 主要な議論点:
    • 問題の解決必要性: この問題がコミュニティ全体として解決すべきものなのか。
    • 複数のアプローチの共存: クライアントIDの問題に対する複数の異なる解決策が提案されている現状について、共存の可能性や、統一的なアプローチの必要性。
    • 適用範囲のガードレール: このアプローチが意味をなすユースケースに厳格なガードレールを設定する必要性。
  • 現状: プロトタイプの実装は機能しており、セキュリティ上の大きな懸念は発見されていません。この提案がワーキンググループで標準化を進める価値があるかどうかの議論が求められています。

10. 遅延キーバインディング (Deferred Keybinding)

  • 背景: 既存のOAuthのPoPメカニズム（DPoPやMTLS）は、トークンが発行される前に、キーの証明（所有証明）を提示することを要求します。これにより、認証サーバーのなりすまし攻撃を防ぎます。しかし、現実世界には、トークンが発行された後にキーの所有証明が提示される必要があるユースケースが存在します。
  • 問題点:
    • 異なるドメインからのキーをバインドする必要がある場合、ターゲットリソースはプレゼンターを検証できるが、リクエスト元のエンティティは同じ方法でリクエストを行うことができない。
    • IoTデバイスのハードウェア発行キーなど、デバイス上でキーが保持され、そのキーにトークンがバインドされるが、発行時にキーの所有証明を提示できないシナリオ。
    • Spiffeエージェントがワークロードの代わりにトークンを発行し、ワークロードに引き渡す際、Spiffeエージェントがワークロードの秘密鍵を所有していないシナリオ。
  • 提案内容と方向性の選択肢: ワーキンググループに対して、この問題にどのように対処すべきかの議論が求められています。
    • オプション0: 無視する: この行為を「悪い習慣」と宣言し、非推奨とする。しかし、現実にはすでにこの方法で解決しているケースがあるため、これを止めることはできない。
    • オプション1: 既存のパターンを文書化する: 既存のパターンとユースケースを文書化し、非常に悪い慣行にはガードレールを設定し、意味のある場合にのみ適用されるようにする。
    • オプション2: プロトコル仕様を構築する: 保持していない確認キーをトークン要求の一部として提示する方法を形式化するプロトコル拡張を構築する。これはMTLS、DEOP、HTTP SIGなどの既存の署名ベースのメカニズムに統合される可能性がある。
    • オプション3: トークンデータ仕様を追加する: JWTやイントロスペクションなどのトークンデータ仕様に、「トークンがバインドされたキーであるが、発行時には提示されなかった」ことを示す方法を追加する。
  • 引用: “The basic idea boils down to allowing the client to say “Hey I have my identity that I can prove but the token that you give me I want it bound to somebody else’s keys.” And so I want you to give me back the token that is bound to somebody else’s keys And trust me I am allowed to do this” (基本的な考え方は、クライアントが「私は自分のアイデンティティを証明できるが、あなたが私に与えるトークンは、他の誰かのキーにバインドしてほしい」と言うことを許可することに帰着します。そして、「他の誰かのキーにバインドされたトークンを私に返してほしい。そして、私はこれを行うことが許されていると信じてほしい」ということです。)
  • 主要な議論点:
    • 問題の緊急性: この問題は他の場所でも見られており、対処しないと誰も助けられないという意見。
    • セキュリティリスクと誤用の可能性: このメカニズムが悪用される可能性があり、危険であるという懸念。
    • ポリシーや動的な振る舞いとの関係: この問題がポリシーや動的な振る舞いなしに完全に解決できるかは不明。
    • SAMLのsubject_confirmation_dataとの類似性: SAMLのsubject_confirmation_data(cnf)クレームとの概念的な類似性。
    • コミュニティの工数: オプション2または3の構築には多大な労力がかかるという懸念。
    • Brianの意見: オプション0（何もしない）を好むと表明。理由は「怠惰」と「作業に消耗されることへの懸念」。
  • 現状: ドラフトは問題提起を目的としており、採用の可否は問われていません。メーリングリストでの議論を通じて、ワーキンググループとしてどの方向性に進むかについて合意を形成することが提案されました。

OAuth WG Session の録画

（最後に一瞬私も出てきますw）

（SVIDについてのメモ）

SVID（SPIFFE Verifiable Identity Document）は、SPIFFEによって定義されたワークロード（アプリケーションやサービスなど）が自分の「身元（アイデンティティ）」を証明するためのデジタル証明書です。SVIDは、現実世界における「パスポート」のような役割を果たします。

主な特徴：

  • SPIFFE IDを含む：ワークロード固有の一意な識別子（spiffe://で始まるURI）が含まれています。
  • デジタル署名付き：信頼ドメイン内の認証局（CA）が署名しているため、第三者がその真正性を検証できます。
  • 形式：X.509証明書形式（X.509 SVID）またはJWT形式（JWT SVID）として標準化されています。
  • 短期間有効＆自動更新：セキュリティのため有効期間は短く、自動的にローテーションされます。
  • 用途：サービス間のmTLS（相互TLS）通信やAPI認証など、IPアドレス等のネットワーク情報に依存せず、安全にワークロード同士の通信の認証・認可を実現できます1345。

イメージとして、「SVID」は下記のような情報を保持しています：

  • 単一のSPIFFE ID
  • 必要に応じて、公開鍵
  • デジタル署名

サービス（ワークロード）は、SPIFFE Workload APIを介して自分専用のSVIDを取得し、通信相手に提示することでゼロトラスト環境実現の中心的な役割を担います。

Pin

コメントを残す

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