idbok

Appearance

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

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

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、Saudi Arabia Open Banking など各国の金融 API 標準の参照ベースとして採用されてきた。2024 年 3 月時点の共同議長は Nat Sakimura (NAT Consulting)、Dave Tonge (Moneyhub)、Dima Postnikov、Anoop Saxena (Intuit) の 4 名。エディタ作業は Daniel Fett (Authlete)、Dave Tonge、Joseph Heenan (Authlete) を中心に進められていた。

2024 年 3 月の FAPI WG は、翌 4 月 24 日に Dave Tonge が起動する FAPI 2.0 Security Profile の Working Group Last Call (WGLC) を見据え、Final 化前に潰しておくべき編集論点と規範論点を集中的に Issue トラッカーへ起票した「準備月」 にあたる。月内に新規起票された Issue は #677 から #688 までの 12 件 で、起票者は Nat Sakimura・Tim Würtele (SECtim)・Brian Campbell・Joseph Heenan・Ralph Bragg・Jacob Ideskog・Dima Postnikov と多岐にわたる。WGLC 直前にこれだけ集中して Issue 数を伸ばせたこと自体が、Final 化作業が WG 内で具体的に進展していたサイン である。

もう一つの大きな動きは、3 月 15 日に Gail Hodges (OIDF Executive Director) が FAPI WG メーリングリストに「ISO PAS プロセスをリードする WG メンバー募集」を投函した ことである（ML #003077）。Hodges は OpenID Connect Core を ISO/IEC 26131 として ISO PAS ルートで標準化した Mike Jones の前例を引きつつ、FAPI 1.0 / FAPI 2.0 を同じルートに乗せるための有償契約者を 1〜2 名探したいと WG 内で公募した。3 月時点では具体的なリード人員はまだ決まっておらず、本投稿が FAPI の ISO 標準化プロセス開始の正式な号砲 となっている。後の 4/23 Mark Verstege による FAPI 2 Explanatory Report レビュー依頼（2024-04 月次レポート §2-3 参照）、5/1 Hodari McClain による FAPI 1.0 + JARM の ISO PAS Submission Draft レビュー依頼（2024-05 月次レポート §2-9 参照）は、いずれもこの 3 月 15 日の公募から派生する具体的な実務作業である。

技術的な議論面では、Ralph Bragg (Raidiam) が 3/22 に立てた Issue #685: Use of TLS 1.2 Ciphers と、Brian Campbell (Ping Identity) が 3/14 に立てた Issue #683: EC keys minimum length? の 2 件が cryptographic requirement の核心論点 として 3/27 の Atlantic コール後に Dave Tonge が WG 全体にフィードバックを呼びかけた（ML #003082）。両者の共通項は、FAPI 仕様が BCP 195 (RFC 9325) から借用する形で暗号要件を規定していることへの整合性確認であり、Bragg は「SHALL レベルで cipher list を狭く規定すると warning レベルで運用できず conformance 不適合者が大量発生する」、Campbell は「EC 鍵の最小長 160 bit は同仕様内の ES256/EdDSA 要件と整合せず、RSA 鍵長との対称性も欠く」という、いずれも実装の現場感覚に裏打ちされた指摘である。この 2 件は後の Issue #698 (5/21、Heenan による TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 脆弱性提起) → Issue #700 (6 月、TLS 1.2 用 cipher リスト削除と BCP 195 一本化) → Issue #703 (7 月、when using TLS 1.2, 限定句削除) と続く、FAPI 仕様の TLS 規範を自前管理から BCP 195 への完全委任へ動かす流れの起点 に位置づけられる。

CIBA / FAPI 2 統合論点としては、Dima Postnikov が 3/30 に Issue #687 と Issue #688 を相次いで起票 した点が重要である。#687 は「FAPI-CIBA がどの Security Profile（FAPI 1 か FAPI 2）から TLS / Algorithm / Encryption / Privacy の各節を継承するか」を問う仕様構造上の論点、#688 は「FAPI 2 Security Profile の §5.3.1 / §5.3.2 に CIBA を Auth Code Flow の代替として明示し、PAR と CIBA auth request endpoint で同一の認証・署名要件を主仕様側に集約する」という具体的提案である。Postnikov は FAPI WG 共同議長として CIBA 統合の整理を Final 化前に WG 内合意の俎上に乗せた格好で、後の FAPI-CIBA を FAPI 2 と整合させていく作業の出発点になった。

事業者間相互運用の論点としては、Jacob Ideskog (Curity AB) が 3/28 に Issue #686: CIBA response parameters in PSD2 TPP use-cases を起票 したのが目を引く。スウェーデン BankID が phishing 対策として CIBA decoupled flow の auth_req_id 取得時に「start-token」をアプリ起動時に渡す方式を導入する予定であり、現状の標準では token endpoint response や error response に追加パラメータを乗せる「やや標準を曲げた実装」が業界で散発的に発生していることを指摘した。Ideskog は「phishing は成長中の問題でこの種のパターンは他地域でも今後出てくる」とし、FAPI WG として CIBA 利用時に追加情報をクライアントへ伝える許容パターンを推奨するよう要請した。Issue #686 は本月以降も結論に至らず、4/10 Atlantic コールでも Jacob Ideskog 自身が ML #003090 で「Issue 686 について議論はあるが結論には至っていない」と書き残す ことになる（2024-04 月次レポート §3 参照）。

セキュリティ規範の細部詰めとしては、Tim Würtele (SECtim、Stuttgart 大学・FAPI 2.0 formal analysis 共著者) が 3/13 に Issue #682: Clarify allowed use of state and required CSRF protection in FAPI 2.0 SP を起票 した。OAuth 2.1 で PKCE が CSRF 対策手段として提示されることを踏まえ、「PKCE verifier を user agent にバインドしないと CSRF 対策として機能しない」「実装者が PKCE verifier を state パラメータに入れて満足してしまう可能性がある」という形式分析者ならではの懸念を明示し、FAPI 2.0 SP で session-binding を明示する規範整備を求めた。

openid-specs-fapi ML の 2024-March アーカイブ には全 19 件の投稿が収録されており、4 月の 23 件・5 月の 29 件と比較して少なめだが、Issue 起票件数（12 件、#677〜#688）は 2024 年前半で最大 であり、編集論点・規範論点を Issue トラッカーに体系的に積み上げた月であった点が特徴的である。

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

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

2024 年 3 月内に FAPI 2.0 Security Profile / Attacker Model / CIBA の新しい公開ドラフト版（Implementer's Draft 3 / Final ドラフト）は公開されていない。月の規範作業は WGLC 起動前に Final 化前へ詰めるべき編集論点・規範論点を Issue トラッカーへ集積するフェーズ であり、ドラフト本体の版番号変更は伴わなかった。月内に ML 上で展開された主要な技術論点は以下のとおり。

2-1. ISO PAS プロセスのリード人員公募（Gail Hodges、3/15） ​

ML #003077 (Gail Hodges, 2024-03-15 16:25 UTC) は 3 月の規範プロセス上で最重要の投稿 である。Hodges は OIDF Executive Director として、FAPI 1.0 / FAPI 2.0 を ISO PAS (Publicly Available Specification) ルートで ISO 標準化するための有償契約者を 1〜2 名 WG メンバーから公募した。投稿の要点は以下のとおり。

  • 背景: Open Banking / Open Data フレームワークが国際的に勢いを増しており、FAPI の ISO 標準化はタイムリーかつ重要
  • 前例: Mike Jones が OpenID Connect Core を同じ ISO PAS ルートで標準化済み（後の ISO/IEC 26131）。formal な標準化完了まで「数か月」のオーダーで進展
  • リソース: OIDC 提出時の baseline reports を FAPI 版に流用可能。ISO 任命の advisor が提出前材料をレビュー
  • 作業負荷: 集中作業期間（report 準備・stakeholder feedback 取りまとめ）と、ISO community review サイクル中の長い待機期間が交互に来る
  • タイムライン: 3 月中に人選決定、FAPI 1.0 の report 起草に即時着手、FAPI 2.0 の提出は仕様が Final になってから
  • 連絡先: Gail Hodges 本人または Mike Leszcz (OIDF Operations Director)

この公募投稿が起点となり、4/23 に Mark Verstege が FAPI 2 Explanatory Report ドラフトを WG レビューに回す（2024-04 月次レポート §2-3）、5/1 に Hodari McClain が FAPI 1.0 + JARM の ISO PAS Submission Draft を Google Docs で共有する（2024-05 月次レポート §2-9）といった具体的成果物が翌月以降に表面化していく。3 月時点では「FAPI を ISO 標準化する」という方針が WG ML 上で正式アナウンスされた一方、具体的な起草担当者はまだ決まっていない過渡期 にあった。

2-2. Cryptographic Requirements の整合性: Issue #683 と Issue #685 ​

3/27 Atlantic コール直後に Dave Tonge が ML #003082 で 「両者とも BCP 195 (RFC 9325) から借用する暗号要件に関連する」 とまとめて WG 全体に明示的フィードバックを要請した 2 件である。

Issue #683 (Brian Campbell, 3/14) は、FAPI 2.0 Security Profile §5.4 の以下の要件を問題視する。

Elliptic curve keys shall have a minimum length of 160 bits

Campbell の指摘は 3 軸からなる。

  • 同仕様内の不整合: 同じ FAPI 2.0 SP は JWT 署名アルゴリズムとして「ES256 または EdDSA (Ed25519 サブタイプ)」を要求しており、これは 256 bit 鍵を要求する。160 bit 最小長と矛盾
  • 適用範囲の不明瞭性: 160 bit 最小長は TLS context にも適用されるのか、JWT に適用されるのか、その他にも適用されるのか
  • RSA との対称性: RSA 鍵長要件（2048 bit、約 112 bit security strength）との対称性を保つなら EC 鍵は 224 bit 最小長とすべき

Campbell は「160 bit という規定は revision が必要かもしれない」と結び、WG にコメントを求めた。EC 鍵長の議論は表面的には小さく見えるが、Final 化前の正本テキストに残しておくと「最低限のセキュリティ強度に未達のアルゴリズムを許容する仕様」というレッテルが貼られかねない、Final 化の品質判断に直結する論点である。

Issue #685 (Ralph Bragg, 3/22) は、FAPI 2.0 SP の TLS 1.2 cipher 規定が「4 個に絞った具体的 cipher suite を SHALL レベルで要求」している現状に対し、FAPI 1.0 が認めていた「BCP 195 整合の追加 cipher を必要に応じて許容する（HSTS 等の前提条件付き）」という柔軟性を FAPI 2 でも維持すべきと提起する。Bragg の論拠は実装側の運用感覚に強く根ざしている。

"if necessary to allow sufficient interoperability with users' web browsers or are required by local regulations."（FAPI 1 の文言）

エコシステム全体で議論すべきだ。SHALL レベルの強制で cipher list を狭く制約すると、警告レベルでの conformance 運用ができず、「conformance 不適合」が大量発生しかねない。

Bragg は Raidiam の立場から複数の Open Banking エコシステム（特に UK・Brazil）の実装現場を見渡しており、「規範を厳しくすれば品質が上がる」という単純な発想ではなく「規範を厳しくしすぎて市場との乖離が広がれば、結局誰も完全準拠できなくなる」という運用視点での問題提起である。この Issue は後の Issue #698（5/21）・#700（6 月）・#703（7 月）と続く、FAPI が TLS 1.2 cipher リストを自前で詳しく規定するのを止めて BCP 195 へ完全委任していく流れ全体の正式な起点 に位置づけられる。

2-3. CIBA / FAPI 2 統合: Issue #687 / #688（Dima Postnikov、3/30） ​

WG 共同議長の Dima Postnikov が 3/30 朝に 10 分の間隔で投函した 2 件の Issue は、FAPI-CIBA を FAPI 2 と整合させていくための仕様構造論点を Final 化前に WG の俎上に乗せた ものである。

Issue #687 (3/30 08:12 UTC) は次の 4 節を FAPI-CIBA がどの Security Profile から継承するかを問う構造論点である。

  • §7.9 TLS considerations
  • §7.10 Algorithm considerations
  • §7.11 Encryption algorithm considerations（FAPI 2 では関連性が薄い可能性）
  • §8 Privacy Considerations（CIBA 仕様への参照付き）

FAPI-CIBA は FAPI 1 を前提として作られた仕様だが、FAPI 2 の Final 化が近づくにつれ、FAPI 2 環境下で CIBA を使う実装者にとって「どの規範を読めばよいか」が不透明になりつつあった。Postnikov の問題提起は、FAPI-CIBA 自身を改訂してプロファイル選択を明示するか、FAPI 2 SP 側で CIBA への参照を組み込むかという二択を WG に投げかけたものである。

Issue #688 (3/30 08:22 UTC) は #687 の続編として、より具体的な提案を含む。

  • CIBA を Auth Code Flow の代替として明示: FAPI 2 Security Profile §5.3.1 (Requirements for Authorization Servers) と §5.3.2 (Requirements for Clients) に、新たに §5.3.1.3 / §5.3.2.3 を追加して FAPI-CIBA を参照
  • 認証・署名要件の主仕様側集約: 「同一の認証要件と request signing 要件が PAR endpoint と CIBA auth request endpoint の双方に適用される」ことを明示し、CIBA spec 側で重複させずに主仕様（FAPI 2 SP）側で一箇所に集約

これは仕様構造として 「FAPI 2 SP を CIBA も含めた包括 profile にする」方向 であり、Postnikov の運用視点（UAE Open Banking や Australia CDR の実装現場知識）が強く反映された提案である。後年の FAPI-CIBA 改訂作業（FAPI 2 ベースへの再ポート）における重要な出発点である。

2-4. CIBA × PSD2 TPP × phishing 対策: Issue #686（Jacob Ideskog、3/28） ​

ML #003083 (Jacob Ideskog, 2024-03-28 14:36 UTC) は、Curity AB の Ideskog が スウェーデン BankID の phishing 対策強化を契機として、CIBA decoupled flow における「追加情報のクライアント伝達」標準パターンを FAPI WG に求めた 投稿である。

問題の構造は次のとおり。

  • 現状の CIBA decoupled flow では、TPP がユーザー識別子を AS に送り auth_req_id を受け取り、ユーザー側で別途認証アプリ（BankID）を起動して同意する
  • BankID 側は phishing 攻撃（攻撃者がユーザーに本物そっくりの状況下でアプリを開かせる）への対策として、AS から TPP へ「start-token」を返し、それを TPP がアプリ起動時にディープリンク等で渡す方式を導入予定
  • 標準には「token endpoint response や error response に追加パラメータを乗せる」許容パターンが明示的に規定されていないため、業界では「やや標準を曲げた」実装が散発

Ideskog の要請は「FAPI WG として CIBA 利用時に追加情報をクライアントへ伝える許容パターンを推奨してほしい」であり、その実装上の候補として次が示された。

  • 別の endpoint で token を取得
  • error_description フィールドに埋め込み
  • token endpoint / authorization endpoint response に追加パラメータを乗せる
  • authorization_pending response に追加パラメータを乗せる

RFC 6749 は token endpoint response への追加パラメータを permits しているため法的にも問題ないが、どのパターンが FAPI として推奨されるかの規範が未整備 という指摘である。本 Issue は 4/10 Atlantic コールでも「議論はあるが結論には至っていない」状態が続き（2024-04 月次レポート §3）、phishing 対策の業界横断的な広がりを背景に長期的議論となっていく。

2-5. Issue #682: state / CSRF 規範明確化（Tim Würtele、3/13） ​

ML #003075 (Tim Würtele, 2024-03-13 13:22 UTC) は、Stuttgart 大学を拠点として FAPI 2.0 formal analysis 研究の共著者でもある Würtele が PKCE の CSRF 対策効果が user agent binding に依存することを Final 化前に規範文言上で明示すべき と提起した投稿である。

Würtele の論点は形式分析者の視点から鋭い。

  • RFC 6749 §10.12 はクライアントに CSRF 対策実装を求める
  • OAuth 2.1 系の最新仕様では PKCE を CSRF 対策の実用的メカニズムとして提示する
  • ただし PKCE の verifier を user agent にバインドしないと CSRF 対策として機能しない
  • 実装者が「PKCE verifier を state parameter に入れる」ことで満足してしまうと、session binding を欠いた状態となり実質的に CSRF 対策が空転する
  • FAPI 2.0 SP は PKCE を CSRF 対策手段として言及しているが、user agent binding の明示要件がなく、解釈の余地（実装者の取り違え余地）がある

Würtele の要請は「FAPI 2.0 SP で session binding 要件を明示する形に規範を整える」というもので、後年 Final 化された FAPI 2.0 Security Profile §5.3.2 Authorization Code Flow の規範を直接形作る貢献の 1 つとなった。

2-6. Issue #684: typ in request objects（Joseph Heenan、3/19） ​

ML #003078 (Joseph Heenan, 2024-03-19 22:19 UTC) は、Heenan が JAR / PAR / FAPI1 / FAPI2 にまたがる typ ヘッダの取り扱いの不統一を、Conformance Suite 側の運用知見から指摘 したものである。Heenan は OIDF の Certification Suite 責任者として実装テスト現場の不整合を最も観察しやすい立場にある。

現状の Conformance Suite 動作:

  • OP テスト: request object 内の typ 値を送信していない
  • RP テスト: 受信した request object 内の typ 値を検証していない

Heenan の提案:

  • 全 OP テスト: typ: JWT、typ: oauth-authz-req+jwt、typ ヘッダなし の 3 通りそれぞれを送って試す
  • 全 RP テスト: typ が absent、JWT、または oauth-authz-req+jwt のいずれかであることを検証

Heenan は「この相互運用性問題は Brazil での議論中に浮上した」と注記しており、Open Finance Brazil エコシステムでの実装相互運用テストが具体的トリガーになったことが示唆される。実装の現場で「OP が typ を送らない」「RP が検証しない」という状態が放置されると、将来の SDK バージョンアップで挙動が変わったときに相互運用が破綻するリスクがある。本 Issue は WG として「3 通り全てを受理する」と明示する規範整備を求めるもので、Final 化前の仕様整理として相応に重要な論点である。

2-7. EU Payment Wallet スレッド（Anders Rundgren ↔ Joseph Heenan、3/4） ​

ML #003067 (Anders Rundgren, 3/4 09:07 UTC) → ML #003068 (Joseph Heenan, 3/4 09:22 UTC) → ML #003069 (Rundgren, 3/4 17:05 UTC) の 3 投稿スレッドは、Rundgren が継続的に FAPI WG ML に投げ込む「OAuth は決済 authorization に適しているか」論争の 3 月時点でのスナップショットである。

論点:

  • Rundgren: digitallabor.berlin の draft payment presentation profile を共有し、「decisive feature」として「all forms of intermediaries, including PISPs を排除する」と主張。LinkedIn の Payment Innovation グループ投稿が 30,000 views / 200 reactions / 40 shares を集めた、と数字で裏付け
  • Heenan: 「OAuth2 に依存しない、という主張は不正確。当該ダイアグラムは OpenID4VP（その下に OAuth2）の上に構築されている」と訂正
  • Rundgren: 「我々は両方正しい。EU wallet も OAuth2 を使うが、FAPI が使う variant とは異なる variant だ。EMV ライクなフローのほうがガソリンスタンド自動決済やサブスクリプション等の多様な決済シナリオに柔軟」と部分譲歩しつつ自説を維持

Rundgren の主張は WG 内で広い合意を得るものではなかったが、本月の議論は 4/26 の ML #003099 OpenID - Verifiable Presentations や 5/15〜5/31 の EU Payment Wallet スレッド群 へと連続的につながっていく。

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

FAPI WG は 2024 年 3 月時点で Atlantic コール（水曜 14:00 UTC、隔週運用）と Pacific コール（隔週 Friday / Wednesday、Asia-Pacific 帯）の 2 系統を運用していた。Bitbucket wiki 上の議事録ページ（FAPI_Meeting_Notes_2024-03-XX_Atlantic 系統）は SPA レンダリングのため本記事執筆経路で本文を直接抽出できないが、ML 投稿のアジェンダ・リマインダー・事後報告から各コールの開催状況と議論内容を再構成する。

3 月中に ML 上で開催確認できるコールは Atlantic コール 3/27、Pacific コール 3/21 の 2 回である。3/13 と 3/20 の Atlantic コール枠の ML リマインダーは確認できないが、Issue #678〜#682 が 3/13 朝〜午後に集中起票された経緯から、3/13 もしくはその前後でコールがあり、Final 化前のレビュー方針が共有されたと推察される。

2024-03-21 Pacific コール（Anoop Saxena 運営） ​

ML #003079 (Anoop Saxena, 2024-03-21 17:58 UTC) は、3/21 17:00 PT 開催の FAPI WG Pacific Call の Zoom 案内（隔週 Sydney 10:00〜11:00 で繰り返し設定）。Nat Sakimura、Brian Campbell ら複数の WG 主要メンバーが招待状の宛先に含まれている。アジェンダ参照先は Bitbucket wiki の Meeting ページ。Pacific コールは Asia-Pacific 帯の参加者（Australia CDR エコシステム関係者、Japan 在住の Nat Sakimura 等）が中心で、Anoop Saxena (Intuit) が運営を担う体制。

このコール内容を直接示す事後 ML 投稿はないが、3/22 朝（UTC 00:58）に Ralph Bragg が Issue #685 を起票している時系列を踏まえると、Pacific コール内で TLS 1.2 cipher の柔軟性議論が触れられ、コール後に Bragg が Issue 化した という連動性が推察される。

2024-03-27 Atlantic コール（Final 化前の Issue 集中レビュー回） ​

ML #003081 (Nat Sakimura, 2024-03-27 13:12 UTC) で公示されたアジェンダはデフォルト構成の 7 項目（Roll Call / Adoption of Agenda / Events (Mike L.) / External Orgs & Liaisons (Mike L.) / PRs (Dave) / Issues (Dave) / AOB (Nat)）であり、3 月時点で月内に立てられた Issue 群（#677〜#685 の 9 件）が Dave Tonge の管掌で順次レビューされる議事だったと再構成できる。

コール終了直後の ML #003082 (Dave Tonge, 2024-03-27 15:11 UTC) は 3 月の規範議論の核心 にあたる総括投稿である。Tonge は冒頭で「Atlantic コールに参加した皆さん、多数の Issue で productive な議論ができた」と謝意を述べたうえで、

I'd like to ask for input on these two issues: https://bitbucket.org/openid/fapi/issues/683/minimum-length-for-ec-keyshttps://bitbucket.org/openid/fapi/issues/685/use-of-tls-12-ciphers

Both of them are related to cryptographic requirements that we at the moment take from BCP195

として Issue #683 (EC keys minimum length) と Issue #685 (TLS 1.2 Ciphers) の 2 件を「BCP 195 から借用する暗号要件」として WG 全体のフィードバック対象に明示 した。これは「コール内で結論が出なかった or レビュアーが足りなかった」両 Issue を ML 経由でより広く意見集約するための運用判断であり、共同議長 Tonge が Final 化前の規範の純度を確保するために集合知に依拠する スタイルを明示した投稿でもある。

Pacific 系・追加 Pacific コール ​

3/30 朝（UTC 08:12〜08:22）に Dima Postnikov が Issue #687 / #688 を立て続けに起票している。Dima は Australia 拠点で Pacific 帯のメンバーであり、3/29 Friday 帯前後で Pacific コール（あるいは個別議論）があった可能性は否定できないが、これを直接示す ML 投稿は確認できない。

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

2024 年 3 月の openid-specs-fapi ML は 19 件の投稿を含む。技術論点・規範プロセスに直結する主要スレッドを以下に整理する。

Request for FAPI WG Member to Lead ISO PAS Process — 3/15 Gail Hodges ​

ML #003077 (Gail Hodges, 3/15) は 3 月で最も戦略的に重要な投稿 である（§2-1 で詳述）。FAPI 1.0 / FAPI 2.0 を ISO PAS ルートで標準化するための有償契約者公募。3 月時点で具体的な起草担当者は確定していないが、4 月以降の Mark Verstege（FAPI 2 Explanatory Report）・Hodari McClain（FAPI 1.0 + JARM Submission Draft）の実務作業はすべてこの 3 月 15 日アナウンスから派生する。

FAPI 2.0 PRs and Issues — 3/27 Dave Tonge ​

ML #003082 (Dave Tonge, 3/27) は 3 月で最も技術的に重要な投稿 である（§2-2 / §3 で詳述）。3/27 Atlantic コール直後の総括で、Issue #683 (EC keys) / #685 (TLS 1.2 Ciphers) を WG 全体のフィードバック対象として明示。両者とも BCP 195 から借用する暗号要件に直結する論点で、Final 化前に規範の純度を確保するための運用判断が示された。

Issue #685: Use of TLS 1.2 Ciphers — 3/22 Ralph Bragg ​

ML #003080 (Ralph Bragg, 3/22) は FAPI 仕様の TLS 規範を自前管理から BCP 195 への完全委任へ動かす長期的流れの起点投稿 である（§2-2 で詳述）。Bragg は Raidiam の立場から複数 Open Banking エコシステムの実装現場感覚を持ち込み、「SHALL レベルで cipher list を狭く制約すると、警告レベルでの conformance 運用ができず conformance 不適合者が大量発生する」という運用視点での問題提起を行った。本 Issue は 5/21 Heenan の Issue #698（TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 脆弱性）、6 月の Issue #700（TLS 1.2 cipher リスト削除）、7 月の Issue #703（when using TLS 1.2, 限定句削除）へと連続して継承される。

Issue #687 / #688: FAPI-CIBA × FAPI 2 統合 — 3/30 Dima Postnikov ​

ML #003084 / ML #003085 の Postnikov による 2 連投は、WG 共同議長として FAPI-CIBA と FAPI 2 の仕様構造整合化を Final 化前の俎上に乗せた ものである（§2-3 で詳述）。Issue #687 が継承元 Security Profile 選択の構造論点、Issue #688 が具体的な §5.3.1.3 / §5.3.2.3 追加提案を含む。

Issue #686: CIBA response parameters in PSD2 TPP — 3/28 Jacob Ideskog ​

ML #003083 (Jacob Ideskog, 3/28) は Swedish BankID の phishing 対策強化を契機とした、CIBA decoupled flow における追加パラメータ伝達パターンの標準推奨化要請 である（§2-4 で詳述）。Curity AB の実装現場の観察を WG ML に持ち込んだもので、4/10 Atlantic コールでも「議論はあるが結論には至っていない」状態が継続することになる長期論点。

EU Payment Wallet スレッド — 3/4 Anders Rundgren ↔ Joseph Heenan ​

ML #003067 → ML #003068 → ML #003069 の 3 投稿スレッドは、Rundgren が継続的に FAPI WG ML に投げ込む「OAuth は決済 authorization に適しているか」論争の 3 月時点でのスナップショット（§2-7 で詳述）。Heenan の事実関係訂正（FedCM/OpenID4VP/OAuth2 のレイヤー構造）に対し、Rundgren が「両方正しいが variant が違う」と部分譲歩しつつ EMV ライクな決済フローの優位性を再主張した。

Issue #683: EC keys minimum length? — 3/14 Brian Campbell ​

ML #003076 (Brian Campbell, 3/14) は FAPI 2.0 SP §5.4 の EC 鍵最小長 160 bit 要件の妥当性を、同仕様内の ES256/EdDSA 要件・RSA 鍵長要件との対称性から問い直した 投稿である（§2-2 で詳述）。Campbell の指摘は単純な数値修正ではなく、Final 仕様としての規範整合性の品質判断に直結する論点。

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

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

2024 年 3 月に ML 上で起票・周知が確認できる Issue は 12 件（#677〜#688） であり、FAPI WG にとって極めて Issue 起票密度の高い月であった。一覧と起票者・主題は以下のとおり。

12 件の内訳は Nat Sakimura による編集論点 5 件（#677〜#681）、形式分析者からの規範論点 1 件（#682）、暗号要件論点 2 件（#683 / #685）、相互運用性論点 1 件（#684）、CIBA 関連 3 件（#686 / #687 / #688） と多面的で、4 月 24 日に起動される WGLC を見据えて WG 各層が同時並行で論点を積み上げた構図である。

GitHub openid/fapi リポジトリは Bitbucket の公開ミラー的位置付けで、編集ワークフローの主軸は引き続き Bitbucket 上の PR / Issue で運用されていた。

6. 関連イベント ​

3/4〜3/5: Gartner Identity & Access Management Summit London ​

Gartner IAM Summit London が 3/4〜3/5 にロンドンで開催された。OpenID Foundation は Shared Signals Working Group の interop demo を会場で実施し、Okta・SailPoint・Cisco に加え startup として VeriClouds・SGNL・Helisoft が参加して Shared Signals Framework (SSF) / CAEP / RISC の相互運用性を披露した。本イベントは Shared Signals WG の活動であって FAPI WG の直接の出展ではないが、OIDF のグローバルでの認知度を高め、後の 4/26 公開ブログ Shared Signals: Enhanced Security for All の事後アナウンスとして整理される ESCG / Shared Signals 側の活動である。

3/16〜3/22: IETF 119 Brisbane ​

IETF 119 Brisbane が 3/16〜3/22 に Brisbane Convention Centre で開催された（onsite 674 名・online 597 名）。OAuth WG は 3/20 9:30〜11:30 と 3/21 9:30〜11:30 の 2 セッションを実施。FAPI 専用セッションはないが、FAPI が依拠する OAuth 2.0 系の Best Current Practice、JAR・PAR、DPoP、Selective Disclosure for JWTs (SD-JWT)、Cross-Device Flow 等の議論が並行して進んだ。IETF 119 と FAPI WG の直接接点は ML 上に投函された投稿としては観察できないが、参加者層の重なりは大きく、IETF 側の議論動向は次月以降の WG コール議題に間接的に影響していく。

3/20: CSRB Microsoft Exchange Online Intrusion 報告書公開 ​

米国 Cyber Safety Review Board (CSRB) が 3/20 に Microsoft Exchange Online Intrusion (Storm-0558 事案) のレビュー報告書を公開。事案の発端が「Microsoft が enterprise / consumer 双方の identity system の active signing keys を列挙する 共通 OpenID Connect (OIDC) endpoint サービス を提供しようとした際に、SDK 側で enterprise / consumer key を区別する更新が漏れたこと」にあった点が報告書で言及されている。FAPI 仕様自身は OIDC を normative reference するが、本件は Microsoft 側の SDK 実装ギャップが本質であり、FAPI 仕様の規範には直接的影響を与えないと整理できる。ただし 「ハイバリュー API における identity provider の key 管理が cyber safety 国家レビューの対象になる」 という規制環境の重みを示す象徴的イベントとして、FAPI / OIDC 双方の関係者にとって看過できない月内事象である。

7. 今後の予定 ​

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

  • FAPI 2.0 Security Profile / Attacker Model の Final 化前 PR マージ: Issue #677〜#688 の編集論点・規範論点を順次 PR 化してマージし、WGLC を実施できる状態に持っていく
  • Issue #683 (EC keys) / #685 (TLS 1.2 Ciphers) への WG 全体フィードバック取りまとめ: Tonge が 3/27 ML #003082 で WG 全体に明示要請した 2 件への意見集約
  • FAPI ISO PAS リード人員の確定: 3/15 Gail Hodges 公募投稿への応募者から選抜（3 月中決定目標）。FAPI 1.0 report 起草に即時着手
  • FAPI 2 Explanatory Report for ISO PAS の起草準備: ISO PAS リード確定後に、FAPI 2.0 Security Profile / Attacker Model / CIBA の 3 本を対象とする Explanatory Report 起草開始（実際の WG レビューは 4/23 Mark Verstege が回す）
  • CIBA × FAPI 2 統合論点（Issue #687 / #688）の継続検討: Postnikov 提案を起点に、FAPI-CIBA 改訂を行うか FAPI 2 SP 側に CIBA 参照を追加するかの WG 内合意形成
  • CIBA decoupled flow × phishing 対策（Issue #686）の継続議論: BankID の start-token 方式を契機とした、追加パラメータ伝達パターンの標準推奨化検討
  • 4/15 OpenID Foundation Hybrid Workshop at Google (Sunnyvale) への準備: Nat Sakimura による FAPI WG Update 担当（13:20〜13:35 PT 枠）
  • 4/16〜4/18 IIW 38 (Mountain View) 期間中の Bay Area F2F 議論: WG メンバーの相当数が現地参加見込み
  • WGLC 起動準備: Dave Tonge による 4/24 Atlantic コール直後の WGLC 起動アナウンス（実際に ML #003097 として実行）

8. 参考情報源 ​

メーリングリスト ​

議事録 (Bitbucket wiki) ​

Issue トラッカー (Bitbucket) ​

OpenID Foundation 公式リソース ​

仕様 ​

関連イベント ​

関連月次レポート ​

  • FAPI WG 2024 年 4 月レポート — 4/24 WGLC 起動、Brian Campbell の Attacker Model 同時昇格論点、Mark Verstege の FAPI 2 Explanatory Report for ISO PAS レビュー依頼、Joseph Heenan の Issue #689 FAPI + FedCM
  • FAPI WG 2024 年 5 月レポート — WGLC 集中審議期間、Rifaat 6 項目コメント、Issue #690〜#698 集中起票、FAPI 1.0 + JARM ISO PAS Submission Draft レビュー、Mastercard Board 加盟、CFPB Letter、Identiverse 2024
  • Ecosystem Support CG 2024 年 3 月レポート — 3/4 Gail Hodges による FAPI ISO PAS リード公募の ESCG 側からの記録、FAPI WG #677〜#688 集中起票の俯瞰