idbok

Appearance

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

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

1. 概要 ​

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

2024 年 9 月は、12 月 9 日に予定されていた FAPI 2.0 Security Profile / Attacker Model Final パブリックレビュー開始 に向け、Final 化前の編集論点を一気に洗い出す月となった。Bitbucket Issue は月内を通じて連続起票され、9 月 4 日に #709/#710、9 月 9 日に #711、9 月 11 日に #712/#713/#714、9 月 16 日に #715、9 月 18 日に #716/#717、9 月 20 日に #718、9 月 30 日に #719 が ML 上で周知された。技術的内容としては、FAPI 2.0 Message Signing から HTTP Signatures 部分を別ドラフトとして切り出す という重要な編集判断（Issue #709）、ID Token 署名検証の必須性に関する Dima Postnikov の問題提起（Issue #711）、HTTP メッセージ署名における署名の署名（signature-of-signature）の安全性に関する Takahiko Kawasaki の指摘（Issue #718）など、Final 化前の最終整理に直結する論点が並んだ。また同月、OpenID Foundation 全体としては Process Document と IPR Policy の改訂提案が 9 月 12 日に理事会承認を経て会員レビュー期間（9/13〜10/4）に入っており、FAPI 2.0 Final 投票の手続き的根拠の整備が同時進行していた。

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

openid-specs-fapi ML の 2024-September アーカイブ には 25 件相当の投稿が収録されている。Issue 起票件数で見れば前後の月（8 月・10 月）と比べても突出して多く、Final 化前の論点出しが集中的に行われた月である。

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

2024 年 9 月は WGLC / Call for Adoption / Final 投票通知のいずれも開始されなかった。すなわち外形的な「公開仕様アクション」は静かな月であり、編集作業は Bitbucket 上での Issue 起票・PR 議論に集中していた。FAPI 1.0 Errata の WGLC は翌月（10/2）に Dave Tonge から起票され、FAPI 2.0 HTTP Signing 分割の Call for Adoption も 10/2 起票となる。9 月はこれらの 10 月アクションへの 準備期間 として位置付けられる。

OpenID Foundation 全体レベルでは、以下のプロセス文書改訂が動き始めた。FAPI WG の Final 投票運用に直接影響する事項である。

OpenID Foundation Process Document / IPR Policy 改訂提案（2024-09-12 理事会承認） ​

ML #003202（Elizabeth Garber、9/26）および ML #003203（Gail Hodges、9/26）で WG に周知された改訂内容は次のとおり。

Process Document の主な変更点:

  • 新規定義語の追加: 「Non-Core Decision」「Core Decision」「Quorum Requirement」「Substantive Change」
  • クォーラム要件の現実化: 「Active Contributors の 20% または 20 名のいずれか少ない方」へ調整
  • 一部の意思決定を会員全員投票から Board Supermajority confirmation vote へ移行
  • Work Group Repositories を WG 活動の正式な venue として参照
  • 仕様 artifact の種類整理

IPR Policy の主な変更点:

  • 「Table 1: Overview of IPR applicability」を追加し、文書タイプごとの権利・義務適用を明確化
  • 「Errata corrections」「Final Specification Incorporating Errata Corrections」の定義を追加
  • 著作権節を文書タイプ別に再編成

タイムラインは会員レビュー 9/13〜10/4、会員投票 10/5〜10/19。投票は最終的に 10/19 に賛成 106 / 反対 1 / 棄権 21 で可決される（10 月レポート §2 参照）。

Bitbucket Issue 起票による編集論点の蓄積 ​

9 月の実体的成果は、後述の §5 にまとめる Issue #709〜#719 として整理される。これらは Final 化に向けた「実装してみて初めて分かる文言曖昧さ」「形式的検証の射程との整合」「IANA レジストリ整備」「参照 RFC の更新」「セキュリティ考慮事項の補強」といった編集論点の体系的な棚卸しに相当する。

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

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

2024-09-11 Atlantic コール ​

ML #003179 で Nat Sakimura がコール開始 50 分前に詳細アジェンダ付きでリマインダーを投函した（"FAPI Atlantic Call in 50 min."、UTC 13:08）。標準項目（Roll Call / Pull Requests / Issues / AOB）に加え、以下のトピックが並ぶ。

  • Events: SIDI Hub、Identity Week、ETSI/CEN EU Digital Identity Framework Standards Workshop、Fido Authenticate、OpenID Foundation workshop、DCP Working Group Meeting、IIW、IETF Dublin、OIDF Japan Workshop Tokyo、Calendar
  • External Liaisons: CFPB、Canada、Chile、SAMA、FDX、European Digital Identity Frameworks
  • Spec Updates: FAPI 2 Security Profile、FAPI 2 Message Signing、FAPI 1 Errata、Implementation Guidance、CIBA、FedCM、Other Issues

このアジェンダは「FAPI 1 / FAPI 2 / Message Signing / CIBA / FedCM」と FAPI 周辺のほぼすべての仕様系列が同時並走している状況を可視化している。とりわけ External Liaisons の節で CFPB、SAMA、カナダ、チリ、欧州を並列に置いている点は、FAPI が単一国・単一エコシステムの規格ではなく、各国規制当局のオープンバンキング / オープンファイナンス制度設計に組み込まれつつある実態を反映している。コール開催と同日に Dave Tonge が Issue #712 を、Nat Sakimura が Issue #713 を、Takahiko Kawasaki が Issue #714 を起票しており、Spec Updates / Other Issues 節で扱われる論点がコールを契機に Bitbucket 上に落とし込まれている。

2024-09-18 Atlantic コール ​

ML #003186 で Nat Sakimura がコール直前にドラフトアジェンダを投函した（投函日時 2024-09-18 11:56 UTC、本文に "Date & Time: 2024-09-18-14:00 UTC" と明記。件名は "Draft Agenda for 2024-09-08 Atlantic Call" となっているが日付タイポと考えられる）。アジェンダは Roll Call / Adoption of Agenda / Events (Mike L.) / External Orgs & Liaisons (Mike L.) / PRs (Dave) / Issues (Dave) / AOB (Nat) の簡素な構成。

コール直後（同日 14:11/14:15 UTC）に Dave Tonge は Issue #716 (RFC6125 obsolete) と Issue #717 (Missing security considerations for attacker model) を立て続けに起票しており、コール内での議論で浮上した論点が即座に Bitbucket 上の Issue に落とし込まれる運用が確認できる。

2024-09-20 Pacific コール ​

ML #003189 で 9/19 にアジェンダが投函された。標準構成（Antitrust Statement / Roll Call / Adoption of the Agenda / Events / External Organisations / PRs and Issues / AOB）で、Pacific コールの運用に沿った構成である。

同日（9/20）中に Takahiko Kawasaki から Issue #718 が起票されており、Pacific コールでの議論内容と整合する。論点は 「FAPI 2.0 Message Signing Section 5.6.2.1 が、リソースサーバの応答署名にリクエスト側の signature / signature-input フィールドを req フラグで含めることを要求しているが、RFC 9421 はこの実践を NOT RECOMMENDED としている」 という、Final 化に直結する規範的不整合の指摘であった。

2024-09-25 Atlantic コール（UTC 14:00 / JST 9/25 23:00 - 9/26 0:00） ​

ML #003193 で「Updated invitation: FAPI WG Call 2024-09-25」が発出され、ドラフトアジェンダと OIDF Antitrust Statement が添付された。同タイミングで Nat Sakimura は bi-weekly schedule、2024-11-20 開催分、2025-01-01 開催分 について招待を更新しており、Q4 2024〜2025 年初頭にかけてのコール運用を整える事務手続きが集中している。

このコール本体の議論内容は ML から直接は読み取れないが、翌週（10/2）に Dave Tonge が FAPI 1 Errata WGLC と FAPI 2 HTTP Signing 分割の Call for Adoption を同時に起票していることから、9/25 コールでこれら 2 件の WG 内合意形成が概ね済んだと推測できる。

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

2024 年 9 月の openid-specs-fapi ML は 25 件相当の投稿を含む。技術的に重要な主要スレッドを以下に整理する。

Issue #711: ID Token signature validation — 2024-09-09 Dima Postnikov ​

ML #003178 は共同議長の Dima Postnikov による問題提起で、本月の論点群の中でも最も基礎的な部類に属する。発端は次の観察である。

we have just found out that some implementations do it and some don't.

すなわち、FAPI 認定取得済みの実装の中にも ID Token の署名検証を行っているもの・行っていないもの が混在することが確認された。Postnikov はこれを問題視し、「Common sense says 'yes'」（常識的には ID Token 署名検証は必須であるべき）としつつも、形式的セキュリティ分析が ID Token 署名検証を critical control として依存しているかを確認した上で、仕様上明示すべきであるという論点を提起した。

関連する GitLab 上の Conformance Suite Issue #1375 も参照されており、ML だけの議論ではなく、認定スイートの判定基準としても整合性を取る必要があることが示唆されている。これは「Final 化前にこそ仕様の最も基礎的な前提を再確認する」という FAPI 2.0 の方法論を象徴する論点で、後の月の編集作業で扱われることになる。

Issue #709: Separate out HTTP Signatures from the message signing spec — 2024-09-04 Dave Tonge ​

ML #003176 で Dave Tonge は、FAPI 2.0 Message Signing から HTTP Signatures 部分を別ドラフトに切り出す方針を明確に提起した。理由は次のとおり。

it is slowing us down in moving to final with message signing and is not an immediate requirement

つまり、Message Signing の成熟部分は Final 化のレールに乗せられる一方、HTTP Signatures 部分は実装の蓄積がまだ不足しており、Final 化の足を引っ張っているという判断である。ML 投稿の段階では「分割する」という WG の内部合意の周知だが、対外的な Call for Adoption は翌月 10/2 に起票されることになる（10 月レポート §2 参照）。

この分割判断は、現在の FAPI 2.0 系列が fapi-message-signing-2_0（Message Signing 本体）と fapi-2_0-http-signatures（作業中の独立ドラフト）の 2 本立てとなる起点である。

ML #003190（Takahiko Kawasaki, 9/20）と ML #003195（Anders Rundgren, 9/26）の 2 投稿からなる。

Kawasaki の問題提起は次の構造を持つ。FAPI 2.0 Message Signing Section 5.6.2.1 は、リソースサーバが応答に署名を付与する際、リクエスト側の signature および signature-input フィールドを req フラグで応答署名のカバー範囲に含めることを要求している。しかし RFC 9421 Section 2.4 は、この実践（response が request の signature/signature-input を含めて署名する、いわゆる signature-of-signature）を 明示的に NOT RECOMMENDED と規定し、以下のような攻撃に対して脆弱であると述べている。

signatures of signatures do not provide transitive coverage of the components

Kawasaki の提案は、FAPI 2.0 Message Signing から該当箇所を削除すること、もしくは「リクエスト署名の受領を成功裏に確認したい場合に使う代替メカニズム」を別途定義することである。

これに対し Anders Rundgren は 9/26 に応答し、Kawasaki の指摘を支持した上で、deterministic CBOR を用いれば HTTP ヘッダに署名値を埋め込む構造そのものを回避できる、と自身の CBOR-Everywhere プロジェクトを引き合いに出した。Rundgren の代替提案は本論点の直接の解決策ではないが、HTTP メッセージ署名アプローチ全体への懐疑として記録されるべき論点である。

Issue #714: Multiple HTTP message signatures in a single HTTP message — 2024-09-11 Takahiko Kawasaki ​

ML #003182 は同じく Authlete の Takahiko Kawasaki による問題提起。FAPI 2.0 Message Signing Section 5.6 は、1 つの HTTP メッセージに複数の署名が含まれる場合の取り扱いを明示していない。Kawasaki の主張は次のとおり。

the specification should explicitly state that a single compliant signature is sufficient

つまり、1 つのメッセージに複数の署名が存在する場合、そのうち 1 つが FAPI 2.0 準拠であれば十分 と仕様で明記すべきだという立場である。これにより、FAPI 2.0 Message Signing と並行してアプリケーション固有署名を共存させる構成が成り立つ。全署名に FAPI 2.0 準拠を要求すると実装上の困難が生じる、という運用観点の指摘である。

ML #003204 は月末（9/30）に起票された Kawasaki による論点。HTTP メッセージ署名検証失敗時のエラーコードが汎用的な invalid_request に集約されてしまっており、API クライアントが原因切り分けに難儀するという実装者観点の指摘である。

Kawasaki の参照は RFC 9449（OAuth 2.0 DPoP）で、DPoP は invalid_dpop_proof および use_dpop_nonce といった専用エラーコードを定義している。これに倣い、FAPI 2.0 Message Signing についても invalid_http_message_signature 等の専用エラーコードを定義すべきという提案である。

EUIDW-4-Payments update: dropping OAuth — 2024-09-16 Anders Rundgren ​

ML #003183 で Anders Rundgren が、欧州デジタル ID ウォレット (EUIDW) の決済応用イニシアティブが OAuth 2.0 から離れる方向に動いている件を報告した。Rundgren の評価は厳しい。

an extremely poor API extension … most likely prove to be a genuine blocker

すなわち、提案されている "Signed Payment Request" 構造を「極めて不出来な API 拡張」と断じ、自身が主導する Open Banking 2.0 プロジェクトを代替案として推した。FAPI WG にとって直接の仕様作業ではないが、欧州決済領域における OAuth ベースアプローチの限界が議論の俎上に上がった点は、後の Open Banking 2.0 議論（10/16 Atlantic コールでアジェンダ化）の伏線となる。

In Wallet We Trust: USENIX Security 2024 紹介 — 2024-09-02 Nat Sakimura（応答 2024-09-02 Anders Rundgren） ​

ML #003174 で Nat Sakimura が USENIX Security 2024 の論文「In Wallet We Trust: Bypassing Digital Wallets Payment Security for Free Shopping」を WG に紹介し、push-based MFA を緩和策として挙げる研究内容を共有した。Anders Rundgren は ML #003175 で「現実の詐欺の多くは ID 詐欺に根がある」「device attestation と application-specific keys の組み合わせがウォレット完全性確保に有効」「A2A 決済はカード複製のような脅威がないので状況が異なる」と応答した。FAPI 直接の仕様議論ではないが、デジタルウォレット決済のセキュリティ前提を WG として共有する典型的なやり取りである。

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

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

11 件という起票件数は、Final 化前の論点棚卸しとして突出している。論点は以下の 4 系統に大別できる。

  1. 編集系・準備系（#710 謝辞、#712 errata 準備、#713 overview 文言）: Final 化に向けた地ならし
  2. ドラフト構造の再編（#709 HTTP Signatures 切り出し）: Message Signing Final 化のための切り離し
  3. 規範的内容の見直し（#711 ID Token 署名、#716 TLS 参照、#717 Security Considerations、#718 signature-of-signature、#719 エラーコード）: 既存条文の妥当性検証
  4. レジストリ整備（#715 JARM IANA）: IANA 登録ギャップの解消

実装者観点（Authlete の Takahiko Kawasaki から #714/#718/#719 の 3 件、Filip Skokan から #715、Dima Postnikov の運用観点から #711）の指摘が連続したことが特徴で、Final 化前に「実装してみて初めて分かる文言曖昧さ」が一気に表面化した月といえる。これらの Issue の解決作業は 10 月以降、Atlantic / Pacific 両コールで継続される。

6. 関連イベント ​

IETF 121（事前周知） ​

9/11 Atlantic コールのアジェンダに「IETF Dublin」が Events 項目として含まれていた。これは 2024 年 11 月 2-8 日にダブリン（アイルランド）で開催される IETF 121 の事前周知で、FAPI WG コアメンバーの多くが IETF にも参加する実態を反映する。後に 10/30 の ML #003222 で 11/6 Atlantic コールが IETF 121 と重複のため事前キャンセルされることになる。

SIDI Hub / Identity Week / ETSI/CEN EU Digital Identity Framework workshop ​

9/11 Atlantic コールの Events 項目に列挙された外部活動。FAPI WG として個別の登壇情報は ML 上で確認できないが、Liaisons 議論の中で各地イベントの進行状況が共有された。

OAuth Security Workshop 2025 の Save the Date — 2024-09-16 ​

Daniel Fett が ML #003185 で 2025-02-26〜28 にレイキャビク（アイスランド、Signicat ホスト）で開催される OAuth Security Workshop 2025 の事前周知を行った。Call for Sessions の締切は 2024-11-24 と 2025-01-12 の 2 段階。FAPI 2.0 の形式的検証作業を行ってきた Daniel Fett をはじめ、FAPI WG コアメンバーが OSW で発表する慣例があり、Final 化後のレビュー結果が翌年 2 月の OSW で報告される運用構造が見える。

OpenID Foundation Process / IPR Policy 改訂レビュー期間開始 — 2024-09-13 ​

理事会承認（9/12）を受けて、9/13 から 10/4 までの 3 週間が会員レビュー期間として設定された。FAPI WG 個別のイベントではないが、Final 投票の手続き基盤に直結するため WG メンバーも当事者として参加した。

7. 今後の予定 ​

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

  • FAPI 1.0 Errata の WGLC 起票: 9 月中に Issue #712 として準備が進められ、10/2 に Dave Tonge から正式に WGLC が起票される
  • FAPI 2.0 HTTP Signing 分割の Call for Adoption: 同じく 10/2 に Dave Tonge から正式起票
  • FAPI 2.0 Security Profile / Attacker Model の Final パブリックレビュー開始: 12 月開始予定（実際は 2024-12-09 開始、60 日間）
  • 9 月起票 Issue 群 (#709〜#719) の解決: 編集系・規範系・レジストリ系の論点を WG コール / PR 経由で順次処理
  • OpenID Foundation Process / IPR Policy 会員投票: 10/5〜10/19 に実施予定
  • 2024-09-25 / 10-02 / 10-16 / 10-30 Atlantic コール: bi-weekly schedule で継続
  • IETF 121 (Dublin, 11/2-8): WG コアメンバー多数参加見込み
  • IIW 39 (Mountain View, 10/29-31) と OIDF Workshop at Microsoft (10/28): Q4 の主要対面集合機会

8. 参考情報源 ​

メーリングリスト ​

議事録 (Bitbucket wiki) ​

Issue トラッカー (Bitbucket) ​

仕様 ​

関連プロジェクト・外部参照 ​

関連リソース（OpenID Foundation） ​