EMV 3DS ACSベンダーの現状を解説。フリクションレス決済のためのパスキーとFIDOデータ活用、そして安全なチャレンジ決済を実現するSPCへの対応状況について学びましょう。
Want to learn how top banks deploy passkeys? Get our 80-page Banking Passkeys Report (incl. ROI insights). Trusted by JPMC, UBS & QNB.
Get Report
1. はじめに#
オンライン決済における認証の世界は、大きな変革の時期を迎えています。この変革は、巧妙化する不正行為に対するセキュリティ強化と、フリクション(手間)やカート離脱を減らすためのユーザー体験向上という、2つのニーズによって推進されています。
EMV® 3-Dセキュア(3DS)プロトコル、特にその新しいバージョン(EMV 3DS
2.x)は、世界中のカード非提示(CNP)取引を認証するための基盤技術として機能しています。EMVCoによって管理されるこのプロトコルは、マーチャント(加盟店)、イシュアー(カード発行会社、そのアクセス・コントロール・サーバー(ACS)経由)、そして相互運用ドメイン(決済スキームが運営するディレクトリサーバー)間のデータ交換を円滑にし、カード会員の本人確認を行います。
この枠組みの中で、FIDO(Fast Identity
Online)アライアンスの標準に関連する2つの重要な技術的進歩が登場しています。
- ユーザーが以前に行った操作(例:マーチャントへのログイン)で生成されたFIDO認証データを活用し、EMV
3DSのフリクションレスフローにおけるリスク評価を強化する。
- FIDO/WebAuthnを基盤に構築されたW3Cのウェブ標準であるセキュア・ペイメント・コンファメーション(SPC)を、EMV
3DSフロー内の効率的でフィッシング耐性のある「チャレンジ」手法として統合する。
この記事では、カード発行銀行に提供されるEMV
3DSアクセス・コントロール・サーバー(ACS)ソリューションのグローバル市場の概要を解説します。主要なベンダーを特定し、非SPCのFIDOデータ構造と、チャレンジフローのためのセキュア・ペイメント・コンファメーション(SPC)の両方に対する現在のサポート状況を評価します。さらに、イシュアーがSPCを介して3DSチャレンジフロー内で自社のFIDOパスキーを暗号学的に検証する仕組みを明らかにし、この標準のグローバルな適用性について議論します。
2. EMV 3DS、FIDO、SPCの概要#
2.1 EMV 3DSにおけるフリクションレスフローとチャレンジフロー#
EMV 3DSは、主に2つの異なる認証経路で動作します。
- フリクションレスフロー:
これは、シームレスなユーザー体験を目指す、望ましい経路です。イシュアーのACSは、取引開始時に交換される豊富なデータセット(認証リクエスト、AReqメッセージ経由)に基づいてリスク評価を行います。このデータには、取引詳細、マーチャント情報、デバイス特性、ブラウザデータ(3DSMethodのJavaScriptを介して収集される可能性あり)、そして以前の認証情報などが含まれます。リスクが低いと判断された場合、カード会員からの直接的な操作や「チャレンジ」を要求することなく、取引は認証されます。このフローは、特にリスクエンジンが適切に調整されている場合、3DS取引の大部分を占めます。
- チャレンジフロー:
ACSが取引リスクが高いと判断した場合、または規制(ヨーロッパのPSD2
SCAなど)やイシュアーのポリシーによって義務付けられている場合、カード会員は本人確認のために能動的なチャレンジを求められます。従来のチャレンジ方法には、SMSで送信されるワンタイムパスコード(OTP)、知識ベースの質問、または銀行アプリを介したアウトオブバンド(OOB)認証などがあります。新しい3DSバージョンやSPCのような関連技術の目標は、このチャレンジフローを従来の方式よりも安全で、手間のかからないものにすることです。
2.2 フリクションレスフロー強化におけるFIDOデータ(非SPC)の役割#
EMVCoとFIDOアライアンスは協力して、マーチャントが以前のFIDO認証(この場合、マーチャントがリライング・パーティとして機能。例:ユーザーログイン時)に関する情報を、標準の3DS
AReqメッセージ内でイシュアーのACSに渡すための標準化された方法を定義しました。この仕組みは、EMV
3DS
v2.1で初めてサポートされ、AReq内の特定のフィールド、主にthreeDSRequestorAuthenticationInfo
構造体とそのサブフィールド(threeDSRequestorAuthenticationData
など)を活用します。
FIDOアライアンスの技術ノートと関連するEMVCoのホワイトペーパーでは、以前のFIDO認証の詳細を伝える際に、このthreeDSRequestorAuthenticationData
フィールドに含めるJSON構造が規定されています。このJSONオブジェクトには、認証時刻(authTime
)、FIDOリライング・パーティID(rpId
またはappId
)、そして使用された認証器に関する情報(公開鍵、AAGUID/AAID、ユーザープレゼンス(UP)およびユーザーベリフィケーション(UV)のインジケータなど)が含まれます。
この背景にある考え方は、もしマーチャントが購入を開始したユーザーセッションに対して最近強力なFIDO認証(生体認証やパスキーなど)を実行した場合、この情報がイシュアーのACSにとって価値ある追加のリスクシグナルとして機能するというものです。この標準化されたFIDOデータを受信し処理することで、ACSは取引の正当性に対する信頼度を高め、フリクションレスでの承認の可能性を高め、別途チャレンジを要求する必要性を減らすことができます。このシナリオでは、マーチャントがFIDO
RPであり、イシュアーはこのデータをリスクエンジンの入力として消費することに注意が必要です。イシュアーは、このフリクションレスフロー内でFIDOアサーション自体を暗号学的に検証するわけではありません。ACSは、このデータを処理するように設定されていない場合、無視する選択肢を保持します。
2.3 チャレンジフローにおけるセキュア・ペイメント・コンファメーションの役割#
セキュア・ペイメント・コンファメーション(SPC)は、EMV
3DSのチャレンジフロー内におけるFIDO標準の明確な統合を表します。SPCは、FIDOおよびEMVCoとの協力のもとで開発されたW3Cのウェブ標準であり、WebAuthnを基盤としています。EMV
3DSではバージョン2.3から正式にサポートされています。
SPCがチャレンジ方法として使用される場合:
- イシュアー(またはイシュアーによって明示的に委任された当事者、例えば決済スキーム)が**FIDOリライング・パーティ(RP)**として機能します。これは、マーチャントが自身のログイン/認証目的でRPとして機能する、前述の非SPCのFIDOデータフローとは根本的に異なります。
- 3DSチャレンジ中、ACSはSPCの必要性を示し、必要なFIDOクレデンシャル識別子と暗号学的チャレンジをマーチャント/3DSサーバーに提供します。
- マーチャントのシステムはブラウザのSPC
APIを呼び出し、取引詳細(金額、通貨、受取人、支払い手段)をブラウザが制御する安全なダイアログでユーザーに提示します。
- ユーザーは自身のFIDO認証器(例:デバイスの生体認証、PIN、セキュリティキー)を使用して認証します。これにより、イシュアーに登録されたパスキーに関連付けられた秘密鍵を使用して、取引詳細とチャレンジが署名されます。
- 結果として得られるFIDOアサーション(認証と同意の暗号学的証明)は、3DSプロトコルを通じて(通常は2回目のAReqメッセージで)イシュアーのACSに返送されます。
- RPであるACSは、対応する公開鍵を使用してアサーションを暗号学的に検証し、カード会員の本人確認と特定の取引詳細への同意を確認します。
SPCは、従来の方式と比較して、より安全(フィッシング耐性、認証と取引データの動的リンク)で、かつフリクションが少ない(多くの場合、OTP入力よりも速い)チャレンジ体験を提供することを目指しています。
FIDO統合のための2つの経路(1つはフリクションレスのリスク評価のために以前のマーチャント認証データを活用し、もう1つはSPCを介した直接的なFIDOベースのチャレンジのためにイシュアー管理のクレデンシャルを使用する)は、EMV
3DSフレームワーク内でセキュリティとユーザー体験を向上させるための異なるアプローチを提供します。それぞれのベンダーサポートを理解することは、認証戦略を計画するイシュアーやPSPにとって極めて重要です。
3. 主要なEMV 3DS ACSベンダーの分析#
このセクションでは、EMV
3DS ACSソリューションのグローバルプロバイダーの能力を分析し、その市場での存在感と、FIDOデータ(非SPC)およびセキュア・ペイメント・コンファメーション(SPC)へのサポートに焦点を当てます。正確な市場シェアの数値は非公開であり、公に入手することが困難なため、存在感はベンダーの主張、認証、パートナーシップ、地理的範囲、市場レポートに基づいて評価します。
3.1 Entersekt(Modirumを統合)3DS ACS#
- 市場での存在感:
Entersektは、特に2023年12月のModirumの3DSソフトウェア事業買収後、EMV
3DSソリューションの主要なグローバルプロバイダーとしての地位を確立し、市場トップ5を目指しています。Modirumは3DS分野で20年以上の経験を持っていました。Entersektは、特に北米での新規クライアントや、Mastercardとの関係拡大を含む戦略的パートナーシップによって記録的な成長を遂げたと強調しています。年間25億件以上の取引を保護していると主張し(24年度時点)、Liminalによって銀行業務におけるATO(アカウント乗っ取り)防止で第1位にランクされています。同社のACSは、ホスト型(Entersektまたはクライアントによる)またはオンプレミスで利用可能です。世界中のイシュアーやプロセッサーにサービスを提供しています。
- 非SPC FIDOデータサポート(フリクションレス): Entersektは、Context Aware™
Authentication、リスクシグナルのためのデバイスおよび行動分析、さまざまなリスクスコアリングサービスとの統合を強調しています。同社のACSはFIDO
EMVCo
2.2の認証を受けています。フリクションレスフロー強化のために、以前のマーチャント認証からの
threeDSRequestorAuthenticationInfo
フィールド内の標準化されたFIDO構成証明データを処理することについては、オンライン資料で明確に述べられていません。しかし、高度な認証とリスクシグナルに注力していることから、その能力が示唆されます。
- SPCサポート(チャレンジ):
EntersektがSPCをサポートしていることを強く示唆する兆候があります。Entersektが買収したModirumは、VisaのSPCパイロットに拡張機能付きの3DS
2.2を使用してコンポーネントを提供していました。Entersektは、規制遵守能力の一環としてSPCコンプライアンスのサポートを明示的にリストアップしています。同社のACSは生体認証をサポートし、EMV
3DS
2.2の認証を受けており、Modirumのパイロット参加から得た能力を組み込んでいる可能性が高いです。Modirumの買収、SPCコンプライアンスへの明確な言及、FIDO認証の組み合わせは、現在の製品でSPCをサポートしていることを強く示しています。
- 市場での存在感:
BroadcomのArcotは、Visaと共同で元のプロトコルを発明した、3DS市場の創設的なプレーヤーです。世界中の5,000以上の金融機関にサービスを提供し、229カ国からの取引を処理する、世界的に認められたリーダーとして自らを位置づけています。彼らのArcot
Networkは、広大なコンソーシアムデータアプローチ(6億以上のデバイス署名、150兆のデータポイントを主張)を強調し、不正スコアリングとリスクエンジンを強化しています。ヨーロッパ、オーストラリア、北米で強い存在感を持っています。
- 非SPC FIDOデータサポート(フリクションレス):
Broadcomは、データネットワークの豊富さと、不正検出およびリスクベース評価のためのAI/ニューラルネットワークの使用を非常に重視しており、標準のEMV
3DSデータ要素を超えています。彼らのソリューションは、複数のイシュアーを流れるデータを活用し、デバイスや地理位置情報などのデジタルデータを取り入れていると明言しています。
threeDSRequestorAuthenticationData
からの特定のFIDO
JSON構造を処理することについては明示的に言及していませんが、RBAのために多様なデータポイントを取り込むことに注力していることから、提供されればそのようなデータを消費できる可能性が強く示唆され、EMVCo/FIDOガイダンスの意図と一致します。彼らのプラットフォームは、優れたリスク評価を通じてフリクションレス承認を最大化することを目指しています。
- SPCサポート(チャレンジ): Broadcomのドキュメントは、より広範なVIP Authentication
Hub / Identity
Securityスイート内でFIDO認証器(セキュリティキー、生体認証、パスキー)をサポートしていることを確認しています。彼らの3DS ACSは、OTPやプッシュ通知を含むさまざまなチャレンジ方法をサポートしており、生体認証のサポートにも言及しています。また、Delegated Authentication(委任認証)機能を提供し、チャレンジ後のリスク評価機能を導入しています。しかし、彼らのEMV
3DS ACS製品が現在、特定のチャレンジ方法としてSPC(EMV 3DS
v2.3+の機能と2つのAReqフローが必要)をサポートしているという明確な確認は、提供されたドキュメントにはありません。彼らはそれを実装する能力を持つ主要プレーヤーである可能性が高いですが、現在の公開資料は、RBAエンジンと従来の/OOBチャレンジ方法に重点を置いています。
3.3 Netcetera 3DS ACS#
- 市場での存在感:
Netceteraは、特にヨーロッパと中東で強力な、国際的な決済プレーヤーとして自らを位置づけています。彼らのACSは800以上の銀行/イシュアーによって使用され、世界中で5,000万枚以上のカードを保護していると述べています。すべての主要なカードネットワーク(Visa、Mastercard、Amex、Discover、JCB、UnionPayなど)での認証とPCIコンプライアンスを強調しています。彼らは、世界で初めてEMV
3DS 2.3.1認証を達成したACSベンダーとして注目されました。
- 非SPC FIDOデータサポート(フリクションレス):
Netceteraのドキュメントは、フリクションレス認証を増やすために、ACSのリスク評価のために3DSMethodを介して収集されたデータの重要性を強調しています。彼らはリスクツールとの統合を提供しています。しかし、リスク評価のために以前のマーチャントFIDO認証データ(
threeDSRequestorAuthenticationInfo
から)を処理することについての具体的な確認は、レビューした資料では明示的に言及されていません。
- SPCサポート(チャレンジ):
NetceteraはSPCに対する強力なサポートを示しています。彼らは、SPCを組み込んだバージョンであるEMV
3DS
2.3.1の認証を世界で初めて受けたベンダーです。彼らはVisaのSPCパイロットに参加し、v2.3.1のコンポーネントを提供しました。彼らの製品ドキュメントはSPCを明確に定義しています。彼らはFIDOとSPCの統合について議論するウェビナーを実施し、SPCの利点を強調する記事を公開しています。この認証、パイロット参加、明確なドキュメントの組み合わせは、彼らがSPCチャレンジをサポートしていることを確認するものです。
3.4 Worldline 3DS ACS#
- 市場での存在感:
Worldlineは、決済および取引サービスのヨーロッパのリーダーであり、主要なグローバルプレーヤー(世界第4位の決済プレーヤーと主張)として自らを位置づけています。年間数十億の取引を処理し、保証されたコンプライアンス、AI/MLを使用した不正管理、およびスケーラビリティを強調しています。彼らのACSはEMV
3DS認証済みで、主要なスキーム(Visa Secure、Mastercard Identity Check)およびPSD2に準拠していると述べられています。100以上のイシュアーのために年間24億件以上の3DS取引を処理していると報告しています。
- 非SPC FIDOデータサポート(フリクションレス):
WorldlineのACS製品には、イシュアーがリスクに基づいてフリクションレスまたはチャレンジフローを設定できるRBAルールエンジンが含まれています。彼らのより広範な「Trusted
Authentication」ソリューションは、デバイスインテリジェンスと行動分析を活用しています。彼らは一般的にFIDOをサポートしていますが、リスク評価のためにACS内で以前のマーチャントFIDOデータ(非SPC)を処理することについての明確な確認は、提供されたスニペットには詳述されていません。
- SPCサポート(チャレンジ):
WorldlineはSPCをサポートする明確な兆候を示しています。彼らのドキュメントは、EMV 3DS
2.3がSPC/FIDOを含むように進化したことを認識しています。彼らは、「WL Trusted
Authentication」ソリューションがFIDO認証をサポートすると明示的にマーケティングしており、「emvCO2.3およびSPCを使用した3DSユースケース」に適した「WL
FIDO Server」を提供しています。
3.5 GPayments 3DS ACS#
- 市場での存在感:
GPaymentsは、ActiveAccessを「堅牢な市場をリードするアクセス・コントロール・サーバー(ACS)プラットフォーム」として位置づけ、3Dセキュア分野で20年以上の実績があります。主要なカードスキーム(Visa Secure、Mastercard Identity Check、JCB
J/Secure)で3DS1とEMV
3DSの両方で認証されています。彼らのソリューションは、オンプレミスまたはクラウドホストで展開できます。市場レポートでは、GPaymentsはACSソリューションを提供する注目すべきプレーヤーとして特定されています。
- 非SPC FIDOデータサポート(フリクションレス):
ActiveAccessは、サードパーティのRBAソリューションとの統合をサポートし、独自のリスク評価のためにさまざまなパラメータを利用します。しかし、提供されたドキュメントでは、フリクションレスのリスク評価のために以前のマーチャントFIDO認証データ(非SPC)を取り込んだり使用したりするサポートについては明示的に言及されていません。
- SPCサポート(チャレンジ):
レビューしたActiveAccessのドキュメントでは、チャレンジフローの機能の一部として、セキュア・ペイメント・コンファメーション(SPC)、WebAuthnチャレンジ、またはFIDOチャレンジのサポートについては明示的に言及されていません。彼らはOOB(生体認証を含むことができる)を含むさまざまな認証方法をサポートしていますが、利用可能な情報からは特定のSPCサポートは不明です。
3.6 Visa (Visa Secure) 3DS ACS#
- 市場での存在感: Visaは、主要なグローバル決済ネットワークとして、EMV
3DS標準に基づいたVisa Secureプログラムを定義しています。彼らは元の3DSプロトコルを開拓しました。EntersektやBroadcomのようなテクノロジー企業と同じように直接的なACSベンダーとして機能するのではなく、Visaはプログラムを運営し、EMV
3DSおよびVisa
Secureのルールに準拠していると認定された承認済み3DSベンダー(ACSプロバイダーを含む)のリストに依存しています。イシュアーは通常、これらの認定ベンダーからACSソリューションを調達します。Visa自体は、ネットワーク(ディレクトリサーバー)に焦点を当て、プログラムルールを定義し、採用を促進し、SPCパイロットのようなイノベーションを推進しています。
- 非SPC FIDOデータサポート(フリクションレス): EMV 3DSに基づくVisa
Secureは、フリクションレスフローを可能にするためのリスク評価のための豊富なデータ交換を本質的にサポートしています。以前のFIDOデータを渡すためのEMVCo/FIDOフレームワークは、選択されたACSベンダーがその処理をサポートしていれば、Visa
Secureエコシステム内で動作します。
- SPCサポート(チャレンジ):
VisaはSPCのパイロット運用と推進に積極的に関与しています。彼らはパートナー(パイロットではNetceteraやModirum/Entersektなど)と協力して、3DSプロトコル内でのSPCフローをテストし、改良しています。この強力な関与は、エコシステムの準備(ACS、マーチャント、ブラウザのサポート)が整うことを条件として、Visa
Secureプログラム内でのチャレンジ方法としてSPCを戦略的にサポートしていることを示しています。
3.7 Mastercard (Identity Check) 3DS ACS#
- 市場での存在感: Visaと同様に、MastercardはEMV
3DSに基づいたMastercard Identity Checkプログラムを運営しています。彼らは、スタンドイン処理や、NuDataのようなパートナーや子会社を活用する可能性を含め、イシュアーやマーチャントに選択肢を提供しています。Mastercardは2017年に行動生体認証企業のNuData
Securityを買収し、リスク評価能力を強化しました。彼らはまた、生体認証、RBA、AIにおける継続的なイノベーションを強調しています。Visaと同様に、彼らは中核となるACSコンポーネントについては認定ベンダーに依存していますが、バンドルサービスや買収した技術を活用することがあります。
- 非SPC FIDOデータサポート(フリクションレス): Mastercard Identity
Checkは、リスク判定の改善とフリクションレスフローのためにEMV 3DS
2.xの豊富なデータ交換を活用しています。NuDataの買収は、このリスク評価の一環として行動分析に強く焦点を当てていることを示唆しています。以前のマーチャントFIDOデータを処理するサポートは、Identity
Checkプログラム内でイシュアーが使用する特定のACS実装に依存します。
- SPCサポート(チャレンジ):
MastercardはEMVCoの主要メンバーであり、SPCをサポートするv2.3を含むEMV
3DS標準の開発に関与しています。彼らはまた、より広範にパスキーの採用を推進しています。詳細はこちらで確認できます。彼らはSPCの強力な支持者であり、現代的な認証方法への移行を推進しています。
3.8 その他の3DS ACSベンダー#
EMV
3DS ACS市場には、上記で詳述した以外にも多数のプロバイダーが存在します。/n
software、RSA、2C2P、3dsecure.io、Adyen、ACI
Worldwide、Computopなどのベンダーも、認定ソリューションを提供したり、特定の地域やセグメントで重要な役割を果たしたりしています。この分析は、著名なグローバルプレーヤーを対象としていますが、市場の動的な性質のため、網羅的なものではありません。ベンダーの能力、特にSPCのような新しい標準に関するものは、急速に進化します。ベンダーのFIDOデータまたはセキュア・ペイメント・コンファメーションのサポートに関する不正確な点や更新情報にお気づきの場合は、この概要が最新かつ正確であり続けるよう、ご連絡ください。
4. セキュア・ペイメント・コンファメーションによるイシュアーのパスキー認証#
4.1 メカニズムの説明:リライング・パーティとしてのイシュアー#
EMV
3DSチャレンジフロー内でセキュア・ペイメント・コンファメーション(SPC)を使用する際の中心的な原則は、カード発行会社(イシュアー)(またはイシュアーによって明示的に委任された当事者、例えば決済スキーム)が**FIDOリライング・パーティ(RP)**として機能することです。これは、マーチャントが自身のログイン/認証目的でRPとして機能する、前述の非SPCのFIDOデータフローとは根本的に異なります。
3DSチャレンジでSPCが機能するためには、以下のステップが必要です。
- 登録(Enrollment):
カード会員はまず、FIDO認証器(例:指紋/顔認証などのデバイス生体認証、デバイスPIN、またはローミングセキュリティキー)を発行銀行に登録する必要があります。このプロセスでパスキーが作成され、公開鍵と一意のクレデンシャル識別子がイシュアーによって保存され、カード会員のアカウントまたは特定の支払いカードに関連付けられます。登録は、銀行のモバイルアプリ、オンラインバンキングポータル内で行われるか、あるいは従来の3DSチャレンジが成功した後に提供される可能性があります。重要なのは、マーチャントのウェブサイトのような第三者によってSPCが呼び出されるためには、通常、そのようなコンテキストでの使用を許可するユーザーの明確な同意を得てクレデンシャルが作成される必要があることです。これには、登録時に特定のWebAuthn拡張機能が関与することがよくあります。
- 認証(3DSチャレンジ中):
- 3DS取引がチャレンジを引き起こし、イシュアー/ACSがSPCをサポートし選択した場合、ACSはカード会員とデバイスにリンクされた関連するFIDOクレデンシャルIDを特定します。
- ACSはこれらのクレデンシャルID、一意の暗号学的チャレンジ、および取引詳細(金額、通貨、受取人名/オリジン、支払い手段のアイコン/表示名)を認証応答(ARes)に含め、3DSサーバー/リクエスターに返送します。
- マーチャントの3DSリクエスターコンポーネントは、このAResからの情報を使用してブラウザのSPC
APIを呼び出します。
- ブラウザは、ACSから提供された取引詳細を表示する、標準化された安全なダイアログを提示します。
- ユーザーは取引を確認し、登録済みのFIDO認証器(例:指紋センサーに触れる、顔認証、デバイスPINの入力、セキュリティキーをタップする)を使用して認証します。この操作により、デバイス/認証器に安全に保存されている秘密鍵がアンロックされます。
- 認証器は、提示された取引詳細とACSから受け取った暗号学的チャレンジに署名します。
- ブラウザは、結果として得られるFIDOアサーション(署名されたデータペイロード)をマーチャントの3DSリクエスターに返します。
- 3DSリクエスターは、このアサーションを、通常は2回目のAReqメッセージにカプセル化して、イシュアーのACSに送信します。
- 権威あるリライング・パーティとして機能するイシュアー/ACSは、カード会員の以前に保存された公開鍵を使用して、アサーションの署名を暗号学的に検証します。検証が成功すると、正当なカード会員が登録済みの認証器を使用して、提示された特定の取引詳細を承認したことが確認されます。
4.2 SPCチャレンジを含むEMV 3DSプロトコルフロー#
SPCをEMV
3DSチャレンジフローに統合するには、標準のメッセージシーケンスの変更が必要で、通常は2回のAReq/ARes交換が含まれます。
- 最初の認証リクエスト(AReq #1):
マーチャント/3DSサーバーは、取引データとデバイスデータを含むAReqを送信して3DSプロセスを開始します。SPCの能力を示すために、リクエストには
threeDSRequestorSpcSupport
を'Y'に設定するなどのインジケータが含まれる場合があります(ACSベンダーの実装によって異なります)。
- 最初の認証応答(ARes #1):
ACSがチャレンジが必要と判断し、SPCを選択した場合、これを示すAResで応答します。
transStatus
は'S'(SPCが必要であることを示す)または別の特定の値に設定される場合があります。このAResには、SPC
API呼び出しに必要なデータペイロードが含まれています。
- SPC APIの呼び出しとFIDO認証: マーチャントの3DSリクエスターコンポーネントはARes
#1を受信し、そのペイロードを使用してブラウザのSPC
APIを呼び出します。ユーザーはブラウザの安全なUIを介して認証器と対話します。
- FIDOアサーションの返却:
ユーザー認証が成功すると、ブラウザはFIDOアサーションデータを3DSリクエスターに返します。
- 2回目の認証リクエスト(AReq #2):
3DSリクエスターは、2回目のAReqメッセージを構築してACSに送信します。このメッセージの主な目的は、FIDOアサーションデータを転送することです。通常、以下が含まれます:
ReqAuthData
:FIDOアサーションを含む。
ReqAuthMethod
:'09'(またはSPC/FIDOアサーションに指定された値)に設定。
- リクエストをリンクするために、ARes
#1からの
AuthenticationInformation
値が含まれる可能性あり。
- オプションで、SPC
API呼び出しが失敗またはタイムアウトした場合の
SPCIncompletionIndicator
。
- 最終的な認証応答(ARes #2): ACSはAReq
#2を受信し、カード会員の公開鍵を使用してFIDOアサーションを検証し、最終的な認証結果を決定します。 definitiveな取引ステータス(例:
transStatus
= 'Y'で認証成功、'N'で失敗)を含むARes #2を返送します。
この2回のAReqフローは、通常はtransStatus
=
'C'が受信された後、最初のAReq/AResサイクル内で完了する従来の3DSチャレンジ方法(CReq/CResまたはRReq/RResメッセージを介して処理されるOTPやOOBなど)からの逸脱を表します。SPCのユーザーインタラクション部分(生体認証スキャン、PIN入力)は、OTPを入力するよりも大幅に速いことが多いですが、2回目の完全なAReq/AResラウンドトリップの導入は、3DSサーバー、ディレクトリサーバー、ACS間のネットワーク遅延を追加します。実装者とベンダーは、このフローを慎重に最適化し、潜在的なタイムアウトを処理して、全体のエンドツーエンドの取引時間が競争力を維持し、ユーザーの期待に応えるようにする必要があります。
5. SPCに関するエコシステムの考慮事項#
5.1 グローバル標準としてのSPC(W3C/EMVCo)#
セキュア・ペイメント・コンファメーションは、その二重の標準化により、世界的な採用に向けて位置づけられています。これは、World
Wide Web
Consortium(W3C)によってウェブ標準として正式に定義されており、2023年半ばに勧告候補(Candidate
Recommendation)ステータスに達し、完全な勧告(Recommendation)になるための作業が進行中です。同時に、SPCは、決済標準のグローバルな技術団体であるEMVCoが管理するEMV®
3-Dセキュア仕様に、バージョン2.3から統合されています。この統合により、SPCはCNP取引認証のための確立されたグローバルフレームワーク内で機能することが保証されます。W3C、FIDOアライアンス、EMVCo間の協力は、安全でユーザーフレンドリーなオンライン決済のための相互運用可能な標準を作成するための業界全体の取り組みを強調しています。
5.2 規制要件を超えた適用性(例:米国、カナダ)#
SPCの設計、特にユーザー認証を特定の取引詳細に暗号学的にリンクする能力(「動的リンク」)は、ヨーロッパの決済サービス指令(PSD2)のような規制下での強力な顧客認証(SCA)要件を満たすのに役立ちますが、その有用性はこれらの義務付けられた地域に限定されません。SPCは、必要なエコシステムコンポーネントが整備されていれば、米国やカナダを含むあらゆる市場で適用可能なグローバルな技術標準です。
すべての取引に明確なSCA要件がない市場では、SPCを採用する主な動機は次のとおりです。
- ユーザー体験の向上:
従来のOTPや知識ベースの質問と比較して、より速く便利なチャレンジ方法(例:デバイスの生体認証を使用)を提供し、カート離脱を減らす可能性があります。パイロットでは、従来のチャレンジと比較して認証時間が大幅に短縮されることが示されています。
- セキュリティの強化:
SPCに固有のFIDOベースの認証は、フィッシング攻撃、クレデンシャルスタッフィング、およびパスワードやOTPを標的とするその他の一般的な脅威に対して耐性があります。
したがって、北米などの地域のイシュアーやマーチャントは、すべての取引で規制上の要件がなくても、セキュリティを強化し、より良い顧客体験を提供するために、戦略的にSPCを実装することを選択するかもしれません。
5.3 SPCとFIDO/パスキーに関するエコシステムの依存関係と準備状況#
セキュア・ペイメント・コンファメーション(SPC)の成功した展開と広範な採用は、決済エコシステムの複数のコンポーネントにわたる協調的な準備状況に大きく依存しています。基盤となるFIDO標準とパスキー技術は急速に成熟していますが、SPC
APIの特定のブラウザレベルのサポートと、決済チェーン全体での完全な統合は、依然として重要なハードルです。他のエコシステムプレーヤーは概ね順調に進んでいます。
エコシステムの準備状況の概要(2025年5月時点)
エコシステム関係者 | SPC準備状況 | FIDO/パスキー準備状況(一般) | 主要な注記(2025年5月) |
---|
ユーザーデバイスと認証器 | ❌ 未使用 | ✅ 準備完了 | ほぼすべての最新のラップトップ、スマートフォン、セキュリティキーにはFIDO2/WebAuthn認証器が搭載されています。数十億台がすでに消費者に利用可能です。ハードウェアはボトルネックではありません。 |
ウェブブラウザ(ソフトウェア) | ❌ ボトルネック | ✅ 準備完了 | SPC: Chromium(Chrome/Edge ≥ 95)はベースラインのSPC v1をサポートしていますが、高度な機能は実験的です。Safari(macOS & iOS)とFirefoxはSPCをサポートしていません。 一般的なFIDO/パスキー: 主要なブラウザ全体でログインなどのための完全なWebAuthnサポートがあります。 |
イシュアーとACSベンダー | ⚠️ 進展中 | ✅ 進展中 | SPC: 市場リーダーはEMV 3DS 2.3.1の認証を受けており、SPCを実行できます。他社はパイロットから本番環境に移行中です。 一般的なFIDO: 多くがアプリ認証/OOBにFIDOをサポートしています。RBAデータ取り込み能力は存在しますが、採用状況は様々です。FIDOサーバー/RPインフラが必要です。 |
マーチャント | ❌ サポートなし | ✅ 進展中 | SPC: EMV 3DS v2.3+スタックとブラウザロジックが必要です。早期導入者は利点を報告しています。 一般的なFIDO: パスキーを採用してログインでの使用が増加中。threeDSRequestorAuthenticationInfo を介してデータを渡すことができます。統合の労力が必要です。 |
PSP / 3DSサーバー | ⚠️ 展開中 | ✅ 進展中 | SPC: EMV 3DS v2.3+スタックとブラウザロジックが必要です。早期導入者は利点を報告しています。 一般的なFIDO: ログインでの使用が増加中。threeDSRequestorAuthenticationInfo を介してデータを渡すことができます。統合の労力が必要です。 |
スキームのディレクトリサーバー | ✅ 準備完了 | ✅ 準備完了 | インフラ(Visa、Mastercardなど)は、パスキーが主流になるずっと前の2021年からEMV 3DS 2.3/2.3.1メッセージ(SPCおよびFIDOデータフィールドを含む)に対応済みです。 |
これが実際に意味すること(2025年5月)
SPC採用の主な制約要因は、ユーザーエージェント(ブラウザ)層です。
- Safari (macOS & iOS): ❌ WebKitにはまだ
secure-payment-confirmation
Payment
Requestメソッドがありません。Safariで訪問されたサイトは、他の認証方法(OTP、OOB、潜在的には非SPCのWebAuthn体験)にフォールバックする必要があります。Appleはこの拡張機能の実装に関心を示していません。
- Chrome / Edge (Chromium):
⚠️ ベースラインのSPC(クレデンシャル作成+認証)は安定していますが、キーはまだハードウェア認証器に保存されておらず、パイロットでのみ使用されています。実装者は、潜在的な破壊的変更を予測し、APIの利用可能性チェック(例:
canMakePayment()
)や機能フラグに基づいて機能を制限する準備をしておくべきです。
- Firefox:
❌ チームは関心を示していますが、コミットされた実装タイムラインはありません。マーチャントは、優雅なフォールバックパスを計画する必要があります。
イシュアーのインフラ(ACS、FIDOサーバー)とスキームのディレクトリサーバーは大部分が準備完了か急速に進展しており、マーチャント/PSPのツールも利用可能になりつつあるため、広範なSPC利用の主な障壁はブラウザのサポートです。
ブラウザのカバレッジが改善されれば、残りのタスクは主にマーチャント/PSPの統合(EMV
3DS
v2.3+へのアップグレード、SPC呼び出しロジックの追加、2回のAReqフローの処理)と、決済コンテキスト専用のイシュアーによるパスキー登録の拡大になります。
当面の間、SPCは限られた一部の取引でのみ表示されると予想されます。Safari(ひいてはiOSエコシステム全体)がサポートを提供するまで、SPCは市場でのサポートを達成できません。
6. 結論と戦略的提言#
6.1 まとめ:当面はフリクションレスに注力し、将来的にはSPCに備える#
この分析から、2025年5月現在、EMV
3DSにおける2つの主要なFIDO統合の準備状況には明確な乖離があることが明らかになりました。チャレンジ方法としてのセキュア・ペイメント・コンファメーション(SPC)の基盤要素、特にイシュアー/ACSの能力とスキームの準備は進んでいますが、その広範な採用はブラウザサポートという重大なボトルネックによって著しく妨げられています。特に、AppleのSafari(すべてのiOS/iPadOSデバイスをブロック)とFirefoxでの実装の欠如、および現在のChromium実装の制限が問題です。SPCは有望な未来像であり続けますが、今日、実用的で普遍的なソリューションではありません。
6.2 主要な参加者への提言#
現在のエコシステムの状態に基づき、以下の提言を行います。
- マーチャント:
- パスキー導入を優先する:
ユーザーのログインと認証にパスキーを実装しましょう。自身のセキュリティとユーザー体験を向上させる(ここでは詳述しない要素)だけでなく、これにより3DSのフリクションレスフローに必要なデータが生成されます。
- FIDOデータを渡す:
3DS統合において、チェックアウトセッション中の成功した事前のパスキー認証の詳細を
threeDSRequestorAuthenticationInfo
フィールドに正しく入力するようにしてください。これを有効にするために、PSP/3DSサーバープロバイダーと協力しましょう。
- イシュアー:
- ユーザーのパスキーを登録する:
カード会員に直接パスキーを登録するよう提供し、奨励し始めましょう(銀行アプリへのアクセス、将来のSPCなど)。必要なFIDOリライング・パーティのインフラを構築してください。
- マーチャントのパスキーデータを今すぐ活用する:
ACSベンダーに対し、マーチャントから渡されたFIDOデータ(
threeDSRequestorAuthenticationInfo
)をRBAエンジン内の強力な肯定的なシグナルとして取り込み、活用するよう指示してください。可能であれば、ユーザーに関連付けられた信頼できるマーチャントのパスキーの記録を保持しましょう。強力なマーチャントのパスキー認証に続く取引のフリクションレス承認を大幅に増やすことを目指してください。
- SPCに備え、積極的に監視する: ACSのロードマップに完全なEMV 3DS
v2.3.1+のSPCサポートが含まれていることを確認しつつも、それを将来の機能強化として扱ってください。SPCが大規模に実現可能になる時期を見極めるために、ブラウザの動向(特にSafari)を継続的に監視しましょう。
- ACSベンダー:
- パスキーインテリジェンスでRBAを強化する:
マーチャントから提供されるFIDO/パスキーデータを処理し、信頼するRBAエンジンの能力に重点的に投資してください。特定のユーザー/デバイスに対するマーチャントでの購入全体にわたるパスキーの使用状況を追跡するロジックを開発しましょう。提供された場合、マーチャント認証データの暗号学的完全性を検証するために(直接のイシュアー登録からの)公開鍵を保存してください。成功したパスキーの使用を、より高いフリクションレス承認率に直接結びつけましょう。
- 堅牢なSPC能力を構築する:
将来の市場採用に備えて、完全なSPCチャレンジフローサポート(EMV 3DS
v2.3.1+)の開発と認証を継続してください。
- 決済スキーム/ネットワーク:
- フリクションレスFIDOデータを推進する:
3DSフロー内でのマーチャントFIDO認証データ(
threeDSRequestorAuthenticationInfo
)の受け渡しと利用を積極的に推進し、場合によってはインセンティブを提供してください。このデータをRBAに効果的に活用する方法について、イシュアーとACSベンダーに明確なガイダンスとサポートを提供しましょう。
- SPCの擁護とブラウザとの連携を継続する:
SPCの標準化と推進の取り組みを維持し、特にブラウザベンダー(Apple、Mozilla、Google)と協力して、SPC
API標準の完全で相互運用可能な実装を奨励してください。
6.3 全体的な戦略的方向性#
当面の具体的な機会は、マーチャントレベルでのパスキー採用の拡大を活用してフリクションレスフローを強化することにあります。すべてのエコシステム参加者は、既存のEMV
3DSフレームワーク内で、この事前の認証データの作成、送信、およびインテリジェントな消費を可能にすることを優先すべきです。この道筋は、普遍的なSPCブラウザサポートを待つことなく、フリクションを減らし、潜在的に不正を削減するという短期的な利益をもたらします。同時に、SPCの基盤を準備すること、特にイシュアーのパスキー登録とACSの準備を進めることで、ブラウザのボトルネックが解消された際に、この優れたチャレンジ方法をエコシステムが採用できる態勢を整えることができます。