日程確保を『OpenID Foundation グローバルカンファレンス 2027』

OpenID Foundation（OIDF）は、初開催となるグローバルカンファレンスの開催日程を発表できることを嬉しく思います。本カンファレンスでは、デジタル・アイデンティティのエコシステム全体から、リーダー、イノベーター、意思決定者が一堂に会します。

目的は、エコシステム同士をつなぎ、ベストプラクティスを共有し、グローバルな相互運用性を加速させることです。

• メインカンファレンス: 2027年2月2日（火）
• ワーキンググループおよびサイドイベント: 2027年2月3日（水）から4日（木）
• 会場: etc.venues County Hall（ロンドン）

インパクトを生む新しい形式

2027年のカンファレンスでは、戦略的な示唆、実務的な協働、コミュニティの交流のバランスをとるため、3日間の構成をより洗練させて提供します。

• 1日目（2月2日）: メインカンファレンス
  厳選された専門家主導のコンテンツ、グローバルな視点、思想的リーダーシップを盛り込んだ、制作品質の高いプレナリー中心のプログラムです。
• 2日目および3日目（2月3日から4日）: ワーキングセッションとコミュニティ協働
  ワーキンググループ会合、相互運用性セッション、デモ、協働ディスカッションに特化し、現実世界での実装と前進を加速させる設計です。

この構成により、イベント期間中に最大で11以上のワーキンググループ・セッションを実施でき、戦略的議論と並行して実質的な成果を生み出すことを目指します。

期待できる内容

2027年のプログラムは、現在のデジタル・アイデンティティを形づくる重要テーマに焦点を当てます。例として、以下を扱います。

• セキュリティ、信頼、標準
• デジタル・アイデンティティとグローバルな相互運用性
• エコシステムの発展とガバナンス
• 実装、普及、現実のユースケース

参加者は、厳選されたコンテンツ、実務に直結する示唆、現場の経験にもとづく知見の共有を通じて、エコシステム横断での導入と普及を加速するためのヒントを得られます。

象徴的なロンドンの会場

2027年カンファレンスは、ロンドン屈指の象徴的かつ歴史的な場所である etc.venues County Hall で開催されます。

メインカンファレンスはサウスバンク・ウィング（3階）で実施されます。County Hallは、1980年代後半まで60年以上にわたりロンドンの地方行政の本部として使用されていた建物であり、その中でも印象的な空間が会場となります。

2日目と3日目は4階へ移動し、ワーキンググループ会合、協働セッション、エコシステム主導の各種アクティビティのための専用スペースを提供します。

この特別な環境は、デジタル・アイデンティティ分野の世界的リーダーを結集するのに最適な舞台です。歴史、規模、そして現代的なカンファレンス設備を兼ね備えています。

参加対象

本カンファレンスは、技術専門家に加え、オープンファイナンス、オープンヘルス、デジタル・アイデンティティネットワーク、公共部門の取り組みなど、大規模なアイデンティティおよびデータ・エコシステムを推進する実務家が集う場です。さらに、開発機関や標準化団体などのグローバルパートナーも参加します。

想定参加者は以下のとおりです。

• エコシステムのリーダーおよび意思決定者
• アーキテクト、政策リーダー、ビジネス関係者
• 政府、規制当局、国際機関
• テクノロジープロバイダーおよび関連パートナー
• これらのユースケースを支える技術標準やプロトコルを推進するOIDFコミュニティのメンバー

日程のご案内（日程確保してください）

政策を形づくる立場の方、基盤を構築する方、アイデンティティ・ソリューションを展開する方など、将来のアイデンティティ・エコシステムに本気で取り組むすべての方にとって、必見のイベントです。

• 会場: etc.venues County Hall, Belvedere Rd, London SE1 7PB, UK
• メインデー: 2027年2月2日
• ワーキングセッション: 2027年2月3日から4日

詳細は近日公開

参加登録、会場、スポンサー機会、全プログラムに関する追加情報は、今後数か月のうちに順次公開します。

それまでの間、ぜひ日程を確保のうえ、ロンドンで開催される OIDF 2027 にご参加ください。

会員の皆さまへ - GDCカンファレンスの参加登録を今すぐ

OpenID Foundationは、スイス ジュネーブのPalexpoで今年9月1日から3日に開催される Global Digital Collaboration (GDC) Conference の共同主催者を務めることをお知らせします。

GDCは、一般的な業界カンファレンスではありません。標準化団体、政府間機関、オープンソース財団、NGOからなる連合が、明確な目的のもとに結集して開催するものです。その目的は、デジタルアイデンティティ、クレデンシャル、ウォレットに関わる、国や地域の制度をまたぐ複雑な課題に取り組むことです。これらは、単一の組織だけでは解決できません。

OpenID Foundationの会員は、3日間すべてのプログラムに参加できる無料チケットを登録できます。チケットには限りがあるため、Foundationでは、特にカンファレンスの議題に関連の深い活動をされている会員の皆さまに、早めの登録をおすすめしています。

OIDF会員が参加すべき理由

GDCの議題は、クレデンシャルのフォーマット、ウォレットのアーキテクチャ、認証、フェデレーション、越境時における相互運用性、プライバシー、セキュリティ、AIなどを扱います。これらは、OpenID Foundationのワーキンググループが現在まさに策定を進めている領域と重なります。

参加団体には、W3C、ISO、Linux Foundation、OpenWallet Foundation、UNDP、世界銀行などが含まれます。これらの関係者と一か所で出会える貴重な機会です。

GDCのワーキングセッションは、イベント当日後も続く具体的な成果を生み出すことを目的として設計されています。これには、継続的に活動するCollaboration Groupの立ち上げも含まれます。

OpenID Foundationが共同主催者であることにより、会員の皆さま、ワーキンググループの成果物、そして策定中のOpenID Foundation標準が、ジュネーブで生まれる成果の方向性を形づくる要素となります。

OpenID Foundation事務局長のGail Hodgesは、次のように述べています。
「このカンファレンスは他にないユニークなイベントであり、OIDFの技術的取り組みを、より広い国際的な政策議論と実装の議論へと接続する貴重な機会です。政府や多国間機関と直接対話し、グローバルなデジタル基盤の方向性をともに定める一助となります。」

なお、個別の登壇者と別途合意がない限り、全体を通してチャタムハウス・ルールが適用されます。

参加登録、ならびにイベントや議題の詳細は、以下をご覧ください。
GDC 2026 Tickets via OpenID Foundation · Luma

進化する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によるサイバー攻撃がもたらす新たな脅威を軽減できる可能性への認識も高まると私たちは見込んでいます。