idbok

Appearance

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

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

1. 概要 ​

FAPI (Financial-grade API) Working Group は、金融 API をはじめとする高保証用途向けに OAuth 2.0 のプロファイルを策定する OpenID Foundation のワーキンググループである。2024 年 7 月時点の共同議長は Nat Sakimura (NAT Consulting)、Dave Tonge (Moneyhub)、Dima Postnikov、Anoop Saxena (Intuit) の 4 名で、エディタ作業は Daniel Fett (Authlete)、Dave Tonge、Joseph Heenan (Authlete) を中心に進められていた。

2024 年 7 月は FAPI WG にとって 2 つの大きな出来事が並走した月 である。第一に、FAPI 2.0 Security Profile に「Refresh Token Rotation を許容するか否か」を確定させる WG 投票が公示・実施され、Option 1 (全面禁止維持) と Option 5 (例外条件付き許容) のいずれかを選ぶ簡単過半数決が 7/17 の Atlantic コールで取られた。第二に、OpenID Foundation が米 Consumer Financial Protection Bureau (CFPB) の Personal Financial Data Rights ルールメイキングに対し、5/16 のオープンレター（CFPB に対して FAPI を Communication Protocol の Qualified Industry Standard (QIS) として採用するよう求めた書簡）に続く詳細ガイダンス文書を 7/24 に公開し、FAPI ファミリーをセキュアな通信プロトコルとして CFPB ルールに位置付けるよう推奨 した。FAPI WG の規範作業（投票・Issue 起票）と、その規範を米国規制の参照標準として位置付けようとする渉外活動とが、同月内に同時進行した格好である。

加えて、Joseph Heenan が FAPI 2.0 Security Profile Implementer's Draft 2 + DPoP の認定テストスイートのベンダーベータ参加募集 を 7/22 に投函した。FAPI 2.0 における DPoP 認定の運用準備が 7 月内に本格化し、Filip Skokan が即日翌日に OP/RP 実装での協力を表明している。

Issue は #703 (BCP 195 引用文言の簡素化)、#704 (CISA Cyber Safety Review Board 勧告のスコープ検討)、#705 (FAPI 1 における request object の typ 適合テスト)、#706 (security scheme、Lukasz Jaromin、月末起票) の 4 件が ML 周知された。Issue #704 は翌月以降の PR #514 (key compromise 周りの Security Considerations 補強) の起点となる重要な提起である。

openid-specs-fapi ML の 2024-July アーカイブ には 19 件の投稿が収録されている。8 月の 11 件、6 月の比較的静かな水準に対し、7 月は投票関連の事務通告と Issue 起票が重なって投稿数が増えた月である。

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

注: ML #003161 の Lukasz Jaromin による Issue #706 (security scheme) と、翌月 8/16 に Dag Sneeggen が ML 周知した Issue #706 (Unclear Section 5.4 of FAPI2 Security Profile) は 本文題目が異なる。Bitbucket Issue 番号の付番タイミングの差異か、あるいは同一番号への複数の言及である可能性があるが、7/30 投稿の本文には具体的な技術記述が伴わず、後続の議論連鎖も確認できないため、本記事では「7/30 時点で Lukasz Jaromin が security scheme 関連の Issue を ML に持ち込んだ事実」までを記録する。

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

2024 年 7 月内には FAPI 2.0 Security Profile / Attacker Model の新しい公開ドラフト版（Draft -04）は公開されなかった（Draft -04 は 2024-12-08 公開）。一方で、WG 全体の規範プロセスとしては「Refresh Token Rotation 採決」が最大のアクション であり、これは Implementer's Draft 2 後の編集判断のうち、Final 化前に WG 内で確定させるべき最後級の規範論点であった。

2-1. Refresh Token Rotation の WG 採決（7/17 実施） ​

ML #003150 (Nat Sakimura, 7/4) で公示された投票は、FAPI 2.0 Security Profile が Refresh Token Rotation を許すべきか否かを、簡単過半数決 で WG メンバーが選ぶ手続である。背景は 7/3 の Atlantic コールで Lukasz が提示した 6 つのオプションのうち、議論を経て生き残ったのが Option 1 と Option 5 の 2 案であったことによる。

選択肢規範内容賛成根拠反対根拠
Option 1FAPI 2.0 SP の shall not use refresh token cycling 要件を維持相互運用性運用上の理由で RT ローテーションを時折使う実装が仕様準拠不能
Option 5通常はローテーション禁止だが、例外条件付きで許容。「AS は新 RT がクライアントから初めて使用されるまで古い RT を保持し、新 RT 使用後に古い RT を無効化する」というルールRT は通常使われない／適合テストでカバーされる範囲では生態系は相互運用的AS 側に追加実装が必要

公示文 (ML #003150) は Option 5 のルール部分を次のように規定している（原文）。

AS must keep the old RT until the client uses the new RT for the first time. If the new RT is used the AS shall invalidate the old RT.

採決方法は OpenID Process に則った WG 内 simple majority vote で、欠席者は議長宛にプロキシ指名を書面通告できる。7/17 のリマインダー ML #003155 では Option 1 と Option 5 の二択構造があらためて確認されている。この投票は「FAPI 2.0 が Final へ進む前に確定させておくべき規範上の最終分岐」のひとつ として位置付けられ、8 月以降の Final 化前 PR レビュー（PR #512-#516）に直接接続する。

2-2. Issue #703: BCP 195 引用文言の簡素化 ​

ML #003151 (Joseph Heenan, 7/5) で起票された Issue #703 は、FAPI 2.0 Security Profile の TLS 文言から when using TLS 1.2, という限定句を取り除く提案である。

  • 現行: when using TLS 1.2, shall follow the recommendations for Secure Use of Transport Layer Security in [@!BCP195]
  • 提案: shall follow the recommendations for Secure Use of Transport Layer Security in [@!BCP195]

Heenan の根拠は、BCP 195 が近い将来 TLS 1.3 向け要件を含めて改訂される見通しがあり、その時点で FAPI 側の version-specific qualifier が陳腐化する点である。Heenan は「BCP 195 には既に少なくとも 1 つの TLS 1.3 関連要件が含まれており、ただし主に Web サーバ向けかもしれない」と注釈を付けた。これは 8 月の PR #513 (BCP 195 の新版 RFC 9325 への移行ノート追加) に直接接続する提案である。

2-3. Issue #704: CISA Cyber Safety Review Board 勧告への対応 ​

ML #003152 (Joseph Heenan, 7/7) で起票された Issue #704 は、CISA Cyber Safety Review Board が 2024 年 3 月 20 日に公開した Microsoft Exchange Online 侵入事案（Storm-0558、2023 年夏）のレビュー報告に含まれる勧告のうち、FAPI WG がスコープに含めるべきものを特定する提起である。

Heenan が参照した勧告は次の 3 件。

  • Recommendation 13: OpenID Foundation を含む標準化団体に対し、コアなデジタルアイデンティティ標準のプロファイルを「key rotation, stateful credentials, credential linking, key scope の要件を含む形に更新または開発する」よう要求
  • Recommendations 11 & 12: OAuth 2 DPoP (bound tokens) および OpenID Shared Signals & Events の実装、ならびに国家アクターレベルの高度脅威への対応を含む標準更新を強調

Heenan は FAPI WG のスコープ内候補として「key rotation」「key scope」「Shared Signals & Events 仕様」の 3 領域を挙げる一方、「stateful credentials」「credential linking」の用語、および「国家アクターレベルの脅威」を WG スコープでどう具体化するかについて不確実性を率直に表明した。Issue #704 は 8 月の PR #514 (key compromise シナリオに関する Security Considerations 補強、"single use keys" → "single purpose keys") の起点 であり、7 月時点では問題提起と論点整理のフェーズに留まる。

2-4. Issue #705: FAPI 1 における request object の typ 適合テスト ​

ML #003154 (Joseph Heenan, 7/10) で起票された Issue #705 は、Issue #684 を経て FAPI 2.0 側では request object の typ ヘッダ取り扱いが整理された一方、元の相互運用問題が発見されたのは FAPI 1 であり、FAPI 1 のテストスイートに対応する適合テストを追加すべきかを WG に問う ものである。Heenan は認定スイート責任者として、仕様改訂と認定テストの整合性を埋めるための運用判断を WG に求めた格好で、これは 8 月の Issue #708 (FAPI 1 にあったクエリ経由アクセストークン受理禁止条文が FAPI 2 で欠落、認定テスト判定基準への影響) と同種の「認定運用 vs 仕様階層」論点の系譜にある。

2-5. FAPI 2.0 + DPoP 認定テストスイートのベンダーベータ ​

ML #003158 (Joseph Heenan, 7/22) で、OIDF Certification Team が FAPI 2.0 Security Profile Implementer's Draft 2 with DPoP の認定テスト群を完成させ、これが OIDF が DPoP を扱う初の認定試験となるためベンダーベータ参加者を募集する旨が告知された。参加ベンダーは DPoP プロファイルの無償認定リスティングと、次回 OIDF ワークショップでの紹介機会というインセンティブが提示されている。連絡先は certification@oidf.org。

翌日 ML #003159 (Filip Skokan, 7/23) で Filip Skokan が「OP と RP の両実装で協力する」と即応した。Skokan は当時 node-oidc-provider および panva/oauth4webapi 等の主要オープンソース OAuth 実装の作者として知られており、初期ベータの妥当性検証に大きく寄与したと推測される。

3. ミーティングと議論 ​

FAPI WG は Atlantic コール（水曜 14:00 UTC、隔週）と Pacific コール（金曜朝、Asia-Pacific 帯、隔週）を運用している。Bitbucket wiki 上の議事録ページ（FAPI_Meeting_Notes_2024-07-03_Atlantic 等）は SPA レンダリングのため本記事執筆経路で本文を直接抽出できないが、ML 投稿のアジェンダ・投票結果・後続議論から各コールの内容を再構成する。

2024-07-03 Atlantic コール ​

ML #003145 で公示されたアジェンダは次の 7 項目。

  1. Roll Call (Dave/Nat)
  2. Adoption of Agenda (Dave/Nat)
  3. Events (Mike L.)
  4. External Orgs & Liaisons (Mike L.)
  5. Issue #694: Refresh token clause readability (Dave)
  6. PRs & Issues (Dave)
  7. AOB (Nat)

「Mike L.」は OpenID Foundation の Director of Marketing & Communications を務める Mike Leszcz を指す。通常アジェンダと異なる特徴は議題 #5 に Issue #694 (Refresh token clause readability) が単独項目として立てられている ことで、これは Refresh Token Rotation 議論を本コールで集中討議するための明示的な意図である。

7/3 コールの議論内容は ML #003150 (Nat Sakimura, 7/4) で間接的に再構成できる。Lukasz が「6 つのオプション」を提示したが、コール内で議論が収束しきれず、最終的に Option 1 と Option 5 の二択を 2 週間後 (7/17) に簡単過半数決で確定させる手続が決まった。Lukasz の本名は Lukasz Jaromin (Allegro Pay 所属、Issue トラッカー上で security scheme 関連の起票実績あり) と推測される。

Nat Sakimura が翌日 (7/4) 議事録公開通知 ML #003149 と Refresh Token Rotation 採決公示 ML #003150 を投函している。

2024-07-10 Atlantic コール ​

ML #003153 で公示されたアジェンダは標準構成 (Roll Call / Adoption / Events / External Orgs / PRs / Issues / AOB)。同日中に Joseph Heenan が Issue #705 を ML 周知 (ML #003154) しており、コール中に FAPI 1 conformance test の typ 検査追加が議題化されたと推測される。

2024-07-17 Atlantic コール（Refresh Token Rotation 採決回） ​

ML #003156 で公示されたアジェンダは次の 8 項目。

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

投票結果そのもの（Option 1 / Option 5 のどちらが採択されたか、賛成・反対・棄権数）は ML 上では明示されていないが、その後の FAPI 2.0 Security Profile 最終公開版（2025-02-22 Final）の Section 5.3.1.1 における Refresh Token の取り扱いから遡って読むと、Option 5 系列の「例外条件付き許容」方向で整理された と解釈できる。すなわち WG は「ローテーションの全面禁止」ではなく「特定の運用条件下での古 RT 保持・新 RT 初使用後の旧 RT 無効化」を許容する規範に着地した。これは Final 化に向けた最後の実質的な規範分岐のひとつであった。

2024-07-24 Atlantic コール ​

Dave Tonge の リマインダー (ML #003160) のみが ML 上に残り、アジェンダ詳細は ML には投函されなかった。この日は OpenID Foundation が同日に Guidance to the CFPB regarding US Open Banking を公開した日でもあり、コール内で米 CFPB ルールメイキングと FAPI の関連が触れられた可能性が高い。

2024-07-31 Atlantic コール ​

Dave Tonge の リマインダー (ML #003162) のみが ML 上に残る。Atlantic コールが biweekly schedule である一方で、7/24 と 7/31 の連続開催が記録されている点から、Refresh Token Rotation 採決後の継続作業のために週次運用に切り替わっていた 可能性がある。これは 8 月の Atlantic コール (8/14, 8/21, 8/28) が 3 週連続で開催される運用にも接続する。

Pacific コール ​

2024 年 7 月の ML 投稿には Pacific コールのアジェンダ・リマインダー投稿が確認できない。Pacific コールは隔週運用かつ夏季は不定期開催であり、7 月中に開催月の隙間に当たった、もしくは開催されなかったと考えられる。9 月から再開する。

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

2024 年 7 月の openid-specs-fapi ML は 19 件の投稿を含む。技術論点を含むスレッド・告知を以下に整理する。

Refresh Token Rotation 採決公示と背景 — 7/4 Nat Sakimura ​

ML #003150 (Notice of WG Votes for Refresh Token Rotation) と ML #003155 (follow-up) の 2 投稿は、7 月の FAPI WG 規範プロセスの中核 をなす。Option 1 (全面禁止) と Option 5 (例外条件付き許容、AS が新 RT 初使用まで旧 RT を保持) の二択を 7/17 に簡単過半数決する公示で、論点の対立軸は「相互運用性の純度（Option 1）」対「運用現場の実装柔軟性（Option 5）」である。

Option 5 のコアルールである AS must keep the old RT until the client uses the new RT for the first time. If the new RT is used the AS shall invalidate the old RT. は、Token 持ち替え期間中のリプレイ攻撃耐性を担保しつつクライアントの停止リスクを下げる 設計で、OAuth 2.0 Security BCP の議論動向とも整合的である。Lukasz による 6 オプション提示から 2 オプションに絞り込まれる過程は、WG 内で「特定オプションへの強い反対が少ない案」を残す現実的なプロセスであった。

EUIDW-4-Payments update: dropping OAuth — 7/2 開始 Anders Rundgren / Joseph Heenan ​

ML #003144 (7/2 Anders Rundgren) → ML #003147 (7/3 Joseph Heenan) → ML #003148 (7/3 Anders Rundgren) の 3 投稿スレッド。

Rundgren は EU Digital Identity Wallet (EUIDW) の 4-Payments 関連仕様が「OAuth を捨てた」と主張し、PISP is now just a backend process, technically no different than Stripe & Co, while the wallet only communicates with the Merchant. という具体的な観察を提示した。Heenan は反論として「このフローは依然として OAuth 2.0 を基礎としている。OpenID for Verifiable Presentations が OAuth 2.0 の上に構築されているため、Rundgren が言わんとしたのは『銀行に対する標準的な OAuth 2.0 認可コードフローを踏襲しない』ということではないか」と整理した。

Rundgren は再反論で「改訂されたフローは OAuth 2.0 に何ら類似していない」「Verifiable Presentations の用語自体に問題がある（マーチャントは真の verifier ではない、ペイヤーは verifier と直接接触しない）」と主張し、加えて「Berlin Group のこの分野へのアプローチは主流になるには扱いづらすぎる」という FAPI / Open Banking 全般への踏み込んだ批判を展開した。

このスレッドは FAPI WG 内で合意を取る議論には進まなかったが、「OpenID for VP / EUDIW と FAPI / Open Banking の関係をどう整理するか」という WG 横断的な論点が ML 上に顕在化した最初期の記録のひとつ として記録される。

Issue #703 (BCP 195) と Issue #704 (CSRB 勧告) と Issue #705 (FAPI 1 typ) — 7/5〜7/10 Joseph Heenan ​

3 件の Issue 起票は ML #003151 (7/5 #703)、ML #003152 (7/7 #704)、ML #003154 (7/10 #705) で連続投函された。Heenan の Authlete 兼 OIDF 認定スイート責任者という立場から、「仕様の表現の現代化（#703）」「外部からの規範要請への対応スコープ（#704）」「仕様改訂と認定テストの整合性（#705）」という 3 つの異なる種類の論点を同時並行で提起 した格好である。

特に Issue #704 は CISA Cyber Safety Review Board の Microsoft Exchange Storm-0558 事案レビュー（2024-03-20 公開）の勧告を WG スコープに翻訳しようとする提起で、Heenan 自身が「key rotation / key scope / Shared Signals & Events は WG スコープに収まるが、stateful credentials と credential linking の用語は不明確、国家アクター脅威の具体化方法も不確実」と率直に問題範囲の限界を表明した点が特徴的である。これは「規範作業の起点としての問題設定の不確実性を ML 上で明示する」WG 文化を反映している。

FAPI WG Overview 更新要請 — 7/21 Brian Campbell ​

ML #003157 (Brian Campbell, 7/21) で Campbell (Ping Identity) は、openid.net/wg/fapi/ の公式説明文が現状の WG 活動を反映していない旨を指摘した。引用された旧説明文は次のとおり。

The FAPI working group provides JSON data schemas, security and privacy recommendations and protocols to enable applications to utilize the data stored in a financial account...

これは FAPI WG の発足当初（2016 年前後）に重点が置かれていた「金融アカウントデータ利用のための JSON スキーマ」というスコープ表現で、2024 年時点の FAPI 2.0 Security Profile / Attacker Model / Message Signing 等の規範作業実態と乖離していた。Campbell の指摘は実害を伴うものではないが、FAPI WG が「データスキーマ作業から OAuth プロファイル策定中心に重心が移った」過程を公式ページが追随できていない という認識のずれを ML 上に記録した形で、後の WG ページ更新の起点となる。

FAPI 2.0 + DPoP 認定テスト募集 — 7/22 Joseph Heenan / 7/23 Filip Skokan ​

ML #003158 (7/22 Heenan) と ML #003159 (7/23 Skokan) のペアは、FAPI 2.0 Security Profile Implementer's Draft 2 with DPoP の認定テストの公式運用に向けた最後のベータ段階を象徴 する。OIDF が DPoP を扱う初の認定試験であるため、ベンダー側の実装多様性を吸収する事前検証が必要であった。Skokan の即応は OP/RP 双方の実装提供を伴うもので、初期ベータの相互運用検証の質を高めたと推測される。

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

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

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

4 件の特徴は 「仕様文言の現代化（#703）」「外部規範要請のスコープ翻訳（#704）」「仕様改訂と認定テストの整合性（#705）」「security scheme（#706、詳細未展開）」 という多様な切り口での問題提起が同月内に集中していることである。Heenan 単独で 3 件起票している点は、認定スイート運用責任者の立場から仕様完成度のギャップを集中的に拾い上げる役割を担っていたことを示す。

GitHub openid/fapi リポジトリは Bitbucket の公開ミラー的位置付けで、編集ワークフローの主軸は引き続き Bitbucket 上の PR / Issue で運用されていた。7 月内に WG 内レビューに付された PR は ML 上には明示されていないが、8 月の PR #512〜#516（Final 化前最終 PR 群）の編集はこの時期から準備されていたとみられる。

6. 関連イベント ​

7/24: OIDF Guidance to the CFPB regarding US Open Banking ​

Guidance to the CFPB regarding US Open Banking (2024-07-24 公開) は、5 月 16 日のオープンレター（Letter to the CFPB on US Open Banking、Gail Hodges 名義）に続く OpenID Foundation の対 CFPB 渉外活動の第二弾である。執筆者は Gail Hodges (OIDF Executive Director)、Joseph Heenan、Dima Postnikov、Mark Haine、Mike Leszcz、Elizabeth Garber の連名。

主要な主張は次のとおり。

  • CFPB はルールメイキングにおいて ID データの交換のためのセキュアな通信プロトコルの利用を確保すべき
  • 通信プロトコルとしては FAPI ファミリーを採用すべき（FAPI が OAuth 2.0 を高セキュリティ用途向けに強化し、OAuth 2.0 が対処しない重大なセキュリティギャップを塞ぐ点、および任意性を減らすことで生態系内外の相互運用性を促進する点を強調）
  • 補完標準として OpenID Federation（オンボード済み参加者間で迅速に信頼確立） と Shared Signals（セキュリティイベントを通知し動的なアクセス・認可判断を可能にする） を推奨
  • 国際的な FAPI 採用実績（UK Open Banking、Australia、Brazilian Open Finance、Saudi Arabian Monetary Authority、UAE、Chile、Colombia、Canada、US FDX、German Verimi、Norwegian HelseID 等のオープンバンキング／オープンデータ生態系）を実証根拠として提示
  • 標準化された通信プロトコルは 相互運用性、市場投入時間、セキュリティ、国際整合性に資する

なお、本ガイダンス文書では「Qualified Industry Standard (QIS)」という用語は使用されておらず、QIS 区分への明示的な言及は 5/16 オープンレター側でなされている。

このガイダンス文書は、CSRB が OpenID Foundation に対して標準のプロファイル更新を求めた勧告（Issue #704 で Heenan が引用したのと同じ CSRB レポート）に対する OIDF 側の応答の一部としても位置付けられる。すなわち 7 月の FAPI WG では、CSRB 勧告に対し (a) 仕様内部での Issue #704 起票による技術論点化、(b) CFPB 渉外による FAPI の規制参照標準化、という 2 方向の応答が同時並行で進んだ ことになる。

5/16 オープンレターからの連続性 ​

5 月 16 日の Letter to the CFPB on US Open Banking はガイダンス文書の前段となる。主要な主張は「Communication Protocol の QIS を Data Format の QIS から分離して要求すべき」「Sub-standardization なき実装は『一貫してセキュアではない』」というもので、4 つのリスクカテゴリ（相互運用性、市場投入時間、セキュリティ、国際整合性）を提示した。7/24 ガイダンスはこの 5 月レターを技術詳細レベルに具体化した位置付けである。

IETF 120 (Vancouver, 2024-07-20〜26) ​

7 月 20-26 日にバンクーバーで開催された IETF 120 では、IETF OAuth WG での DPoP、OAuth 2.1、OAuth Security BCP の議論が継続していた。FAPI WG 内では IETF 120 を明示的に振り返るスレッドは 7 月の ML には現れなかったが、FAPI 2.0 が依存する上位標準（DPoP は RFC 9449 として 2023-09 に発行済み、OAuth Security BCP は当時 draft-ietf-oauth-security-topics、OAuth 2.1 は draft-ietf-oauth-v2-1）の進捗が FAPI 2.0 Final 化のタイミング判断に影響していた。Joseph Heenan による 7/22 の DPoP 認定テスト募集は、DPoP RFC 化後の実装認定運用への移行を象徴する。

7. 今後の予定 ​

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

  • Refresh Token Rotation 採決の結果反映: 7/17 採決を受けた FAPI 2.0 Security Profile の編集差分を 8 月以降の PR に反映
  • Issue #703 (BCP 195 文言) の PR 化: 8 月の PR #513 として実装される運び
  • Issue #704 (CSRB 勧告対応) の具体化: key compromise シナリオの Security Considerations 補強として 8 月の PR #514 に発展する見込み
  • Issue #705 (FAPI 1 typ 適合テスト) の対応: 認定スイート側の追加テストとして整理
  • FAPI 2.0 + DPoP 認定テストのベンダーベータ拡大: Filip Skokan に続く他ベンダーの参加募集を継続
  • CFPB ルールメイキングへの追加働きかけ: 7/24 ガイダンス公開後、CFPB の最終ルール公示（2024 年秋予定）に向けて OIDF 渉外活動を継続
  • Atlantic コール継続: 隔週 / 週次 schedule で 8 月の Final 化前 PR レビューに移行
  • Pacific コール再開: Asia-Pacific 帯のメンバー参加を 9 月以降に通常運行へ復帰

8. 参考情報源 ​

メーリングリスト ​

議事録 (Bitbucket wiki) ​

  • FAPI Meeting Notes Wiki (Bitbucket) — 議事録所在（FAPI_Meeting_Notes_2024-07-03_Atlantic、FAPI_Meeting_Notes_2024-07-10_Atlantic、FAPI_Meeting_Notes_2024-07-17_Atlantic、FAPI_Meeting_Notes_2024-07-24_Atlantic、FAPI_Meeting_Notes_2024-07-31_Atlantic）

Issue トラッカー (Bitbucket) ​

OpenID Foundation 公式アナウンス ​

仕様 ​

外部参照 ​

関連リソース（OpenID Foundation） ​