進化するTLS暗号スイートへのFAPIの適応

FAPIは導入が広がり、実装が成熟してきました。そして今、継続メンテナンスが初期の実装と同様に重要となっています。特に管理が難しい課題の一つが、TLS暗号スイートの扱いです。

FAPIは、広く普及しているインターネット標準仕様を前提としています。これまでこの設計方針は有効でしたが、同時にこれは、前提とした標準仕様のライフサイクルに伴う変化の影響を受けることを意味します。暗号スイートは不変ではなく、研究者や標準化団体によって、新たに追加されたり、分類が見直されたり、非推奨とされたりするためです。

この記事では、FAPIワーキンググループが、この課題にIANA（Internet Assigned Numbers Authority）レジストリへの準拠によってどう対応しようとしているかを説明します。FAPI仕様と適合性テストの今後の変更点を解説し、実装コミュニティがTLS 1.3へ移行すべき理由を述べます。

暗号スイートの進化の仕組み

インターネットコミュニティは、以下の複数の仕組みを組み合わせてTLS暗号スイートを管理しています：

• IANAレジストリ： 各暗号スイートとその現在のステータスを一覧化
• IETF RFC（例：RFC 8446）： プロトコルの動作を定義
• 現在のベストプラクティス（BCP）（例：RFC 9325）： その時点での実装ガイドラインをまとめる

IANAレジストリでは、各暗号スイートのエントリに以下の情報が関連付けられています：

• 定義しているRFC
• 適用可能なプロトコルバージョン（TLS 1.2、TLS 1.3）
• 現在のステータス（推奨、非推奨、予約済み）

これは意図的な設計です。標準化団体は、安全で有用と判断されれば新たな暗号スイートを導入しますが、より優れた代替手段が登場したり脆弱性が発見されたりすれば、既存のものを非推奨とします。このモデルゆえに、静的に「許可リスト」を定めても、それはいずれ時代遅れになってしまうのです。

FAPI 2.0とBCP 195

FAPI 2.0セキュリティプロファイルは、TLSのセキュリティ要件を、現在RFC 9325として公開されているBCP 195に委ねています。これは仕様策定時点では適切な判断でした。しかし、RFC 9325自体がその適用範囲を明示的に限定している点に注意が必要です。

• TLS 1.2の場合： RFC 9325 セクション4.2は、以下のごく限られたAES-GCM暗号スイートのみを挙げ、他を推奨していません。
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS 1.3の場合： RFC 9325 セクション4.3は、暗号に関する全てのガイダンスをRFC 8446に委ねています。RFC 8446 セクション9.1は以下の暗号を定義しています。
• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256

重要なのは、RFC 8446がこれらのアルゴリズムを、TLSのバージョンに関わらず、「現代的で安全な構成」として扱っていることです。

ChaCha20-Poly1305と、静的BCP適用の限界

最近の一件が、暗号スイートを静的に規定することの難しさを露呈しました。

あるFAPI 2.0準拠の実装が、TLS 1.2接続でサーバーがTLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256という暗号スイートを提示したために、適合性テストに失敗したのです。その理由は、FAPI 2.0適合性テストがTLS 1.2に対してBCP 195（RFC 9325）を厳格に解釈し、上記の限られたAES-GCMスイートしか許可していなかったのです。

しかし、ChaCha20-Poly1305は強力な現代的暗号であり、RFC 8446 セクション9.1で定義されている通り、TLS 1.3では実装が必須の暗号スイートです。また、AESのハードウェアアクセラレーションを持たないプラットフォームでのパフォーマンス向上を目的に設計されています。

この事例は、RFC 9325のTLS 1.2用リストを厳密に適用することが、IETFのより広範な意図（強力な現代的暗号を推奨する）と矛盾する場合があることを示しました。実際には、適合性テストの要求と、現実世界での暗号技術のベストプラクティスとの間に齟齬が生じる結果となったのです。

FAPIをIANAレジストリに準拠させる

この問題を受け、FAPIワーキンググループは、TLS暗号管理に対するより明確で持続可能なアプローチを公式に定めようとしています。

• FAPIは、特定のBCP文書の改訂版に縛られるのではなく、暗号に関する要件をIANA TLS暗号スイートレジストリに合わせます
• レジストリに登録され、「推奨」ステータスを持つ暗号スイートは、FAPIでも使用可能とします
• これは、各暗号を定義するRFCの内容と整合する形で、TLSのバージョンを跨いで適用されます
• 適合性テストもこの動的なモデルを反映するよう更新されます
• この方針を反映するため、FAPI 1.0およびFAPI 2.0の正誤表を更新します。

新しい暗号の自動的な段階的導入

IANAが新たな推奨暗号スイートを登録した場合：

• FAPI適合性テストはそれを自動的に受け入れます
• 基本的な利用資格を得るために、FAPI仕様そのものの改訂は必要ありません
• 実装コミュニティは、適合性認証を失うリスクなく、新しい暗号を採用できます
• これにより、FAPIが暗号技術の進歩の妨げになることがなくなります

非推奨暗号の予測可能な段階的廃止

暗号スイートが非推奨とされたり、推奨ステータスから外されたりした場合、その移行は予測可能な段階的アプローチに従います：

1. 初期段階： 適合性テストが警告を発します
2. 移行期間： 実装コミュニティに移行の猶予期間が与えられます
3. 最終段階： 非推奨暗号は適合性テストを通過できなくなります

具体的なタイムラインは別途公表されますが、その意図は、FAPIやBCPガイダンスで既に想定されている12か月の期間と整合する、明確で混乱の少ない移行の機会を提供することにあります。

TLS 1.3がデフォルトとなる

前述のライフサイクルガイダンスはTLS 1.2と1.3の両方に適用されますが、戦略的な方向性は明白です。実装コミュニティはTLS 1.3の導入を最優先すべきです。

IETFは、プロトコルに関する見解を明確に転換し、TLS 1.3を必須とし、TLS 1.2はオプションサポートに移行する方針を示しています。

この立場は、近く更新予定のRFC 9325に反映され、正式な変更となります。以下は、RFC化が目前（AUTH48段階終了済み）のドラフト draft-ietf-uta-require-tls13-12 のセクション5からの抜粋です：

...この文書は、[RFC9325]のセクション3.1.1に記載された推奨事項に対し、以下の2点を変更する：

1. 同セクションはTLS 1.3を「サポートすべき(SHOULD)」としているが、本ドラフトは新規にTLSを利用するプロトコルではTLS 1.3を「サポートしなければならない(MUST)」 と規定する。

• 同セクションはTLS 1.2を「サポートしなければならない(MUST)」としているが、本ドラフトはTLS 1.2は「サポートしてもよい(MAY)」とする。

FAPIの実装環境においても、これは進むべき道筋を明確に示すものです。可能な限りTLS 1.3を有効化し、優先して使用すべきです。 TLS 1.2は、運用上やむを得ない場合にのみ維持してください。

今後の変更点とスケジュール

近日中に、正誤表の草案やテストスイートの変更を含む詳細を共有する予定です。計画されている更新は以下の通りです。

• FAPI 1.0 正誤表:
• 暗号スイートと鍵長の規定を以下の文に置き換えます：
1. [BCP 195]で許可されている鍵長を要求し、使用しなければならない
2. [IANA TLSP]で非推奨とされているアルゴリズムを使用してはならない
• FAPI 2.0 正誤表 (近日公開):
• サーバーは、「Transport Layer Security (TLS) Parameters」レジストリグループ内の「TLS Cipher Suites」レジストリにおいて、許可されており、かつ非推奨とされていない暗号スイートのみを使用しなければならない
• クライアントは、同レジストリにおいて推奨されている暗号スイートのみを許可すべきである
• FAPI 2.0 適合性テスト更新: 近い将来に実施予定
• FAPI 1.0 適合性テスト更新: その後を予定

これらの更新には、前述のIANAレジストリ準拠アプローチが盛り込まれます。

FAPI関係者が次に取るべき行動

すべてのFAPI関係者には、以下のステップを実施されることをお勧めします。

1. 現在のTLS設定を確認する
• 現在使用している暗号スイートを特定する
• それらをIANAレジストリおよびTLS 1.3のデフォルト設定と照合する
2. TLS 1.3導入の準備状況を評価する
• TLS 1.3を有効化し、優先プロトコルとして設定する
• クライアントとサーバー間での動作互換性を検証する
3. 暗号ライフサイクル管理の計画を立てる
• 将来の暗号追加や削除を見越した計画を立てる
• 可能な限り、静的な許可リストをコードに直接埋め込む（ハードコード）ことを避ける

エコシステム間の協業

FAPIは、オープンバンキングおよびオープンファイナンス分野におけるセキュリティのグローバル標準として主導的立場にあり、安全で相互運用可能なデータ共有を実現するため多くの国で採用されています。この規模で相互運用性と高いセキュリティを維持するには、関係者間の調整、透明性、そして予測可能性が不可欠です。

FAPIワーキンググループは、強力で現代的（モダン）な実装が不利益を被ることなく、かつ高いセキュリティ水準を維持できるようにすることを目指しています。FAPIをIANAレジストリにより密接に連携させ、TLS 1.3への移行を推進する今回のアプローチは、エコシステムの長期的な健全な発展を最もよく支えるものと考えています。

参考文献

• RFC 9325: Recommendations for Secure Use of Transport Layer Security and Datagram Transport Layer Security (Section 4.2, Section 4.3)
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 (Section 9.1)
• IANA Registry: Transport Layer Security (TLS) Parameters
• Draft-ietf-uta-require-tls13-12: New Protocols Using TLS Must Require TLS 1.3
• FAPI 2.0 Security Profile: FAPI 2.0 Security Profile

OIDFはNIST SP 1800-42を歓迎するとともに、新たなeKYC作業項目を発表

Juliana Cafik氏（独立系アイデンティティ標準・ソリューションアーキテクト）による寄稿です。Juliana Cafik氏は、mDL向けのOIDF NIST NCCoEプロジェクトのコントリビューターでもあり、OpenID FoundationのOIDC4IDA Claims Registration（クレーム登録）拡張仕様のリードエディターも務めています。

NIST NCCoE モバイル運転免許証（The NIST NCCoE Mobile Driver's Licenses：mDL）プロジェクト（Special Publication 1800-42）は、金融分野のセキュリティにとって大きな転換点です。受動的なデータ収集に依存する方法から、検証可能なアイデンティティを実現するための明確なロードマップへと舵を切る内容となっています。

本ガイダンスは、mDLに基づく手続きが既存のコンプライアンス要件とどのように整合するかを示すことで、これまでの「事後対応的」な監査対策から、顧客識別プログラム（Customer Identification Program：CIP）に対する「事前対応的」な確信へと発想を転換させます。このアプローチは、デジタル・オンボーディングの最初の入口（受付段階）での信頼性と堅牢性を重視し、オンボーディング時のリスクを最小化する考え方です。政府が裏付ける信頼の基点（trust anchor）に根差し、NIST 800-63-4のアイデンティティ保証に基づくNISTアーキテクチャは、デジタル・オンボーディングを効率化するための機械可読なエビデンスを提供し、リスクベースの判断を可能にし、変化する規制要件への対応を支えます。

金融機関はいま、合成アイデンティティ詐欺の前例のない増加、巧妙なディープフェイク、そして従来の画像ベースの本人確認を通用しにくくする自動化された自律型（エージェント型）AI攻撃に直面しており、極めて重要な局面にあります。mDLは、権威ある発行元である州の車両管理局（DMV）によって暗号学的に署名され、金融機関側のリライングパーティ（依拠当事者）によって検証される、検証可能なアイデンティティ証跡です。NIST SP 1800-42の枠組みは、mDLの普及に不可欠な透明性と説明責任、そして現代的な監督のための基盤を提供します。

NIST SP 1800-42Aは現在、5月8日までパブリックコメントを受け付けており、NISTは4月23日にウェビナーを開催します。OpenID Foundationを通じてフィードバックを提出したいコミュニティメンバーは、director@oidf.org に連絡することができます。

この実践ガイドは、NISTの専門家、主要金融機関、州DMV、非営利団体、OpenID Foundation、主要テクノロジー企業、ウォレット提供事業者が、約2年にわたり協働してきた成果です。報告書のエグゼクティブサマリーでは、この業界横断の取り組みの目的について、「市場にある技術を用いて金融機関が標準とベストプラクティスを実装し、金融機関におけるmDL導入によって得られうるセキュリティ、プライバシー、ユーザビリティ、信頼性、コンプライアンス上の便益を実現できるよう支援すること」と述べています。

OpenID Foundationは、NIST NCCoEプロジェクトに参加して報告書に貢献したことに加え、NISTおよび業界パートナーと複数の相互運用性イベントを共同開催してきたことも誇りに思っています。実際のデジタルウォレットや企業インフラに対して標準を検証することで、基盤となる仕様を成熟させ、相互運用性を実証し、実装における知識・仕様・セキュリティ・プライバシー・保証の不足点を特定しています。政府、金融、標準化、技術の各領域をまたぐ協働こそが、米国およびグローバルで、高保証のデジタルアイデンティティ資格情報を金融業界が採用する流れを前に進め、その安全性を確かなものにしていきます。

報告書に含まれるOpenID Foundation標準

NIST NCCoEが定義するアーキテクチャの中核には、フレームワークを支えるいくつかのプロトコルがあります。

• OpenID for Verifiable Presentation 1.0
• High Assurance Interoperability Profile 1.0
• OpenID Connect

これらの標準は、相互運用性イベントとNISTの技術評価を通じて検証されました。検証にあたっては、金融機関の口座オンボーディングに必要となる非同期プロセスを成立させるために、OpenID Connectが用いられました。

OpenID Foundationは、理事会および専門のコントリビューターの方針のもと、NIST NCCoEプロジェクトとSP 1800-42Aによって築かれた基盤を踏まえて取り組みを進めています。目的は、分野や法域に依存しない高保証のKYCプロセスを支えるために必要な、アイデンティティのclaimsとその値（Values）を定義することです。これはNCCoE参加者からのフィードバックとも直接一致しており、そこでは、発行者からRelying Parties（RPs）へ身元確認（Identity proofing）の保証レベルを伝達できるようにすることが、重要な要件として強調されていました。OpenID Identity Assurance Schema Definition 1.0およびOpenID Connect for Identity Assurance Claims Registration 1.0を拡張することで、このフレームワークは、顧客の本人性について、防御可能な「合理的な確信（Reasonable belief）」を確立する助けになります。

この新しい作業項目は、eKYC & IDA Working Groupで正式にホストされています。この取り組みには、Internet Identity Workshop（IIW）Conferenceにおいて他の標準開発組織と行った予備的な意見交換も取り込まれており、将来的にはISO/IEC SC17 WG10との整合も計画されています。個人、政府、組織の皆様には、このフレームワークを国際的に協力して厳しく検証し、正式な仕様として取りまとめるために、FoundationのeKYC & IDA WGへ参加することが強く推奨します。

参加はすべての方に開かれています。Contribution Agreementに署名すれば、費用負担なく誰でも貢献でき、また同意書により、より広いコミュニティの利益のために貢献が適切な法的保護の対象となることが確保されます。

グローバルでの重要性

OpenID FoundationのVice ChairであるDima Postnikov氏は次のように述べています。「世界的に、多くの金融機関、通信事業者、そして他の規制産業の企業が、ｍDLの受け入れ開始に向けた準備を進めています。これらの組織がこの文書に依拠して運用を始めるには、自らの義務に準拠していることを確実にするための追加情報が必要です。NISTによる本報告書と、eKYC working groupでの新しい作業項目は、mDLの採用に限らず、あらゆるcredential、そしてデジタルアイデンティティへの依拠一般にとって重要な成果です。」私たちは、他の法域でも同様の結論に急速に至っていると見ています。

eKYC and IDA WGの新しいwork itemについて4つの法域と初期協議を行った結果、各市場においてプロトコルが金融機関やその他の重要セクターをどのように支援できるか、またローカル目的と越境目的の双方を支え得るグローバルな標準アプローチをどのように推進できるかに、明確な関心があることが分かりました。

OpenID FoundationはSIDI Hubの共同主催者として、他の共同主催組織とともに、デジタルcredentialを用いた「open a bank account」というユースケースの重要性を確認しました。SIDI Hubは、4大陸で2年間に7回のサミットを開催し、45か国以上を招集しました。得られた知見の1つは、「opening a bank account」のような代表的ユースケースを実現するために、デジタルアイデンティティの国内および越境の相互運用性に対する強い需要がある一方で、世界の銀行が何を必要としているのか、そしてその情報をプロトコルのレベルでどのように伝えるのかが主要なつまずきになっていることでした。NISTの報告書と新しいOIDF work itemを組み合わせることで、前進するための道筋が示されます。

地域レベルでは、EUは2027年末までに、欧州のすべての金融機関がEU Digital Identity Wallets（EUDIW）からのVerifiable credentialsを受け入れられるようにし、地域的な相互運用性を実現しようとしています。そのため、この取り組みはEUの地域目標に照らして特に良いタイミングです。

デジタルウォレットとVerifiable digital credentialアーキテクチャを推進する法域にとって、Verifiable digital Credentialを用いる利点はますます明確になっています。こうした動きが進むにつれ、金融機関と消費者が、口座開設のような、より簡素で包摂的なユースケースから利益を得られることへの理解が広がるだけでなく、AIによるサイバー攻撃がもたらす新たな脅威を軽減できる可能性への認識も高まると私たちは見込んでいます。

2025年 - OpenID Foundationにとって語り継ぐべき一年

年月は、時によって静かに過ぎていきます。

しかし、OpenID Foundationにとって、2025年はそうした年ではありませんでした。

今年のOpenID Foundationコミュニティにおける進展の速度と規模は、実に目覚ましいものでした。

それがあまりにも顕著だったため、私たちは2025年の歩みをこの「Year in Review」レポートとしてまとめることにしました。

ここに記された物語を、私たちは心から誇りに思います。

2025年は、国際的な認知が新たな段階へ到達した年でした。

ITU（国際電気通信連合）が、OpenID Foundationの仕様を初めて国際標準として正式に採用したのです。

さらに3つの仕様ファミリーがISOの投票を通過し、ISO/IECのPAS（Publicly Available Specification）として認められました。

相互運用性が、目標から、繰り返し確認できる「証拠に基づく現実」へと移りました。

そしてOpenID Foundationの標準は、実証実験の域を出て各国の基盤へと本格的に組み込まれ、医療システムを守り、デジタルウォレットを実現し、世界中の数百万人の金融データを保護しています。

技術面の成果に加えて、2025年にはFoundationが、今日のデジタルアイデンティティにおける差し迫った課題について、議論をリードする立場として一段と踏み込みました。

具体的には、死後にデジタル資産やアカウントを社会としてどう扱うのか、また自律型AIエージェントをいかに安全に認証し、統制と運用（ガバナンス）を行うのか、といった論点です。

これらは政府、企業、市民が今後数年にわたり向き合う必要のある課題であり、私たちはその議論の形成に貢献できていることを誇りに思います。

今後に目を向けると、勢いはすでに増しています。

数十の政府やエコシステムの運営主体が、デジタルウォレットおよびVerifiable Credentials関連プログラムの基盤として、OpenID Foundationの標準を採用しました。

これにより、2026年以降、何千万人もの人々が日常のサービスでこれらの仕様を利用するための土台が整いました。

メンバー、貢献者、パートナーからなる私たちのコミュニティは、これまでになく強固で、関与も活発です。

2025年が示すとおりであれば、2026年もまた記録に残す価値のある一年になるでしょう。

完全版レポートはこちらからお読みください：OIDF_2025_Year_in_Review

AuthZEN：「これは何？」から「どう実装すればいい？」へ

AuthZENワーキンググループが、3月初に行ったGartner IAM Londonのハイライトを共有します。実務家の質問から見えてきた、企業の準備状況も取り上げます。

今月初めに開催されたGartner IAM Londonには、エンタープライズIAM（アイデンティティおよびアクセス管理）の実務家、アナリスト、標準化団体が集まりました。OpenID FoundationのAuthZENワーキンググループにとって、この数日間は多くの気づきがある時間でした。共同議長のAtul Tulshibagwale氏、Alex Olivier氏、David Brossard氏が出席し、2つのセッションに参加しました。どちらも聴衆の関心は高く、示された結論は同じでした。認可は、企業の重要課題として確実に位置づけられています。

最初のセッションでは、Atul Tulshibagwale氏がGartnerのアナリストErik Wahlström氏とともに、アイデンティティ標準が企業の「将来にわたって通用する」IAMアーキテクチャづくりにどう役立つかを取り上げました。この議論は、イベント全体を通じて繰り返し語られたテーマを改めて裏づけるものでした。標準はもはや「Nice-to-have」なものではありません。アイデンティティの仕組み全体を成り立たせ、つなぎ合わせるための要となるものです。

2つ目のセッションでは、Alex Olivier氏（Alex氏の詳細はこちら）とDavid Brossard氏（David氏の詳細はこちら）が、GartnerのアナリストHoman Farahmand氏とともに、AuthZENを前面に押し出して紹介しました。ワーキンググループは仕様の最新状況を共有し、最新の相互運用性の結果もデモで示しました。チームが最も印象的だったのは、会場の空気の変化です。1年前の質問は「これは何？」でした。今回は「どう実装すればいいのですか？」でした。これは大きな変化です。実務家はもはや、AuthZENが注目に値するかどうかを検討しているのではありません。本番環境に適用する方法を具体的に考え始めています。

イベントにおけるこの標準の存在感は、2つのセッションにとどまりませんでした。3人のGartnerアナリストが、それぞれ別のセッションで、誰かに促されたわけでもなくAuthZENに言及しました。これは、アナリスト・コミュニティがAuthZENを「追うべき標準」と見なしている明確なサインです。

また、認可をめぐる会話からは、より広い意味での切迫感も見て取れました。参加者からは、たとえば次のような趣旨の質問が出ていました。「人間に対する認可ですらまだ十分に整っていないのに、エージェントに対する認可をどう実現するのか？」多くの企業チームが身に覚えのある葛藤を端的に表しています。だからこそ、認可を外部化し、標準にもとづいて整備することは、単なるベストプラクティスにとどまりません。

AuthZENワーキンググループ共同議長のDavid Brossard氏は、次のように述べています。
「Gartner IAM Londonでの会話は、私たちがしばらく前から目にしてきた状況を改めて確認するものでした。企業は認可に本格的に取り組む準備ができています。そしてAuthZENは、そのための標準を提供します。」