Skip to content

OpenID Foundation FAPI WG 活動レポート (2024年6月)

執筆日: 2026-05-21(2024 年 6 月の活動を約 1 年 11 か月遡って再構成した遡及レポートです)

1. 概要

FAPI (Financial-grade API) Working Group は、金融 API をはじめとする高保証用途向けに OAuth 2.0 / OpenID Connect のプロファイルを策定する OpenID Foundation のワーキンググループである。FAPI は単一仕様の名称ではなく、Baseline / Advanced(FAPI 1)と Security Profile / Attacker Model(FAPI 2)からなる仕様ファミリーで、UK Open Banking、Brazil Open Finance、Australia の CDR など各国の金融 API 標準の参照ベースとして採用されてきた。2024 年 6 月時点の共同議長は Nat Sakimura (NAT Consulting)、Dave Tonge (Moneyhub)、Dima Postnikov、Anoop Saxena (Intuit) の 4 名。エディタ作業は Daniel Fett (Authlete)、Dave Tonge、Joseph Heenan (Authlete) を中心に進められていた。

2024 年 6 月の FAPI WG は、FAPI 2.0 Security Profile を Final 化する前の「最後の規範ギャップ洗い出し」フェーズ に位置付けられる月であった。月内に Issue が 4 件集中起票され(#699 Daniel Fett 6/6、#700 Nat Sakimura 6/12、#701 Joseph Heenan 6/13、#702 Joseph Heenan 6/26)、いずれも翌 7 月以降の Refresh Token Rotation 採決(7/17)や BCP 195 文言改訂(7/5 Issue #703)に直結する論点を抱えていた。中でも Daniel Fett の Issue #699 は、IETF OAuth WG で並行進行していた OAuth 2.0 Security Best Current Practice(当時 draft-ietf-oauth-security-topics-29)に対する FAPI 2 の構造的ギャップ分析 であり、FAPI 2 Final 版が「Security BCP を準拠基盤として位置付けるなら、どの規範を FAPI 側で明示すべきか」という Final 化前の最大級の宿題を WG に突き付けた。

加えて 6/15 には Gail Hodges (OIDF Executive Director) が ML 上で CFPB と米国・カナダのオープンバンキング・サブグループ立ち上げ を呼びかけ、活発な米加規制連携のための専用 Slack チャネル運用とリアルタイム調整体制を提案した。これは翌月(7/24)に公開される Guidance to the CFPB regarding US Open Banking の起草チームを組成する動きでもあり、仕様内部の Final 化作業と、その仕様を米国規制の参照標準として位置付ける渉外作業が同じ月に立ち上がった ことを示す。

外部活動としては、6/18 に Gail Hodges が ブラジル G20 の Digital Government and Inclusion Workshop に登壇し、Brazil Open Finance が FAPI を採択していること、OpenID Connect が世界 30 億超のユーザーに利用されていること、SIDI Hub による国境横断アイデンティティの 25 カ国超協調イニシアチブを紹介した(Digital Identity at the G20)。FAPI そのものが G20 の文脈で語られる初期の機会のひとつである。

openid-specs-fapi ML の 2024-June アーカイブ には 12 件の投稿が収録されている。7 月の 19 件、5 月の比較的密な議論に対し、6 月は Issue 起票と少数の深い技術スレッドに集中したやや静かな月 である。

月内の主要な動きは以下のとおり(日時は ML 投稿の Date ヘッダ UTC を基準とする)。

2. 公開された仕様・ドラフト改訂

2024 年 6 月内に FAPI 2.0 Security Profile / Attacker Model の新しい公開ドラフト版(Draft -04)は公開されていない(Draft -04 は 2024-12-08 公開)。6 月の規範作業は Final 化前のギャップ洗い出しと Issue 起票 が中心であり、ドラフト本体への変更は Issue を経て後続月の PR に集約される運用であった。月内に ML 上で公開された主要な技術論点は以下のとおり。

2-1. Issue #699: FAPI 2 vs. Security BCP Gap Analysis

ML #003133 (Daniel Fett, 2024-06-06 07:59 UTC) で起票された Issue #699 は、当時 IETF OAuth WG で進行していた draft-ietf-oauth-security-topics-29 (OAuth 2.0 Security Best Current Practice -29) に対する FAPI 2 の規範ギャップを 5 項目で整理したものである。Fett は Authlete 在籍中のエディタ立場から、Security BCP の各推奨を FAPI 2 が継承・上書き・無言のままにしている箇所を網羅的に拾い上げた。

項目Security BCP -29 の規範FAPI 2 の現状
Access Token 権限制限アクセストークンを「必要最小限に制限」し、特定の Resource Server に対する audience restriction を明示すべき明示的な実装規範がない
Client ID への影響制御クライアントが自身の client_id や正当なリソースオーナーと混同される claim に影響を与えられないようにすべき明示的なカバーがない
TLS のエンドツーエンド要件TLS 保護エンドポイントに加え、クライアントとリソースサーバ間の end-to-end TLS が必要。ネイティブクライアントのループバック以外で認可レスポンスを暗号化なしで送信してはならないエンドツーエンド TLS の明示的記述が不足
In-Browser CommunicationHTTP リダイレクトの代わりに postMessage 等を使う場合、メッセージ発信者・受信者の両方を検証すべき明示的な扱いがない
CORS ポリシーToken / Metadata エンドポイントでは CORS 許容、Authorization エンドポイントでは禁止現行の規範がない

Fett は「いくつかは corner case のみ影響する、または推奨レベルにとどまる項目だが、議論したい」と中立的に問題提起した。本 Issue は FAPI 2 が Security BCP の単純な superset ではなく、BCP の特定項目を意図的に省略・上書きしている事実を WG が文書化すべき という構造的な指摘であり、Final 化に向けた最大級の規範レビュー項目として 6/12 Atlantic コールに単独議題として組み込まれた。

2-2. Issue #700: TLS 1.2 用 4 cipher リスト削除と BCP195 への一本化

ML #003136 (Nat Sakimura, 2024-06-12 14:36 UTC) で ML 周知された Issue #700 は、FAPI 仕様に従来ハードコードされていた「TLS 1.2 で許容される 4 つの cipher suite のリスト」を削除し、BCP 195(当時の RFC 7525、後に RFC 9325 で改訂)への参照に一本化する erratum 扱いの提案である。背景は BCP 195 自体が継続的に改訂されるため、FAPI 仕様側で cipher を列挙する保守コストが釣り合わない という運用判断にある。

この方針は翌 7 月の Issue #703(ML #003151 (Joseph Heenan, 2024-07-05)、BCP 195 引用文言から when using TLS 1.2, 限定句を削除する提案)と直接連動しており、FAPI WG が「TLS 規範を自前で抱え込まず BCP 195 への完全委任に移行する」方針 を 6〜7 月にかけて段階的に整理したことが分かる。

2-3. Issue #701: BCP195 改訂後の実装更新期限の明確化

ML #003139 (Joseph Heenan, 2024-06-13 15:37 UTC) で ML 周知された Issue #701 は、Issue #700 と同じ「BCP 195 への参照一本化」方針を採用した場合に 必然的に発生する運用問題 を先回りで提起したものである。Heenan の論点は、FAPI1Adv と FAPI2SP が BCP 195 を unversioned に参照している現状では、BCP 195 の新版が発行された瞬間に 認定テストを即座に更新せざるを得ず、既存実装が一夜にしてテスト不適合になる リスクが残るという点である。

Heenan が提示した解決案は次の二択である。

  • 仕様側で「BCP 195 の新版発行から 12 か月以内に準拠することを実装者に期待する。ただし変更の性質によってはより早期の対応が望ましい」といった猶予期間を明示する
  • もしくは WG として正式な立場を打ち出し、認定テストチームがそれに従って運用する

これは Heenan の OIDF 認定スイート責任者としての立場が色濃く反映された提起で、規範の現代性(BCP 195 改訂への即時追随)と認定運用の安定性(実装者への猶予)のトレードオフ を WG 全体で合意形成すべきという問題設定である。

2-4. Issue #702: Security Considerations 内の normative text

ML #003142 (Joseph Heenan, 2024-06-26 08:09 UTC) で ML 周知された Issue #702 は、FAPI 2.0 Security Profile の Security Considerations セクション内の JWKS URIs 節に 本来 informative であるべき箇所に normative requirements が混入している 旨の指摘である。Heenan が特定した 3 件は次のとおり。

  • jwks_uri エンドポイントの TLS-only 要件
  • JOSE ヘッダ x5u および jku の利用を推奨しないという規範
  • JWK セット内で同じ kid 値の重複を避けるべきという指針

Heenan は「OIDF として Security Considerations 内に normative 規範を置くことを禁じる方針が確立されているか?」という形で WG に問い、これらの規範は仕様本体の適切な節に移すべきだと示唆した。これは 仕様本体と Security Considerations の節構造の規律 に関するメタ論点であり、Final 化前の文書整備として重要な整理作業に直結する。

2-5. FAPI 2.0 Baseline Profile におけるネイティブアプリ位置付け(Koiwai/Heenan スレッド)

ML #003135 (Kosuke Koiwai, 2024-06-12 14:29 UTC) を発端とする 3 投稿スレッドでは、Koiwai (KDDI) が 「秘密鍵を安全に管理できるネイティブアプリは confidential client として動作できる、と明示している仕様はどこか?」 という問題を提起した。Koiwai の指摘は次の二項対立に整理される。

  • OAuth 2.0 (RFC 6749) はネイティブアプリを「resource owner が使うデバイス上にインストール・実行される public client」と定義
  • 一方で FAPI Implementation and Deployment Advice には iOS Secure Enclave や Android hardware-backed keystore を使った "per-installation confidential clients" の記述がある

Koiwai は「FAPI 2.0 が OAuth 2.0 プロファイルである以上、ネイティブアプリを confidential client として位置付ける際に基底 OAuth の定義との整合性に課題があるのではないか」と問うた。

ML #003137 (Joseph Heenan, 2024-06-12 15:19 UTC) で Heenan は次のように整理した。

  • 「native app」は OAuth 2.0 においてクライアントプロファイルとして定義されているのであって、公的に public client に限定されているわけではない
  • RFC 6749 §2.1 は「資格情報の機密性を維持できる」confidential client を許容している
  • RFC 6819 §3.7 はネイティブアプリでの confidential client 化が歴史的に困難だったことを認めつつ、現代では可能になったと指摘
  • 11 年前に発表された iOS Secure Enclave、デバイス/アプリ attestation がこれを可能にしている
  • RFC 8252 §8.5 が示すとおり、問題はネイティブアプリそのものではなく、共有秘密 (shared secrets) を使うアプローチである

ML #003138 (Kosuke Koiwai, 2024-06-13 03:18 UTC) で Koiwai は Heenan の整理を受け入れつつ、「適切な理解を欠く実装者がネイティブクライアントを安易に public client として分類してしまうリスク」 を懸念として残し、OAuth 2.1 がこの混乱を整理してくれることへの期待を表明した。

このスレッドは FAPI 仕様本体への直接的な編集差分には繋がらなかったが、「FAPI 2.0 が OAuth 2.0 の上位プロファイルとして、OAuth 基底仕様のグレーゾーンをどこまで明示的に再定義すべきか」 という Final 化判断のメタ論点を ML 上に明確化した記録として価値がある。

3. ミーティングと議論

FAPI WG は Atlantic コール(水曜 14:00 UTC、隔週運用だが繁忙月は週次化)と Pacific コール(金曜朝、Asia-Pacific 帯、隔週)を運用している。Bitbucket wiki 上の議事録ページ(FAPI_Meeting_Notes_2024-06-XX_Atlantic)は SPA レンダリングのため本記事執筆経路で本文を直接抽出できないが、ML 投稿のアジェンダ・Issue 起票タイミング・後続議論から各コールの内容を再構成する。2024 年 6 月の Atlantic コール開催記録は 6/5、6/12、6/19、6/26 の 4 回である。

2024-06-05 Atlantic コール

ML #003132(Nat Sakimura が開始 15 分前に投函した直前リマインダー)に標準アジェンダが付されている。

  1. Roll Call (Dave/Nat)
  2. Adoption of Agenda (Dave/Nat)
  3. Events (Mike L.)
  4. External Orgs & Liaisons (Mike L.)
  5. PRs (Dave)
  6. Issues (Dave)
  7. AOB (Nat)

「Mike L.」は OpenID Foundation の Director of Marketing & Communications を務める Mike Leszcz を指す。本コールは 6/4-7 開催の European Identity and Cloud Conference (EIC 2024) 直後にあたり、Events 項目で EIC 関連の振り返り(特に Digital Credentials Protocols WG が EIC Award を受賞したこと)が触れられた可能性が高い。Issues 議題では翌日 (6/6) に Fett が起票することになる Issue #699 の前段議論が行われていた可能性があるが、ML 上に直接の記録は残っていない。

2024-06-12 Atlantic コール(Issue #699 集中討議回)

ML #003134 (Nat Sakimura, 6/12) で公示されたアジェンダは次の 7 項目。

  1. Roll call
  2. Adoption of the agenda
  3. Events
  4. Liaisons
  5. Issue #699: FAPI 2 vs. Security BCP Gap Analysis (openid/fapi)
  6. Other issues and PRs
  7. AOB

通常アジェンダと異なる特徴は議題 #5 に Issue #699 が単独項目として立てられている ことで、これは Daniel Fett が 6/6 に起票した Security BCP ギャップ分析の 5 領域を本コールで集中討議する明示的な意図である。コール終了直後(同日 14:29 UTC)に Koiwai が ML #003135 を投函してネイティブアプリ confidential client 論点を持ち込み、続いて 14:36 UTC に Nat Sakimura 自身が Issue #700 (TLS 1.2 cipher list 削除) を ML 周知している。6/12 のコール中ないし直後で TLS / Security BCP 関連の議論が活発に展開された ことが投稿タイミングから読み取れる。

2024-06-19 Atlantic コール

ML #003141 (Nat Sakimura, 6/19) で公示されたアジェンダは標準構成。

  1. Roll Call (Nat)
  2. Adoption of agenda (Nat)
  3. Events (Mike L.)
  4. External Orgs & Liaisons (Mike L.)
  5. PRs (Dave)
  6. Issues (Dave)
  7. AOB

本コールは前日(6/18)の Gail Hodges による G20 ブラジル登壇直後にあたり、Events または External Orgs & Liaisons の項目で G20 と SIDI Hub の振り返り、および 6/15 の Hodges による CFPB/US-Canada サブグループ参加呼びかけ(ML #003140)への WG 側の反応整理が行われたと考えられる。Issues 議題では 6/6 起票の Issue #699、6/12 起票の Issue #700、6/13 起票の Issue #701 の 3 件が継続審議の俎上にあった。

2024-06-26 Atlantic コール

ML #003143 (Nat Sakimura, 6/26) で公示されたアジェンダは標準構成。

  1. Roll Call (Dave/Nat)
  2. Adoption of Agenda (Dave/Nat)
  3. Events (Mike L.)
  4. External Orgs & Liaisons (Mike L.)
  5. PRs (Dave)
  6. Issues (Dave)
  7. AOB (Nat)

同日 08:09 UTC(コール 14:00 UTC 開始の約 6 時間前)に Heenan が Issue #702 (Security Considerations 内 normative text) を ML 周知 (ML #003142) しており、Issues 議題で Issue #702 が新規論点として取り上げられた構成と推測される。

Pacific コール

2024 年 6 月の ML 投稿には Pacific コールのアジェンダ・リマインダー投稿が確認できない。Pacific コールは隔週運用かつ初夏には不定期開催であり、6 月中はアジア太平洋帯メンバーの主要参加が Atlantic コール側に集約されていた可能性がある。Pacific コールが ML 上に再び現れるのは秋以降である。

4. メーリングリストの主要スレッド

2024 年 6 月の openid-specs-fapi ML は 12 件の投稿を含む。技術論点・WG 運営に直結する主要スレッドを以下に整理する。

Issue #699: FAPI 2 vs. Security BCP Gap Analysis — 6/6 Daniel Fett

ML #003133 (Daniel Fett, 6/6)6 月で最も重要な技術投稿 である。IETF OAuth WG で進行中の draft-ietf-oauth-security-topics-29 (OAuth Security BCP) と FAPI 2 の規範を逐一照合し、5 領域(Access Token 権限制限、Client ID 制御、エンドツーエンド TLS、In-Browser Communication、CORS ポリシー)でギャップを特定した。Fett の論点は「FAPI 2 が Security BCP の単純な superset を装っているなら、欠落している規範を Final 化前に補う必要がある」という Final 化レビューの構造化提案であり、6/12 Atlantic コールの単独議題として組まれた。

Fett 自身が「いくつかは corner case のみ影響する、または推奨レベル」と注記している点が特徴的で、5 項目すべてを Final 化前に解消することを WG に強制するのではなく、各項目を個別に評価する余地を残した中立的な提起 であった。本 Issue は後の Final 版(2025-02-22 公開)における Security Considerations 増補と参照規範の明確化に繋がる起点である。

CFPB/US-Canada Open Banking サブグループ立ち上げ呼びかけ — 6/15 Gail Hodges

ML #003140 (Gail Hodges, 6/15)OIDF 渉外作業の体制化 を象徴する投稿である。Hodges は次の提案を行った。

  • 米加オープンバンキング論点に特化した小規模サブグループの組成
  • ML から OIDF Slack チャネル への議論移行(メール過多の回避と reaction time 短縮)
  • CFPB の pre-filing 手続、FDX との連携、米加間の規制相互作用に対する リアルタイム調整
  • 重要マイルストーンや決定事項はメーリングリストにアナウンスする運用
  • サブグループ参加希望者のトラッキング担当を Mike Leszcz が担当

この呼びかけは、翌 7 月 24 日に公開される Guidance to the CFPB regarding US Open Banking の起草チーム(Gail Hodges、Joseph Heenan、Dima Postnikov、Mark Haine、Mike Leszcz、Elizabeth Garber)の組成と密接に対応している。すなわち 6 月中盤の ML 呼びかけが、7 月末の CFPB 向け詳細ガイダンス公表に向けた渉外チームの公式立ち上げの起点 であった。

CFPB は 2023 年 10 月に Personal Financial Data Rights ルールメイキングを公示しており、Communication Protocol を Qualified Industry Standard (QIS) として認定する手続が進行していた。OIDF は同年 5 月 17 日に Letter to the CFPB on US Open Banking を公開し、FAPI を Communication Protocol QIS として位置付けるよう求めていた。6/15 のサブグループ呼びかけは、この 5 月レター後の継続渉外を OIDF 内部体制として恒常化する ための運用整備である。

FAPI 2.0 Baseline におけるネイティブアプリ confidential client 化 — 6/12〜6/13 Koiwai / Heenan

ML #003135 (Kosuke Koiwai, 6/12)ML #003137 (Joseph Heenan, 6/12)ML #003138 (Kosuke Koiwai, 6/13) の 3 投稿スレッドは、§2-5 で詳述した「OAuth 2.0 のネイティブアプリ public client 定義と、FAPI Implementation and Deployment Advice における per-installation confidential clients 記述との整合性」を扱った深い技術討論である。Heenan が RFC 6749 §2.1、RFC 6819 §3.7、RFC 8252 §8.5 を逐一参照しながら 「問題はネイティブアプリそのものではなく、共有秘密の使用そのものである」 という解像度の高い整理を提示した点が議論の質を高めた。

スレッドは FAPI 仕様への直接的な編集 PR には発展しなかったが、OAuth 2.1 がこの混乱を整理してくれるという見通しを Koiwai が示し、Heenan も同意する形で終結 した。FAPI 2.0 が OAuth 2.1 と並行進化する設計指向を反映する記録としても読める。

Issue #700 / #701: TLS 規範の BCP 195 への一本化と猶予期間 — 6/12〜6/13

ML #003136 (Nat Sakimura, 6/12 Issue #700)ML #003139 (Joseph Heenan, 6/13 Issue #701)対をなす提起 である。Issue #700 が「FAPI 仕様から TLS 1.2 用 4 cipher のハードコーディングを撤去し BCP 195 への参照に一本化する」erratum 提案であるのに対し、Issue #701 はその一本化を採用した場合に必然的に発生する「BCP 195 改訂時に認定テストが即座に更新され既存実装が一夜で不適合になるリスク」を予防する猶予期間設定を求める提起である。

Heenan が示した具体案「BCP 195 新版発行から 12 か月以内に準拠することを期待。ただし変更の性質によってはより早期」は、規範の現代性と実装の安定性のトレードオフ を WG が運用ルールとして明示すべきという問題設定であり、認定スイート責任者ならではの実務的観点である。両 Issue は翌 7 月の Issue #703(BCP 195 引用文言から when using TLS 1.2, 限定句削除)に直接接続する。

Issue #702: Security Considerations 内 normative text の整理 — 6/26 Joseph Heenan

ML #003142 (Joseph Heenan, 6/26)文書構造規律のメタ論点 を提起する。Heenan が指摘した 3 件の normative requirements(jwks_uri の TLS-only、x5u/jku 非推奨、kid 重複回避)は、いずれも実質的な技術規範として有効でありながら、Security Considerations という本来 informative な節に置かれている。Heenan の「OIDF として normative 規範を Security Considerations に置くことを禁じる方針はあるか?」という問いは、Final 版の節構造を整える前に WG として共有すべき編集規律 を可視化した。

5. Issue トラッカー上の動き

FAPI WG の Issue トラッカーは Bitbucket (bitbucket.org/openid/fapi/issues) で運用されている。Bitbucket Cloud は SPA レンダリングのため Issue 本文の直接取得経路は限定的だが、対応する ML 投稿から内容を把握できる。

2024 年 6 月に ML 上で起票・周知が行われた Issue は次の 4 件。

4 件の特徴は 「外部規範(Security BCP)との構造的整合性(#699)」「TLS 規範の自前管理脱却(#700)」「規範更新時の認定運用整合性(#701)」「仕様内部の節構造規律(#702)」 という性質の異なる論点が、いずれも Final 化を視野に入れた構造的整理 に収斂している点である。Heenan が単独で 2 件起票している(#701、#702)のは認定スイート責任者の立場からの集中レビューの反映であり、Fett の #699 は OAuth Security BCP と FAPI 2 の関係を Final 前に明文化する Editor 視点の問題提起である。

GitHub openid/fapi リポジトリは Bitbucket の公開ミラー的位置付けで、編集ワークフローの主軸は引き続き Bitbucket 上の PR / Issue で運用されていた。6 月内に WG 内レビューに付された PR は ML 上には明示されていないが、7 月以降の Refresh Token Rotation 採決準備に向けた論点整理がこの時期から進んでいた。

6. 関連イベント

6/4-7: European Identity and Cloud Conference (EIC 2024)

KuppingerCole 主催の EIC 2024 がベルリン(チャールス・チャップリン・プラッツ)で開催された。OpenID Foundation 関連では Digital Credentials Protocols Working Group が "Future Technologies and Standards" 部門で EIC Award を受賞 している(OpenID for Verifiable Credentials Wins EIC Award!)。FAPI WG 単独セッションは確認できないが、Daniel Fett、Joseph Heenan、Dave Tonge 等の主要メンバーが EIC に参加していた可能性は高く、6/5 Atlantic コール(EIC 直後)の Events 項目で EIC の振り返りが行われたと推測される。

6/18: G20 Brazil — Digital Government and Inclusion Workshop

Gail Hodges (OIDF Executive Director) がブラジル G20 議長国主催の Digital Government and Inclusion Workshop に登壇した(Digital Identity at the G20)。Hodges の発言要旨は次のとおり。

  • 80 億人すべてがデジタル経済に参加できるオプションを持つべきという普遍的アクセスのビジョン
  • OpenID Connect は世界 30 億超のユーザー、数百万のアプリで利用されている
  • 28 カ国以上が OpenID の Verifiable Credentials 仕様を採用
  • Brazil Open Finance / Open Insurance は FAPI を高セキュリティデータ共有標準として採択
  • 各国は国際標準採用と独自仕様策定のいずれを選ぶか慎重に判断すべき。独自仕様アプローチは「自国の人々と企業がローカル文脈の外で活躍する能力の制約」リスクを伴う
  • SIDI Hub は 25 カ国以上が参加する多ステークホルダーフォーラムで、国境横断デジタル ID 課題(国境横断商取引、教育資格、難民支援、金融サービス等)に取り組む

FAPI が G20 という国際政策フォーラムの文脈で言及される初期の機会のひとつ であり、ブラジルが Open Finance を介して FAPI を採用していることが G20 議長国の場で再確認された点は、後の FAPI Final 化(2025-02-22)の国際的正統性を補強する意味を持つ。

5/28-31: Identiverse 2024 (Las Vegas) — 6 月の議論への波及

5 月末にラスベガスで開催された Identiverse 2024 は対象月外であるが、6 月の ML 議論の文脈として一部関連する。Identiverse は北米最大のアイデンティティ業界イベントで、FAPI WG メンバーが多数登壇する場でもある。6 月初頭の Atlantic コール(6/5)の Events 項目で Identiverse の振り返りが触れられた可能性がある。

6/20-26: IETF 120 開催前夜

7/20-26 にバンクーバーで開催される IETF 120 に向けて、IETF OAuth WG では draft-ietf-oauth-security-topics-29 の議論が継続していた。Daniel Fett による 6/6 の Issue #699 起票は、Security BCP 当時版 (-29) を参照点として FAPI 2 のギャップを洗い出す作業であり、FAPI WG が IETF OAuth WG の進捗を能動的に追跡し Final 化判断に反映していた ことを示す。

7. 今後の予定

2024 年 6 月完了直後の視点で、当時 WG が次月以降に予定していた動きは以下のとおり。

  • Issue #699 (Security BCP ギャップ) の項目別解消: 5 領域それぞれを Final 化前に評価し、補強・上書き・無視のいずれかを WG で決定
  • Issue #700 / #701 (TLS 規範 BCP 195 一本化) の PR 化: 翌 7 月の Issue #703 として具体化される運び(実際に 7/5 に Heenan が ML 周知)
  • Issue #702 (Security Considerations 内 normative 整理) の対応: 仕様本体の節構造再編
  • Refresh Token Rotation 論点の確定: 後続の 7/3 Atlantic コールで Lukasz の 6 オプション提示を経て、7/17 の WG 採決へ繋がる
  • CFPB/US-Canada サブグループの正式組成: 6/15 Hodges 呼びかけを受けた Slack チャネル運用開始、7/24 公開予定の CFPB 向け詳細ガイダンスの起草
  • FAPI 2.0 + DPoP 認定テストの整備: 7/22 に Heenan からベンダーベータ募集が出される運びの準備
  • Atlantic コール継続: 隔週運用を維持しつつ、Issue 集中審議が必要な月は週次化に切り替え
  • IETF 120 (7/20-26 Vancouver) への追従: draft-ietf-oauth-security-topics の進捗を Issue #699 の評価に反映

8. 参考情報源

メーリングリスト

議事録 (Bitbucket wiki)

  • FAPI Meeting Notes Wiki (Bitbucket) — 議事録所在(FAPI_Meeting_Notes_2024-06-05_AtlanticFAPI_Meeting_Notes_2024-06-12_AtlanticFAPI_Meeting_Notes_2024-06-19_AtlanticFAPI_Meeting_Notes_2024-06-26_Atlantic

Issue トラッカー (Bitbucket)

OpenID Foundation 公式アナウンス

仕様

関連リソース(OpenID Foundation)