idbok

Appearance

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

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

1. 概要 ​

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

2024 年 10 月は、12 月 9 日に控えた FAPI 2.0 Security Profile / Attacker Model Final パブリックレビュー開始 の前段として、複数の編集系決定が集中した月である。月の初週には FAPI 1.0 Errata の Working Group Last Call (WGLC) と、FAPI 2.0 Message Signing から HTTP Signing 部分を切り出して別ドラフトとする Call for Adoption が並行して提起された。月の中盤から後半にかけては、FAPI 2.0 Message Signing の細部について実装者（特に Authlete の Takahiko Kawasaki と Hideki Ikeda）から具体的な Issue が連続起票され、keyid パラメータの必須化、HTTP メッセージ署名のアルゴリズム制約、UserInfo エンドポイントの署名要件など、Final 化を見据えた論点が短期間で出揃った。10 月 19 日には OpenID Foundation 全体の Process Document と IPR Policy の改訂 が会員投票で正式に承認され、月末には IIW 39 (10/29-31) と OIDF Workshop at Microsoft (10/28) の関連イベントが開催された。

月内の主要な動きは以下のとおり。

openid-specs-fapi ML の 2024-October アーカイブ には 21 件の投稿が収録されており、前後の月（9 月・11 月）と比較しても活発な月にあたる。WGLC・Call for Adoption・複数の Issue 起票が並行進行する Final 化前段階の典型的な姿である。

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

FAPI 1 Errata Working Group Last Call（2024-10-02 〜 2024-10-18） ​

10 月 2 日に Dave Tonge が ML #003206 で FAPI 1.0 Part 1 (Baseline) および Part 2 (Advanced) の errata 更新を対象とする WGLC を起票した。対象ドキュメントは openid-financial-api-part-1-1_0.md および openid-financial-api-part-2-1_0.md の 2 本で、前回公開版からの差分を示す diff 文書も添付された。

We will complete this working group last call on the 18th of October (unless substantial issues are raised that require further working group input).

期限は 10/18 と短く、ML または Bitbucket Issue でのフィードバックを受け付ける運用とされた。FAPI 1.0 は 2018 年 Final 化済みのため、本 WGLC は規範的変更を含む errata の収束フェーズに位置する。なお、11 月 27 日の Atlantic コールで「FAPI 1.0 のエラータに normative change を含めて良いか」という手続き的論点が改めて取り上げられることになり、その伏線は 10 月の WGLC 段階で既に張られていたと言える。

FAPI 2 HTTP Signing — Call for Adoption（2024-10-02） ​

同じく 10 月 2 日、Dave Tonge は ML #003207 で FAPI 2.0 Message Signing から HTTP Signatures 部分を切り出して別ドラフトとする Call for Adoption を提起した。

the more mature elements of the message signing draft can be taken to final, whereas the http signing section can remain as a working draft.

判断の理由は明快で、HTTP Signatures（RFC 9421 ベース）部分は WG として 相互運用可能な実装が十分に揃っていない ため Final 化に進めるには時期尚早である一方、Message Signing の成熟した部分は Final 化に進める価値があるという見立てである。具体的な対象 Issue / PR は Bitbucket Issue #709 (Separate out HTTP Signatures) および対応 PR pull-requests/519 として明示された。

この分割提案は、現在 fapi-message-signing-2_0 と fapi-2_0-http-signatures (draft) という 2 本立ての構造を生み出す起点となった意思決定である。

Process Document v1.98 と IPR Policy の改訂承認（2024-10-19） ​

WG 個別の仕様ではないが、FAPI WG の活動を律する全体ルールの改訂として、10 月 19 日に OpenID Foundation Process Document v1.98 と IPR Policy (Final 2024-10-19) が会員投票で正式に承認された。理事会は 9 月 12 日に全会一致で承認しており、続く会員レビュー・投票期間を経た最終承認である。投票結果は賛成 106 / 反対 1 / 棄権 21、参加率 34%（クォーラム 30% を上回る）。Operations Director の Mike Leszcz が 10 月 22 日に ML #003220 で WG へ周知した。

主な変更は「Foundation の現在の運営実態と文書を整合させる」編集的改善が中心で、Process Document と IPR Policy の間に存在した不整合の調整も含まれた。Final 化を控えた FAPI 2.0 にとっても、ここで確立されたプロセスが Final パブリックレビュー・投票の手続き的根拠となる。

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

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

2024-10-02 Atlantic コール ​

ML #003205 で Dave Tonge が「90 minutes」前のリマインダーを投函（12:32 UTC）。「quite a few apologies」を受け取っており通常より短時間で終わる見込みとした。同日、コール開始（14:00 UTC 想定）の直前に Dave 自身が FAPI 1 Errata WGLC（12:36 UTC）と FAPI 2 HTTP Signing 分割の Call for Adoption（12:41 UTC）を立て続けに ML 投函しており、コール本体でこれら 2 つの大きな意思決定について議論する下地を整える段取りが組まれていたと読み取れる。

2024-10-04 Pacific コール ​

ML #003208 で Nat Sakimura が「Pacific Call in 20 min」をリマインド。標準アジェンダ（Roll Call / Agenda Adoption / Events / External Orgs & Liaisons / PRs / Issues / AOB）で進行。Pacific コールは Anoop Saxena が PRs/Issues を担当する構成となっており、Asia-Pacific 帯の実装者の参加機会を確保する運用が継続している。

2024-10-16 Atlantic コール ​

Nat Sakimura は 10/16 当日の朝に ML #003217 で標準アジェンダを投函し、追って ML #003219 で 「FAPI 2.0 Issues」項目の追加 と OIDF Antitrust Policy の声明追加 を含むアジェンダ更新を出した。Nat 自身のコメントが特徴的である。

reverting one of the changes we introduced after I-D 2 on which formal analysis was done

すなわち、Implementer's Draft 2 の後に取り込んだ変更のうち、Daniel Fett らの形式的セキュリティ分析（ACM TOPS 採録版）の射程外となる修正について revert（元に戻す） ことを WG として検討する論点が、このコールに上程された。Final 化を直前に控える局面で「形式的検証が及んでいる範囲の仕様内容」を Final 仕様の境界として優先する姿勢が読み取れる。これは FAPI 2.0 の特徴である「学術的検証と仕様策定の二人三脚」を象徴する判断であり、月の重要な節目となった。

加えて、新規アジェンダ項目「Open Banking 2.0 (Anders)」は、Anders Rundgren が 10/8 に投じた EUIDW-4-Payments postmortem を受けた拡張議論の場であった可能性が高い。

2024-10-18 Pacific コール（推定） ​

Pacific コールについて 10 月後半は ML 上にリマインダー投稿が確認できない（10/4 のみ）。週次運用が継続していれば 10/18 開催想定だが、ML 投稿欠如のため正確な開催有無は議事録参照を要する。

2024-10-30 Atlantic コール ​

Nat Sakimura が 10/23 に ML #003221 でアジェンダを予告し、10/30 当日に ML #003226 で「Updated agenda」を伴う更新版招待を再送した。アジェンダの目玉は 「Events (Mike L.) — IIW」 で、その後の数日（10/29-31）開催の IIW 39 と 10/28 開催の OIDF Workshop at Microsoft を踏まえた現地報告・連携議論が予定されていた。

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

2024 年 10 月の openid-specs-fapi ML は 21 件の投稿を含む。Final 化前段階としては活発で、技術内容を含む主要スレッドを以下に整理する。

Issue #721: The keyid parameter — 2024-10-07 Takahiko Kawasaki ​

ML #003211 は Authlete の Takahiko Kawasaki が起票した FAPI 2.0 Message Signing への提案である。論点は HTTP メッセージ署名に標準的かつベンダ中立な鍵識別子が欠けている ことで、各 RS が独自の鍵識別手段を強いられる現状を解消する意図がある。

提案は RFC 9421 の keyid パラメータを created / tag と並んで mandatory として Signature-Input フィールドに含めることである。利点として以下が示された:

  • 相互運用性: 各機関で異なる鍵識別ルールを設けるのではなく、共通の手法を確立できる
  • ベンダ中立性: 標準準拠であれば任意の参加者が利用できる
  • 複数署名の取り扱い: RFC 9421 の「異なる鍵またはアルゴリズムで同一コンポーネントに署名する複数署名」ユースケースに対応できる
  • 複雑性低減: 金融アプリは機関ごとに鍵識別スキームを交渉する負担を回避できる

Signature-Input フィールドへの keyid 出現を示す具体例が添付された。

Issue #722: Algorithms for HTTP message signatures — 2024-10-07 Takahiko Kawasaki ​

ML #003213 は同 Takahiko Kawasaki による続編で、2 つの実務的論点を提起した。

第 1 に アルゴリズム識別 の課題である。HTTP メッセージ署名は JWT と異なり署名情報内にアルゴリズムを含まず、RFC 9421 は次のように述べている。

the explicit alg signature parameter is not used at all when using JOSE signing algorithms

Kawasaki の提案は、JWK で鍵を表現する場合に alg パラメータの明記を必須化する こと（現状は optional）である。鍵登録時にアルゴリズム宣言が欠落していることに起因する検証失敗を予防できる。

第 2 に アルゴリズム制限の射程 である。FAPI 2.0 Security Profile のアルゴリズム制約は「JWT の生成・処理時」を対象としており、文言上は HTTP メッセージ署名には及ばない。この扱いを (a) HTTP メッセージ署名にも明示的に拡張する、(b) 意図的に拡張しない、のいずれかに WG として決定すべきという問題提起である。

両 Issue ともに keyid 必須化・alg 必須化と FAPI 2.0 全体の暗号アルゴリズム規律との接合点を狙ったもので、HTTP Signing 部分を別ドラフトに分割した（10/2 Call for Adoption）後の編集論点として 11 月以降に持ち越されることになる。

Issue #723: Clarifying Message Signing for UserInfo — 2024-10-09 Hideki Ikeda (authlete-hide) ​

ML #003215 は同じく Authlete の Hideki Ikeda による問題提起で、論点は FAPI 2.0 Message Signing の Section 5.7 が「クライアント」と「リソースサーバ」の署名要件のみを規定し、UserInfo エンドポイントを運用する Authorization Server (AS) を明示的にカバーしていない ことである。

Ikeda は 2 つの解決方向を示した:

  1. UserInfo を保護リソースと見なすなら、Section 5.7 に AS への要件を追加 する
  2. 用語を resource servers から protected resource endpoints に改め、AS が運用するエンドポイントも含む形に再定義する

UserInfo は OIDC の核心エンドポイントである一方で運用主体が AS と RS のいずれにもなり得るため、FAPI 2.0 Message Signing 文言の用語整理は読者の解釈を左右する。これは「Message Signing を Final 化に進める成熟部分」と「HTTP Signing を作業中ドラフトとして残す部分」の境界を引き直す上での実装者観点の指摘である。

Issue #724: use_mtls_endpoint_aliases name — 2024-10-09 Dave Tonge ​

ML #003216 は議長の Dave Tonge 自身による命名議論で、use_mtls_endpoint_aliases パラメータの命名の不透明さを指摘した。

what are the 'aliases' that are being referred to?

代案として mtls_use_preferred または mtls_use_required が示唆されたが、これは Final 化前の最後の命名整理を意図したものと位置付けられる。命名変更は後方互換性に影響するため決着には慎重さが必要で、本論点も翌月以降の編集議論に持ち越される。

How can RS get clients' public keys without a federation — 2024-10-07 Kosuke Koiwai ​

ML #003212（質問）と ML #003214（自答）の 2 投稿構成。発端の問題提起は次のとおり。

what is the standard or best practice to share the public keys of clients between AS and RS?

sender-constrained access token を用いる構成では、RS が client の公開鍵を検証できる必要がある。フェデレーション環境では鍵交換が容易だが、非フェデレーション環境での標準・ベストプラクティスを問うものである。Koiwai は当初の選択肢として (1) Token Introspection を拡張する、(2) JWT Profile for OAuth 2.0 Access Tokens にクレームを追加する、を挙げた。

2 時間半後の自答 ML #003214 では、既存仕様で解決可能であることが整理された:

  1. RFC 8705: JWT certificate thumbprint で鍵を識別（フルキーの転送を回避）
  2. RFC 7800 Section 3: セキュリティトークン内に鍵情報を埋め込む

つまり、トークンに鍵参照・鍵情報を組み込む既存メカニズムにより、別途の鍵ディレクトリ運用なしに RS は sender-constrained アクセストークンを検証できるという結論である。WG として新たな仕様化は不要との示唆で、短いが Q&A として完結したスレッドである。

Issue #720: Drop 5.5 and move it to implementation guidance — 2024-10-04 Nat Sakimura ​

ML #003209 は Nat Sakimura が起票した編集論点で、Section 5.5 を仕様から除いて実装ガイダンス文書に移すべきという提案である。

It does not belong to a spec.

加えて「テーブルヘッダが誤っている」「テーブルタイトルが単に Table 1 となっている」という構造的な不備も指摘された。Final 化前のクリーンアップとして提起されたもので、ML 上での即時の反応スレッドは確認できないが、Atlantic コールの「Issues (Dave)」項目で順次処理される運用に乗ったと考えられる。

EUIDW-4-Payments postmortem — 2024-10-04 Anders Rundgren ​

ML #003210 で Anders Rundgren が欧州デジタル ID ウォレットの決済応用イニシアティブ (EUIDW-4-Payments) の中間総括を投じた。

after more than a year of activity haven't seen a consolidated specification, we can with high certainty assume that interoperability is zero.

trying to change something in the existing projects would be too difficult; they have to crash and burn on their own.

提案は forward-looking で、既存プロジェクトを修復するのではなく、リスタート時にどのアプローチを取るべきかを ML コミュニティに問う形を取った。FAPI WG にとっては Open Banking 2.0 の議論文脈と接続する話題で、10/16 Atlantic コールのアジェンダに「Open Banking 2.0 (Anders)」が追加された経緯と整合する。

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

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

加えて 10/2 の Call for Adoption が参照する Issue #709: Separate out HTTP Signatures from the message signing draft と対応 PR (pull-requests/519) も 10 月の重要な作業項目である。

これらの Issue は、(1) Final 化前の編集系クリーンアップ（#720, #724, #725）、(2) FAPI 2.0 Message Signing / HTTP Signatures の技術的明確化（#721, #722, #723）、(3) ドラフト分割（#709）、という 3 系統に大別できる。実装者観点（Authlete メンバー）からの指摘が連続したことが 10 月の特徴で、Final 化に向けて「実装してみて初めて分かる文言曖昧さ」が一気に表面化した月である。

6. 関連イベント ​

IIW 39 (XXXIX) — 2024-10-29 〜 2024-10-31 ​

Internet Identity Workshop XXXIX (39) が Computer History Museum (Mountain View, CA) で 3 日間にわたり開催された。アンカンファレンス形式の老舗 ID イベントで、FAPI WG メンバーを含む OIDF コミュニティが大規模に集合する。10/30 Atlantic コールのアジェンダに「Events (Mike L.) — IIW」項目が組み込まれており、IIW でのアンカンファレンス議論を FAPI WG にフィードバックする運用が踏まれた。

OpenID Foundation Hybrid Workshop at Microsoft — 2024-10-28 ​

IIW 直前の月曜日 12:30〜15:45 PT に、Microsoft（Mountain View）で OIDF ハイブリッドワークショップ が開催された。各 WG / CG の現況共有と質疑の場で、FAPI 関連としては Security Profile / Attacker Model の Final レビュー直前の状況が共有された想定である。

Process Document v1.98 / IPR Policy 改訂承認 — 2024-10-19 ​

会員投票（クォーラム 30%、投票期間中の参加率 34%）により Process Document v1.98 と IPR Policy Final が正式承認。OIDF Foundation 全体のプロセスルール改訂であり、FAPI 2.0 Final パブリックレビューの手続き的根拠を整える。

IETF 121 (11/2-8) との重複による 11/6 コール先行キャンセル ​

10/30 に Mike Leszcz が ML #003222 / ML #003223 で 11/6 Atlantic コールの事前キャンセルを通知。理由は IETF 121（11 月初週、ダブリン開催）との重複である。FAPI WG コアメンバーの多くが IETF にも参加する実態を反映する運用判断である。

7. 今後の予定 ​

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

  • FAPI 1.0 Errata の最終化: 10/18 締切の WGLC を受けて errata プロセス完了に向けた事務手続き
  • FAPI 2.0 HTTP Signing ドラフト分割: 10/2 Call for Adoption の結論を踏まえ、Message Signing 部分の Final 化準備と HTTP Signatures 部分の独立ドラフト化
  • FAPI 2.0 Security Profile / Attacker Model Final パブリックレビュー: 12 月開始予定（実際は 2024-12-09 開始、60 日間）
  • 10 月起票 Issue 群の解決: #720（編集移動）、#721/722/723（Message Signing 文言）、#724（命名）、#725（謝辞修正）の処理
  • 2024-11-06 Atlantic コール: IETF 121 との重複により事前キャンセル済み
  • 2024-11-20 / 11-27 Atlantic コール: 標準アジェンダで Final レビュー直前期の編集整理を継続
  • DPoP の Conformance Test 対応: 11/7 公示予定（実際に 11/7 に FAPI 2.0 Conformance Tests Now Support DPoP として公示）

8. 参考情報源 ​

メーリングリスト ​

議事録 (Bitbucket wiki) ​

Issue トラッカー (Bitbucket) ​

公式アナウンス・規定 ​

仕様 ​

関連イベント ​