idbok

Appearance

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

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

1. 概要 ​

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

2024 年 8 月は、12 月 9 日に開始される FAPI 2.0 Security Profile / Attacker Model の Final パブリックレビュー に向けて、Security Profile 本体の最終 PR 群を整理する月となった。8 月 7 日に予定されていた Atlantic コールが共同議長双方の都合で土壇場キャンセルされた一方、その後の 3 週連続の Atlantic コール（8/14・8/21・8/28）は予定通り開催され、Dave Tonge が Final 化前最終 PR 群（Bitbucket PR #512・#513・#514・#516）のレビュー進行を主導した。Issue 起票は #706 (FAPI 2.0 Section 5.4 の曖昧さ)、#707 (TLS cipher suites 制限)、#708 (アクセストークンのクエリ受理) の 3 件で、いずれも認定実装または eID 適合の現場からの実装者観点の指摘であった。翌 9 月に Issue #709 以降の連続起票（11 件）で論点出しが本格化することを踏まえると、8 月は「最終 PR の決め切り」と「Final 前の実装者フィードバックの初動」が同時並行で動き出した月として位置付けられる。

openid-specs-fapi ML の 2024-August アーカイブ には 11 件の投稿が収録されている。投稿件数は隣接月（9 月の 25 件超）より少ないが、これは夏季休暇の影響と、議論が PR 上でのレビューに集中していたためと考えられる。

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

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

2024 年 8 月内には FAPI 2.0 Security Profile / Attacker Model の新しい公開ドラフト版（Draft -04）は公開されなかった。Draft -04 が openid.net 上で公開されたのは 2024 年 12 月 8 日（パブリックレビュー開始の前日）であり、8 月時点で WG が編集していたのは Draft -04 公開に向けた最終整形フェーズの内部作業ツリーである。

すなわち 8 月の編集アクションは、外形的な公開仕様アクション（Final 化通告、WGLC、Call for Adoption 等）を伴わず、Bitbucket 上での PR レビュー集中期間として位置付けられる。

Dave Tonge が 8 月にレビュー要請した PR 群 ​

ML #003171 (8/27) と ML #003173 (8/29) の 2 投稿で、Dave Tonge は次の PR 群について WG 内レビューを要請した。FAPI 2.0 Security Profile が Final 投票に進むための最後の編集差分として位置付けられている。

  • PR #512 — FAPI 2.0 Security Analysis 文書へのリンク追加（編集系）。Final 化に向けた相互参照整備
  • PR #513 — BCP 195 の新しいイテレーション（RFC 9325）への移行に関する Conformance note の追加。古い BCP 195 (RFC 7525) を引用していた箇所の現代化
  • PR #514 — Key compromise シナリオに関する Security Considerations の補強。CISA Cyber Safety Review Board が 2023 年夏の Storm-0558 による Microsoft Exchange Online 侵入事案をレビューした報告（2024 年 3 月 20 日公開）を踏まえた、key compromise 周りのガイダンス整理。"single use keys" という用語を "single purpose keys" に変更する。8/29 の再周知では「WG 合意は得られており、追加のマージ承認待ち」と報告
  • PR #516 — PR #514 と同じく key compromise 関連の継続修正で、ML #003173 では "Key Compromise (Continued)" と性格づけられている。8/29 周知時点で「より難しい変更」と Dave Tonge 自身が言及し、過去フィードバックを踏まえて RFC 9068 (JWT Profile for OAuth 2.0 Access Tokens) を参照する形に再起草。翌週の承認を目標としていた

PR #515 は ML 周知の対象に含まれなかった（番号欠番または別目的の PR と推定される）。ML 上でレビュー要請された 4 件はいずれも Final 化前の編集系・解説系・Security Considerations 補強の調整 であり、新しい規範要件の追加を伴わない。Dave Tonge の言葉を借りれば 「we are very close to resolving the final issues for the FAPI 2.0 Security Analysis」（ML #003171）。すなわち 8 月末時点で WG は「Final へ進める踏ん切り」を付けに行っており、9 月の Issue 連続起票（#709〜#719）はこの「Final 化決定後の最終チェックフェーズ」として連続するものである。

Conformance Suite との接続 ​

ML #003170 (Joseph Heenan, 8/25) の Issue #708 は、認定スイートのテスト判定基準として「リソースサーバがクエリ経由のアクセストークンを受理してはならない」という FAPI 1 の条文が FAPI 2 で消失している点を指摘した。Heenan は次の選択肢を提示している。

  • (a) 既存の認定テストから当該チェックを削除する（FAPI 2 では仕様上の根拠がないため）
  • (b) 残置し warning として扱う
  • (c) 残置し failure として扱う（OAuth Security BCP §4.3.2 および OAuth 2.1 Draft §5.1 の禁止規定を根拠とする）

仕様の編集差分そのものとは別に、認定テストとの整合性確保が同時並行で議論されていることを示す典型例である。

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

FAPI WG は Atlantic コール（水曜 14:00 UTC、隔週もしくは毎週）と Pacific コール（金曜朝、Asia-Pacific 帯）を運用している。8 月の対象コールについて、Bitbucket wiki 上の議事録ページは SPA レンダリングのため公開取得経路から本文を抽出できないが、ML 上のアジェンダ・リマインダー・後続投稿から議論内容を再構成する。

2024-08-07 Atlantic コール（土壇場キャンセル） ​

ML #003163（Nat Sakimura、UTC 14:42、件名 "Really sorry for cancelling the Atlantic call"）で、Nat Sakimura が共同議長双方の都合不可と本人の機内 Wi-Fi 接続不能を理由としたキャンセル謝罪を投函した。短い本文の結びには「Next week, we will do as usual.」とあり、翌週からの通常運行への復帰が示唆された。同時刻に Google Calendar 経由の正式キャンセル通知 ML #003164 も発出されている。

このキャンセルは事務的なものであり技術論点を伴わないが、「議長 2 人体制でも夏季の出張・移動が重なる時期は単発キャンセルが発生する」という WG 運営上の実態を記録する観点で有用 である。

2024-08-14 Atlantic コール ​

ML #003165（Nat Sakimura、UTC 12:00、件名 "Meeting reminder and draft agenda"）でコール開始 2 時間前のリマインダーが投函された。アジェンダは標準構成。

  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 を指す。Events / External Orgs & Liaisons という 2 つの節を Mike Leszcz が継続的に担うフォーマットは、9 月以降の Atlantic コールでも踏襲される。

8/14 コール本体の議論内容は ML から直接は読み取れないが、コール後の動き（8/16 に Issue #706 と Curity からの応答が同日中に成立、8/19 に Issue #707）から、コール内で「Final に向けた最終 Issue を会員から拾い上げる」プロセスが共有されたと推測される。

2024-08-21 Atlantic コール ​

ML #003169（Nat Sakimura、UTC 11:15、件名 "Draft Agenda for Today's Atlantic Call"）で同日付のアジェンダが投函された。構成は 8/14 と同一の標準アジェンダ（Roll Call から AOB までの 7 項目）。

このコール後、8/25 に Joseph Heenan からの Issue #708 が ML 周知されており、認定テスト判定基準と仕様文言の整合性問題がコール内の Issues 節で扱われたと推測される。

2024-08-28 Atlantic コール ​

ML #003172（Nat Sakimura、UTC 10:45、件名 "A Friendly Reminder for the Atlantic Meeting Today"）でリマインダーが投函された。アジェンダは前 2 回と同一構成。

8/28 コールは 8/27 の Dave Tonge による PR #512/#513/#514 レビュー要請の翌日に開催されており、PR レビュー進行とマージ判断の場として機能したと推測される。翌日（8/29）に Dave Tonge が PR #514（再）と PR #516 の追加レビュー要請を投函していることから、コール内で PR #512 と PR #513 については一定の合意・マージ目処が立った一方、PR #514 にはまだ追加承認待ちの状態、PR #516 は「より難しい」内容として翌週の承認を目指す段取りに整理された、という流れが読み取れる。

Pacific コールの不在 ​

2024 年 8 月の ML 投稿には Pacific コールのアジェンダ・リマインダー投稿が一切確認できない。これは Pacific コールが隔週運用であり 8 月中に開催月の隙間に当たった可能性、または夏季にスキップされた可能性のいずれかであるが、ML 上に積極的な「キャンセル告知」が存在しない点から、隔週カレンダーの「開催なし週」に該当したと考えるのが自然である。9/19/20 に Pacific コールのアジェンダが投函されており、9 月から通常運行に復している。

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

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

Issue #706: Unclear Section 5.4 of FAPI2 Security Profile — 2024-08-16 Dag Sneeggen → Judith Kahrer ​

ML #003166（Dag Sneeggen、UTC 11:06）で発端の問題提起が投函され、同日 UTC 11:43 に ML #003167（Judith Kahrer, Curity）が応答した。37 分で解決した「素早い相互確認」型のスレッドである。

Sneeggen の論点は、FAPI 2.0 Security Profile Section 5.4「Cryptography and Secrets」の構造的読みづらさである。当該節は 4 つのサブセクションから成り、第 1 節が「Authorization Server は PS256、ES256、または EdDSA (Ed25519) を用いる」と規定する一方、後続のサブセクションが RSA 鍵長要件（PS256 用）と EC 鍵長要件（ES256 用）を別個に規定している。Sneeggen は「PS256 は RSA 系アルゴリズムなのに、後段に RSA 鍵要件が出てくるのは矛盾に見える」と指摘し、AS は EC 鍵のみを使うべきなのか RSA も許容されるのか明確化を求めた。

Judith Kahrer の応答は次の解釈で整理した。

  • PS256 = RSASSA-PSS using SHA-256 → 最低 2048 ビット RSA 鍵
  • ES256 = ECDSA using P-256 and SHA-256 → 最低 160 ビット EC 鍵（実質 256 ビット）
  • EdDSA (Ed25519) → 256 ビット Ed25519 鍵

「Ed25519 は EdDSA のサブタイプであり、PS256 や ES256 に適用できる概念ではない。したがって既存の構造で RSA と EC の双方を適切に収容できており、追加節は不要」と結論付けた。

このやり取りは仕様変更を伴わず、規範解釈の確認で完結した。RFC 7518 (JWA) のアルゴリズム命名規則を熟知していない実装者にとっては読み下しにくいセクション構造であった という、可読性側の課題が表面化した事例として記録される。

Issue #707: Very restrictive list of TLS cipher suites — 2024-08-19 Dag Sneeggen ​

ML #003168（Dag Sneeggen、UTC 07:37）で提起された。FAPI 2.0 Security Profile が TLS 1.2 の cipher suite リストとして許容しているのは 4 件（実質 2 種類）に過ぎず、Sneeggen の組織は TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 を追加で必要としている、というものである。

Sneeggen は支援根拠として、欧州の主要 eID スキーム（デンマーク MitID、フィンランド FTN、オランダ DigiD、オランダ iDIN）が当該 cipher suite を業界ベストプラクティスとして許容している点を挙げた。FAPI 2.0 がこれらの eID と接続される実装では、cipher suite 不一致で技術的に接続困難になるという実装現場からの強い指摘である。

ML 上での直接の応答は 8 月中には現れず、9 月以降の PR / Issue 議論に持ち越された。FAPI 2.0 Security Profile は最終的に BCP 195 (RFC 9325) の参照を強化する方向（PR #513）で BCP 側の cipher suite リストに委ねる構造を採ることになるが、それでも TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 の明示的な許容に至るかどうかは Final 化前の論点として残り続けた。

Issue #708: Passing access tokens in url query not disallowed in FAPI2SP? — 2024-08-25 Joseph Heenan ​

ML #003170（Joseph Heenan、Authlete、認定スイート責任者）で提起された。FAPI 1 Baseline が「サーバは RFC 6750 §2.3 で定義されたクエリパラメータ経由のアクセストークンを受理してはならない (shall not)」と明示的に規定していたのに対し、FAPI 2.0 Security Profile では同等条文が存在しない、という観察である。

Heenan は OAuth Security BCP §4.3.2 および OAuth 2.1 Draft §5.1 が同様の禁止を規定していることを根拠に、認定テスト側で当該チェックを継続するべきかを問うた。残置するなら failure 扱いか warning 扱いか、という具体的な判定基準を含む問題提起である。

この論点は、上位文書（OAuth Security BCP、OAuth 2.1）が禁止規定を持つ場合、FAPI プロファイルがその禁止を明示的に再掲する必要があるかという、仕様の階層構造に関する一般的な論点 に通じる。FAPI 2.0 は「OAuth Security BCP に従う」と冒頭で宣言する構造を採るが、認定テストは個別チェック単位で実装されるため、上位文書への参照だけでは判定基準として弱い、という運用観点の不整合が表面化した。

Final issues and PRs for FAPI2 Security Profile — 2024-08-27 / 2024-08-29 Dave Tonge ​

ML #003171 (8/27) と ML #003173 (8/29) の 2 投稿は、Dave Tonge による Final 化前の最終 PR レビュー要請である。スレッド題名のとおり、FAPI 2.0 Security Profile を Final へ進めるための「最後の Issue と PR」を扱っている。

8/27 投稿では PR #512（文書相互参照の整備）、PR #513（BCP 195 新版への移行ノート）、PR #514（key compromise / single use → single purpose keys）の 3 件を列挙した。CISA Cyber Safety Review Board による Microsoft Exchange Online 侵入事案レビュー（2024 年 3 月公開、対象は 2023 年夏の Storm-0558 事案）の勧告を反映する PR #514 は、実運用インシデントに対する規範的応答 という意味で性格が異なる。

8/29 投稿では、PR #514 については「WG 内合意は形成済みだが追加承認待ち」、PR #516（用語定義の再起草、RFC 9068 を参照する形）については「より難しい変更」「翌週の承認を目指す」と性格づけられた。PR #516 が「より難しい」と評価されたのは、用語の見直しが Attacker Model の論理構造に波及するためで、Daniel Fett の形式的検証作業との整合性確認が必要であったためと推測される。

このスレッドは、「Final 化は単一の通告イベントではなく、PR レビューを通じた WG 内合意形成の積み重ね」 という、IETF / OIDF 双方のオープン標準化プロセスの実態を象徴する。

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

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

2024 年 8 月に ML 上で起票が周知された Issue は次の 3 件。

3 件はいずれも 「Final 化前の実装者フィードバック」 と総括できる。Sneeggen の 2 件は eID 連携を実装する現場からの指摘、Heenan の 1 件は認定スイート運用責任者の立場からの指摘で、いずれも「仕様起草段階では見落としやすい、実装側からしか見えない論点」である。9 月以降に起票される Issue #709〜#719 でも同様の傾向（Authlete の Takahiko Kawasaki から #714/#718/#719、Filip Skokan から #715 等）が継続することを考えると、8 月は Final 化に向けた実装者フィードバック収集モードへの移行月 として位置付けられる。

PR 番号 #512・#513・#514・#516 についても 8 月内に ML 上で周知され WG レビューに付されたが、これらは GitHub openid/fapi リポジトリではなく Bitbucket 側の Pull Request である（ML #003173 本文には https://bitbucket.org/openid/fapi/pull-requests/514/diff といった Bitbucket PR の URL が明示されている）。FAPI WG の主要編集ワークフローは 2024 年当時 Bitbucket 上で運用されていた。Bitbucket Cloud は SPA レンダリングのため PR メタデータの直接取得は本記事執筆経路では限定的であり、§2 / §4 における ML 投稿からの要約を主たる出典とする。

6. 関連イベント ​

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

8 月時点では IETF 120（2024 年 7 月 20-26 日、バンクーバー）の直後に当たり、IETF OAuth WG での FAPI 関連トピック（HTTP Message Signatures、OAuth 2.1、OAuth Security BCP）の進捗が FAPI WG 内議論の前提として共有されていた。8 月の ML 投稿には IETF 120 を明示的に振り返るスレッドは確認できないが、PR #513 の「BCP 195 (RFC 9325) への移行ノート」追加は、IETF 側で RFC 7525 から RFC 9325 への置き換え（2022 年 11 月公開）が一定の浸透を見たタイミングでの取り込みと読める。

夏季の WG 活動希薄期 ​

8 月は北半球の夏季休暇期間に当たり、ML 投稿件数（11 件）は隣接月（9 月の 25 件超）より顕著に少ない。Atlantic コール 1 回キャンセル、Pacific コールの ML 周知投稿ゼロという運営状況も合わせ、FAPI WG にとって 8 月は構造的に活動希薄期 である。それでもなお Final 化前の最終 PR レビューが進行した点は、Dave Tonge と Daniel Fett を中心とするエディタチームの継続的な編集作業を反映している。

外部発信 ​

openid.net ブログには 2024 年 8 月の FAPI 関連単独記事は確認できなかった。9 月以降に Identity Week、SIDI Hub、ETSI/CEN EU Digital Identity Framework Standards Workshop 等のイベントが続くため、8 月はそれらに先立つ準備期間として位置付けられる。

7. 今後の予定 ​

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

  • PR #514 (key compromise)・#516 (用語定義) のマージ完了: 9 月第 1 週を目処に
  • PR #512・#513 のマージ: 既に WG 合意が形成されており、形式的承認のみ残る
  • Issue #706〜#708 への対応方針確定: 9 月の Atlantic / Pacific 両コールで議論継続
  • Final 化に向けたさらなる実装者フィードバック収集: 9 月以降に Issue #709〜#719 として連続起票される（当時の予測としては「もう少し Issue が出てくるはず」という見通し）
  • FAPI 2.0 Security Profile / Attacker Model の Final パブリックレビュー開始: 12 月予定（実際の開始は 2024-12-09、60 日間）
  • Atlantic コール bi-weekly schedule 継続: 9 月以降は 9/11、9/18、9/25 等で再開
  • Pacific コール再開: 9 月内に通常運行へ復帰

8. 参考情報源 ​

メーリングリスト ​

議事録 (Bitbucket wiki) ​

Issue トラッカー (Bitbucket) ​

仕様 ​

関連リソース（OpenID Foundation） ​