はじめに
開発本部MIXI M事業部の@k-asmです。
本投稿はMIXI DEVELOPERS Advent Calendar 2023 5日目の記事です。
MIXI Mでは内製で3Dセキュアサービスを開発しており、日々3Dセキュアの仕様を参照しながら開発しています。MIXI Mの内製3Dセキュアサービスについては、MediumのMIXI DEVELOPERSに書いた以下の記事をご覧ください。
また、PCI 3DS対応についてはAWS様に事例紹介をしていただきました。こちらも是非ご覧ください。
今回は3Dセキュアの最新仕様であるバージョン2.3.1で導入されたSPCベース認証について紹介します。これはSecure Payment Confirmation (SPC)を3Dセキュアのプロトコル上で利用できるようにしたもので、FIDOによる3Dセキュアの決済体験の改善が期待できるものです。
3Dセキュアの認証フロー
3Dセキュアにおける認証フローを解説し、3Dセキュアの決済体験上の課題について述べます。なお、以下の文章中に出てくる「3Dセキュア」は全て3Dセキュア2.0（EMV 3Dセキュア）を指しています。
FrictionlessフローとChallengeフロー
3Dセキュアの認証フローには、FrictionlessとChallengeの2つが存在します。通常3Dセキュアでイメージされる次のような認証画面はChallengeフローで表示されるもので、これは認証の過程でユーザーによるインタラクションを必要とします。
対してFrictionlessフローは、ユーザーによるインタラクションを必要とせずに認証を完了させるものです。Frictionlessフローにおけるユーザーの決済体験は、3Dセキュアが無い場合と全く同一になります。すなわち、ユーザーに3Dセキュアの存在を意識させることなく、3Dセキュアによる決済を完了させることができます。
Frictionlessフローでは、勿論3Dセキュアによる認証をしていないのではなく、バックグラウンドでリスクベース認証をしています。
リスクベース認証をするのは3Dセキュアサービスの1つであるAccess Control Server(ACS)です。ACSはイシュアーと連携して動作し、ユーザーの端末情報や決済内容などを元にリスク判定をします。決済が低リスクと判定された場合はFrictionlessフローとなり、本人認証をスキップできます。高リスクと判定された場合はChallengeフローを要求し、ユーザーの本人認証（Challenge認証）を必要とします。
3Dセキュアにおける決済体験の課題
このように3Dセキュアでは、リスクベース認証の導入によりユーザーの決済体験を向上させています。ですが、現在の3Dセキュアには次のような課題があると考えています。
Challenge認証のユーザー体験がシームレスではない
まず、Challenge認証のユーザー体験が、決済体験上シームレスなものではないことが挙げられます。
Challenge認証で利用されるデザインはEMV® 3-D Secure UI/UX Design Guidelinesに定められており、仕様上ある程度決まったフォーマットが求められます。結果として、加盟店ウェブサイトのデザインとChallenge認証画面のデザインは大きく乖離し、シームレスなユーザー体験にはなりません。
想定しないドメイン上での本人認証を求められる
次に、Challenge認証ではユーザーが想定しないドメイン上での本人認証を求められることが挙げられます。
多くの加盟店は3Dセキュアをブラウザ上で実施するのですが[1]、3Dセキュアの仕様上、Challenge認証フローは加盟店ウェブサイト上のiframe内部、もしくはACSに直接リダイレクトすることで行われます。ユーザーがChallenge認証をする対象は、イシュアー上に登録した自身のIDです。しかし3Dセキュアでは「加盟店」や「ACS」のドメインで本人認証を求められており、これは良い体験ではありません。
リスクベース認証の精度に決済の安全性が依存している
最後に、決済の安全性がACSのリスクベース認証の精度に依存している点が挙げられます。
そもそもFrictionlessフローではユーザーの本人認証ができているわけではありません。デバイス情報や決済内容などの3DS電文中に含まれる様々な情報や、イシュアーが持っているユーザーの認証情報などの各種手がかりを元にして、決済自体が低リスクであると判断されたに過ぎません。
どのようなリスクベース認証をするかは3DSの仕様では定められておらず、その精度はACSまたはイシュアーの実装に依存していると言えます。結果として、ユーザーの決済の安全性がリスクベース認証の精度に委ねられている状態です。
SPCを使った3Dセキュア認証
安全かつシームレスな決済はどのようにすれば実現可能でしょうか。SPCベース認証はその1つの答えになる可能性があります。
Secure Payment Confirmation (SPC)はW3Cにより策定が進んでいる標準技術で、WebAuthnを使って迅速かつシームレスに決済時の認証を行えるものです。3Dセキュアの最新仕様であるバージョン2.3.1では、以前のバージョンからの重要な変更点として、SPCを使った認証仕様であるSPCベース認証が追加されました。
それでは、このSPCベース認証の仕様を説明し、SPCベース認証によって3Dセキュアの体験がどう変わっていきそうか考察します。
3DセキュアのSPCベース認証について
3Dセキュアの仕様では、決済するユーザーの環境ごとに、次の3つの認証方式が定義されています。
- ブラウザベース認証： ブラウザ上から実施される認証
- アプリベース認証： モバイルアプリのNative UI上で実施される認証
- 3RI認証： リカーリング（継続課金など）のような、ユーザー起点ではない認証
SPCベース認証は、ブラウザベース認証を拡張して、WebAuthnを使った3DS認証を可能にしたものです。SPCベース認証の認証フローには、大きく2つの仕様が存在します。
- ACSがFIDO認証を開始する仕様
- 3DS Requestor（加盟店ウェブサイトなど）がFIDO認証を開始する仕様
なお、SPCベース認証におけるRelying PartyはACSとなります。ACSにすでにユーザーのFIDO Authenticatorが登録済みである前提で認証フローを開始します。
ACSがFIDO認証を開始する場合
ACSがFIDO認証を開始する場合の認証フローは、ブラウザベースでChallenge認証をする場合と同じです。ブラウザベースのChallenge認証フローのシーケンス図は次のようになります。
図上シーケンスの「12. Exchange HTML」では、ブラウザベース認証では決済をしようとしているユーザー[2]に対してACSが3Dセキュア認証画面を表示します。SPCベース認証のフローでは、この画面を呼び出す時にSPC APIを呼び出してFIDO認証を促します。
「14. Submit」で、ACSはFIDO認証のAssertionデータを得ることができるため、「15. Determine Challenge Outcome」で認証結果の検証をします。検証が通った場合3DS認証は成功となります。
3DS RequestorがFIDO認証を開始する場合
次に、3DS RequestorがFIDO認証を開始するフローを説明します。この場合のシーケンス図は次のようになります。
「1. Checkout with Purchase Info」から「10. 3DS Response」までは、ブラウザベースで3DS認証を開始した後のフローと同じです。ここまでのシーケンスはChallengeフローとFrictionlessフローにも存在しており、Frictionlessの場合はここで認証完了、Challengeの場合はACSで本人認証をするシーケンスに入ります。
このフローではユーザーがACS上で本人認証をするのではなく、3DS Requestor上でSPC APIを呼び出して（10a. Invoke SPC）FIDO認証をします。
ユーザーのFIDO Authenticatorが登録されているのはACSなので、3DS RequestorはFIDOのAssertionデータをACSまで伝達する必要があります。ここで面白いのが、Assertionデータを3DSの電文に乗せて伝達するために、2回目の3DSトランザクションを開始する点です。3DS仕様では普通、1回の決済に対して1つの3DSトランザクションが紐付きます。同一トランザクションの使いまわしは認められていないため、既存の3DSシステムはトランザクションの唯一性でリクエストバリデーションを行っています。その実装と互換性を保つため、このような仕様になっていると推測しています。
1回目のトランザクションと2回目のトランザクションが同じ決済データに紐付いていることを示すために、3DS Requestorは2回目のトランザクションの中に1回目のトランザクションの情報の一部を入れて電文を送信します。
3DS電文には以前のトランザクション情報を入れるためのパラメータである "3DS Requestor Prior Transaction Authentication Information" があります。これは3DS仕様2.1.0の時点で存在しており、SPCベース認証ではこのパラメータをうまく使っています。
"3DS Requestor Prior Transaction Authentication Information" に入るサンプルデータは次のようになります。
"threeDSRequestorPriorAuthenticationInfo": {
// 一回目のトランザクションに紐付くトランザクション ID
"threeDSReqPriorDsTransId": "894636b1-7082-4b29-85a0-db8a6563b134",
"threeDSReqPriorAuthData": "00",
"threeDSReqPriorAuthMethod": "05",
"threeDSReqPriorAuthTimestamp": "202312011010",
// 一回目のトランザクションに紐付くトランザクション ID
"threeDSReqPriorRef": "df770fd7-6eac-4815-ba0f-ea791f337522"
}
Assertionデータは「10c. Retrieve Assertion Data」から「10f. Authentication Request」に伝達し、ACSに到達します。ACSではAssertionデータの検証の他に1回目のトランザクションと2回目のトランザクションの整合性確認をします。
Assertionデータが検証できれば3DS認証はここで完了しますが、そうでない場合はChallenge認証に進みます。上記のシーケンス図はChallenge認証に進まず3DS認証が完了した時の図になっています。
SPCベース認証の決済体験に関する考察
「ACSがFIDO認証を開始する場合」のSPCベース認証は、従来のChallenge認証の認証方法の1つとしてFIDO認証が選択できるものと言えます。これはSMSやメールによるOTPの送信や、アプリによるOut-of-Band認証のような、ACSで選択できる認証方法の1つとしてFIDO認証が利用できるようになった以上のものではなく、ユーザーの決済体験に大きく変化を与えるものではなさそうです。ただ、従来の3DS認証フローに大きく手を加えることなくFIDO認証を導入できるため、ACSやイシュアーにとっては、FIDO認証を導入して認証強度を上げるカジュアルな方法として選択できる可能性があります。
「3DS RequestorがFIDO認証を開始する場合」のSPCベース認証は、加盟店サイトから遷移することなくFIDO認証で3DS認証を完了させることができます。さらにSPCによってブラウザネイティブの機能としてシームレスに認証できるため、加盟店サイト上での決済体験を損ねることがありません。ユーザーにとっては、シームレスに認証できるという点でChallenge認証よりも良い決済体験ができ、FIDO認証できるという点でFrictionlessよりも安全に決済可能になっていると考えられます。
ただし、3Dセキュアバージョン2.3.1のSPCベース認証では、FIDOのRelying PartyがACSである点に注意する必要があります。ユーザーは事前に、ACSもしくはイシュアーにFIDO Authenticatorを登録する必要があります。SPCベース認証ではChallenge認証よりもイシュアーの存在が隠蔽されると言えるため、ユーザーにとっては、加盟店サイトでの決済時にイシュアーのFIDO Authenticatorが求められるという状況が混乱を招く可能性があります。
この点についてはEMVCoやFIDOアライアンスより、加盟店がFIDOのRelying Partyである時に、3DS認証をどう利用できるかについて検討されたWhite Paper・Technical Noteが発行されています。継続的に議論されている様子ですので、今後の動向に注目していきたいです。
おわりに
この記事では、3Dセキュアの最新仕様で新しく定義されたSPCベース認証について紹介しました。SPCベース認証によって、従来の認証フローにおける課題の改善が期待でき、安全かつシームレスな決済ができる未来に一歩近づきそうです。
3Dセキュアの最新仕様をユーザーが享受できるようになるためには、3DS Server・Directory Server・ACSといった全ての3Dセキュアサービスが協調し、最新仕様に対応している必要があります。MIXI Mは3Dセキュアサービスを開発・運用する事業者として、ユーザーの決済体験向上に努めていきます。
Discussion