WebAuthnクレデンシャル交換プロトコル（CXP）とフォーマット（CXF）

パスキーは、従来のパスワードに代わる安全でフィッシング耐性のある選択肢として、オンライン認証のゴールドスタンダードになりつつあります。FIDOアライアンスが支援するパスキーは、WebAuthnおよびFIDO2標準に基づいており、公開鍵暗号方式を使用してクレデンシャル盗難のリスクを排除します。

しかし、普及が加速するにつれて、重要な課題が浮上してきました。それは、異なるプロバイダー間でパスキーをどのようにインポートまたはエクスポートするかという問題です。例えば、Bitwardenから1Passwordへ、あるいはAppleのiCloudキーチェーンからGoogleパスワードマネージャーへ、といったケースです。

パスワードとは異なり、パスキーには簡単にエクスポートやインポートができるフォーマットがありません。この相互運用性の欠如は、ユーザーにとって不便であり、ベンダーロックインのリスクを高めます。

そこで登場するのが、2つの新しい標準です。

• クレデンシャル交換プロトコル（CXP）：プロバイダー間でパスキーを転送するための安全なメカニズムを定義します。

• クレデンシャル交換フォーマット（CXF）：パスキー、クレジットカード情報、TOTPコードなど、クレデンシャル自体の標準化されたデータフォーマットを定義します。

CXPとCXFは、パスキーのポータビリティを可能にするだけでなく、安全で柔軟、かつユーザーフレンドリーなものにするために設計されています。この記事では、以下の疑問に答えていきます。

1. クレデンシャル交換プロトコル（CXP）とは何か、どのように機能するのか？

2. クレデンシャル交換フォーマット（CXF）とは何か、どのような形式なのか？

3. クレデンシャル交換プロトコルとクレデンシャル交換フォーマットの開発の現状は？

より多くのユーザーや組織がパスキーを採用する中で、1つの重大な課題が残っています。それはプラットフォーム間でクレデンシャルを移動させることです。パスワードは（安全とは言えませんが）単純なテキストやCSVファイルとしてエクスポートできますが、パスキーは暗号化されたキーペアに依存しています。そのため、インポート/エクスポートははるかに複雑で、機密性の高いものになります。

現在、パスキー移行において壊れている点は以下の通りです。

• 標準フォーマットの不在：パスワードのCSVとは異なり、パスキーには普遍的な表現方法がありません。各プロバイダーは異なる方法で保存しています。

• 安全でない転送：移行をサポートしようとする稀な試みでは、クレデンシャルが暗号化されていない形式でエクスポートされ、深刻なセキュリティリスクを生み出しています（このGitHubの議論を参照）。

• 移行の失敗：一貫した構造がないため、プロバイダー間でパスキーを移行すると失敗し、クレデンシャルが失われたり、ユーザーがパスキーを再作成せざるを得なくなったりする可能性があります。

• ポリシーによるブロック：企業環境では、安全でない転送や互換性の問題を懸念して、クレデンシャルのエクスポートが完全に無効にされる可能性があります。

• ベンダーロックイン：パスキーを確実にエクスポートする方法がなければ、ユーザーは現在のプロバイダーにロックインされてしまいます。これはユーザーの自由と競争を損なうものです。

この問題は仮説ではなく、現実に起こっています。人々が複数のデバイス、ブラウザ、アプリを使ってパスキーを管理するようになると、あるエコシステムからパスキーをインポートし、別のエコシステムへパスキーをエクスポートする必要性が急務となっています。

だからこそ、1Password、Dashlane、Bitwarden、NordPassといった主要企業が2023年初頭に協力し、解決策のプロトタイプを作成しました。その結果、安全なクレデンシャル交換のためのオープンスタンダード、すなわち**クレデンシャル交換プロトコル（CXP）とクレデンシャル交換フォーマット（CXF）**を定義するための共同作業が生まれました。

パスキー移行の課題に対処するため、2つの補完的な標準が登場しました。それがクレデンシャル交換プロトコル（CXP）とクレデンシャル交換フォーマット（CXF）です。Apple、Google、Microsoft、1Passwordなどの業界リーダーに支持され、これらの仕様はパスキーのインポートとエクスポートを安全で、標準化され、相互運用可能なものにすることを目指しています。

**クレデンシャル交換プロトコル（CXP）は、2つのクレデンシャル/パスキープロバイダー間でクレデンシャルを転送するための安全な方法を定義する仕様です。現在、FIDOアライアンス内で作業草案（Working Draft）**の段階にあり、設計はまだ進化の途中ですが、クレデンシャルを*送信者（Sender）*からエクスポートし、*受信者（Recipient）*にインポートするための標準化された安全なチャネルを確立することを目指しています。

詳細はまだ最終決定されていませんが、このプロトコルは**ハイブリッド公開鍵暗号（HPKE）**を使用して、転送中のクレデンシャルがエンドツーエンドで暗号化されることを保証すると期待されています。この堅牢な暗号基盤により、機密データが傍受されたり改ざんされたりするのを防ぎます。

CXPは、特にパスワードマネージャーのようなサードパーティプロバイダーが、例えばブラウザ拡張機能間など、異なるプラットフォーム間でクレデンシャル交換を促進するために重要になると考えられています。これらのシナリオでは、標準化された非常に安全な転送プロトコルが不可欠です。まだ初期の草案段階にあるため、最終的な形式や標準化のタイムラインは不確定ですが、2026年初頭と見積もられています。

**クレデンシャル交換フォーマット（CXF）**は、交換のためにクレデンシャル自体がどのように構成されるかを定義します。現在、**レビュー草案（Review Draft）**のステータスにあり、標準として最終決定される間近です。

安全な転送を扱うCXPとは異なり、CXFはデータフォーマットのみに焦点を当てています。これは、さまざまな種類のクレデンシャルに対して標準的なJSONベースの構造を規定し、あるプロバイダーからエクスポートされたクレデンシャルが別のプロバイダーで正しく理解されることを保証します。

CXFは以下のタイプを定義しています：

• パスキー (public-key-credential)
• パスワード (password)
• TOTPシークレット (totp)
• メモ (note)

この標準化された語彙が、相互運用性の鍵となります。例えば、AppleとGoogleはすでに、同じデバイス上のネイティブアプリ間でクレデンシャルを転送するためにCXFを使用しています。転送はローカルで行われるため、CXPのような専用の転送プロトコルは必要ありません。

構造を標準化することで、CXFは移行時のフォーマットの不一致や部分的なデータ損失といった問題を解消します。また、設計上拡張可能であり、将来のバージョンで下位互換性を損なうことなく新しいクレデンシャルタイプを追加できます。

2024年後半現在、**クレデンシャル交換プロトコル（CXP）とクレデンシャル交換フォーマット（CXF）**はそれぞれ異なる成熟段階に達しており、業界からの強い支持を得ています。

CXPとCXFの開発はFIDOアライアンスを通じて調整されており、Apple、Google、Microsoft、1Password、Bitwarden、Dashlaneなどの主要企業が積極的に貢献しています。

この広範な協力は、パスキーのポータビリティを実現するという共通のコミットメントを示しています。実際、いくつかの企業はすでに草案に基づいたソリューションを実装しています。

• AppleとGoogleは、同じデバイスでのアプリ間クレデンシャル転送にCXFを使用する予定です。
• サードパーティのパスワードマネージャーは、安全なクロスプラットフォーム交換に備えるため、CXPの初期草案に基づいたプロトタイプを構築しています。

2つの仕様は、異なるタイムラインで進んでいます。

• クレデンシャル交換フォーマット（CXF）はレビュー草案の段階です。2024年末までに正式な標準として最終決定される見込みです。
• クレデンシャル交換プロトコル（CXP）は作業草案です。標準化への道のりはより長く、クロスプラットフォームでの使用事例に対して堅牢かつ安全であることを保証するためにコミュニティからのフィードバックが統合されるため、2026年初頭にリリースされる可能性があります。

仕様の草案はFIDOアライアンスのウェブサイトで公開されており、最終決定前に仕様を洗練させるため、開発者からのフィードバックが積極的に奨励されています。

早期の実験や実装計画をサポートするために、パスキーエコシステムには現在、以下のものが含まれています。

• Passkeys Debugger：WebAuthnリクエストを分かりやすくデバッグするのに役立つプラットフォーム。

• Passkey Community：ソフトウェア開発者やプロダクトマネージャーがパスキー関連の質問について議論するコミュニティ。

• Passkey Subreddit：CXPやCXFに関する情報を含む、パスキーやWebAuthnに関するニュースを議論するための専門サブレディット。

• passkeys.eu：開発者がWebAuthnフローとパスキーの動作を検証するためのテストツール。

• CXP GitHub Draft：プロトコルのメッセージ構造と暗号フローの全体像。

• CXF GitHub Draft：ZIPファイルのレイアウトとクレデンシャルのパッケージングフォーマット。

まだ完全に標準化されてはいませんが、CXPとCXFは明らかに、パスキーパズルの最後の欠けていたピースになる軌道に乗っており、ユーザーと組織双方にとって安全でシームレスなインポート/エクスポートを可能にします。

**クレデンシャル交換プロトコル（CXP）とクレデンシャル交換フォーマット（CXF）**は、パスキーのインポートとエクスポートを安全かつシームレスにするというニーズから生まれました。しかし、その可能性はそれだけにとどまりません。

これらの標準は、あらゆる機密クレデンシャルをプロバイダー間で、安全に、確実に、そしてプラットフォームを越えて転送するための青写真となります。これは、アイデンティティ、認証、さらには政府発行のクレデンシャルといった、より広範なユースケースへの扉を開きます。

現在のパスキー導入における最大の懸念事項の1つは、ベンダーロックインです。クレデンシャルを安全に移動させる方法がなければ、ユーザーはニーズが変わったとしても、元のプロバイダーに縛られてしまうことがよくあります。

CXPとCXFにより、私たちは真に相互運用可能なパスキーエコシステムへと向かっています。そこでは、ユーザーと企業が以下のことを行えるようになります。

• プロバイダー間で自由にパスキーを移行する

• クレデンシャルの重複作成を避ける

• デバイスやプラットフォームの移行を簡素化する

これは消費者の選択を直接サポートし、競争を促進し、パスキーモデルへの信頼を強化します。

GoogleのアイデンティティおよびセキュリティグループのプロダクトマネージャーであるChristiaan Brand氏は次のように述べています。

「将来的には、これはモバイル運転免許証やパスポートなど、どこかにエクスポートして別のシステムにインポートしたいあらゆる秘密情報に適用できる可能性があります。」

以下のものを安全に転送することを想像してみてください。

• パスキー (public-key-credential)

• TOTPシークレット (totp)

• 支払い情報 (credit-card)

• 政府発行のID (identity-document)

これらすべてを、同じ標準化された交換メカニズムを通じて行う。それがCXPとCXFが形作ろうとしている未来です。

暗号化された検証可能なクレデンシャル交換が標準となることで、組織はついに安全でないCSVエクスポートを廃止し、エラーの起こりやすい手動プロセスを避け、すべてのクレデンシャル処理に対して暗号化第一のポリシーを強制できるようになります。

消費者向け、企業IT、または公共セクターのアイデンティティシステムのいずれにおいても、この変化は使いやすさを損なうことなく、デフォルトのセキュリティ基準を引き上げます。

クレデンシャル交換プロトコル（CXP）とクレデンシャル交換フォーマット（CXF）は、パスキーエコシステムにおける重要な進化を表しています。クレデンシャル移行における長年のギャップに対処することで、これらは異なるプラットフォームやプロバイダー間でパスキーをインポートおよびエクスポートするための、安全で標準化されたフレームワークを提供します。CXFが「何を」（データフォーマット）を標準化し、CXPが「どのように」（安全な転送）を標準化することで、両者は真のパスキーポータビリティへの道を切り開きます。

業界リーダーからの幅広い支持とFIDOコミュニティでの勢いの高まりにより、これらの仕様はパスキー導入における最後の大きな障壁の一つであるポータビリティを取り除く準備が整っています。

今日、パスキーベースのシステムを構築している開発者や組織にとって、CXPとCXFの動向を把握することは、将来に備えるだけでなく、より良いユーザーエクスペリエンス、より強固なセキュリティ、そしてより大きな柔軟性を実現することにつながります。

Corbadoでは、これらの動向を注意深く追い、企業がベンダーロックイン、ユーザー移行の頭痛の種、セキュリティの妥協なしに、大規模なパスキー導入を実現できるよう支援しています。エコシステムが成熟するにつれて、私たちは安全なクレデンシャル交換を現実のものとするため、CXP/CXFベースのフローをいち早くサポートしていきます。

パスキーはすでにここにあります。CXPとCXFは、そのパスキーをあらゆる場所へ届ける手助けとなるでしょう。