EMV® 3-D Secure × FIDO で目指す世界とは?

FIDO Payment 3DS Security

f:id:ritou:20201105022724p:plain

おはようございます。ritouです。 最近寒いです。もうダメ。

なんの話か

今日はこのお話です。

EMVCoとFIDOアライアンスがタッグを組む的な話です。 なんかさっぱりいいねが少ないですが、気になりますね。

読む前に期待してたこと

人間(あるいは猫)はリンク先を確認する前に内容をある程度決めつけちゃう生き物です。そりゃあTwitterも中身見てみろとか言ってくるわけです。

3DSってこういうやつじゃないですか。

https://pointofsale.com/wp-content/uploads/2016/10/3-d_secure_emvco.jpg

(ref. https://pointofsale.com/emvco-launches-emv-3-d-secure-2-0-specification/)

  • (図では3DS Requestorとなってる)MerchantからDSを経由してIssuerに認証要求が送られる
  • (毎回もしくは必要に応じて)Issuerは認証を要求する

なので今回の件、なんとなくこう思っていました。

  • 3DS 2.0からは「必要な時だけ認証を要求してEコマースなどの離脱を防ぐ」みたいな感じだし、きっとその認証にFIDOを使う話なのかなー...
  • そういえば3DSの認証を行うドメインがどうこういう話があったな...FIDO2(WebAuthn)だとドメインというかoriginのあたりも重要になるのでAuthenticatorの登録はこうするとか書かれてるのかなー...
  • 手元のスマホに入ってる公式アプリ + UAF でいよいよ本格的な Decoupled AuthN 時代来るかなー...

f:id:ritou:20201105024925p:plain

で、読んでみました。

書いてあったこと

想像してたのとちょっと違いました。

The ‘Use of FIDO Data in 3DS Messages’ white paper focuses on the newly defined FIDO attestation data set. Using this defined data set, merchants can deliver a structured set of data elements and present the card issuer with a consistent set of values for the same user or device (along with other data they would receive as part of an EMV® 3DS transaction), reducing the need for repeated consumer authentication.

...

“Outlining exactly how the data can be used by card issuers to analyse merchant-initiated FIDO Authentication as part of their risk evaluations, can increase authorisation approval rates, streamline online checkout and reduce fraud,”

資料: https://www.emvco.com/wp-content/uploads/documents/EMVCo_3DS_FIDOData-WPv1.0_20200710.pdf

ということで、

  • FIDOで認証を行うのはMarchantであり、その結果(の一部)もしくはユーザーに紐づく情報を Issuer に送る
  • Issuer はそれを含むユーザー/デバイスのデータを使って認証を要求するかを判断

という感じです。

f:id:ritou:20201105024944p:plain

そっちかい！と思いつつも、3DSはMerchantが決済などをしたい環境、デバイス情報を送りまくってリスクを判別するっていう考えなのでその中にFIDOのデータを使うという考えはなるほどなーという感じもします。

毎回FIDOで認証するわけじゃなく、FIDOのデータも含められるようにするよと。 とはいえ「3DSでの認証スキップの可能性が上がる」ためにMerchantがFIDOでの認証を入れてくれるかってとこが気になります。 まぁ、そこ気にならないぐらいFIDOを普及させれば良いんですね。そうですか。

誰が実装するか？

これ実際どうやって実装されることになるかというと

  1. Merchant自身が元々実装してたのでそれを決済機能に組み合わせて使う
  2. Merchant自身がこのために導入
  3. 3D Secure Merchant Plug-In、SDKがやってくれる未来

の3パターンがありえるかもしれません。2,3は重複するかもしれない。

3DS 2.0でIssuerがリスクベース認証を行うためにたくさんの環境データを利用できるように、3のPluginがSDKを利用して情報を吸い上げる実装があります。 Web用のSDKnならばWebAuthnを呼び出し、結果を保存しておく仕組みやバックエンドから吸い上げる仕組みがあると普及のハードルは下がるかもしれません。

送られるデータ

Merchantから送られるFIDO関連データは次の通りです。

{
  "authTime": "2020-08-08T07:42:17Z",
  "rpId": "https://emvco.com",
  "FIDOAuthenticatorReferences": [
    {
      "publicKey": "BJDLvkKkuXRpn3bWh_hiJQb8lJNd9kTXEmQgEwoHezkNI_VPGd3vrjrWyZTfgxVDl9_Tp ixrVjmEAEmegmfL2WI",
      "aaguid": "0132d110-bf4e-4208-a403-ab4f5f12efe5",
      "uv": true,
      "up": true,
      "usedForThisTransaction": true
    }
  ]
}

WebAuthnとか触った人ならわかりますね。

  • authTime
  • rpId or appId
  • FIDOAuthenticatorReferences
    • publicKey
    • aaguid or Aaid
    • usedForThisTransaction : Merchantの現在のセッションで使われたらtrueがセットされる
    • Up : セキュリティキーやブラウザの所持を確認したか
    • Uv : PINや生体認証をしたか

複数送っても構いません。あるだけ送れという感じです。

まぁ、公開鍵は送っても問題はないしとはいえ、セキュリティキーの緩い型番的な aaguid とかまで...って思ってしまいますが、元々3DSはえぐいデータを送れるような定義になってるのでこういうもんなんでしょう。以前、この3DSのリスクベース判定みたいなのをOIDC CIBAでもやれば...みたいな記事を書きましたので良かったらどうぞ。

ritou.hatenablog.com

Issuerはどうすんの？

先ほど紹介した情報を用いて認証を要求するかしないかを判断します。 ここから先はIssuerの設計/実装に依存する話かと思うので書かれていなそう(別の仕様にあるかも)ですが、この辺りのベストプラクティスもあると良さそうです。

Issuer側でFIDO使わないの？

このあたりは今回の発表とは別で検討されるかもしれません。 FIDOを使ってはいけないということではないので、今後は使うところが出てくることを祈ります。 上にも少し書きましたが、元々3DSの認証で使われるドメインがIssuerのドメインじゃなかったりするパターンもあるので、そのあたりはもう少し整理されないと「微妙に使いにくい組み合わせ」と言われかねません。

まとめ

  • EMV® 3-D Secure × FIDO ということで想像が膨らんだ
  • 書いてある内容は予想と違ってMerchantがFIDOで認証した結果を送るものだった
  • これはこれで興味深いがMerchantの採用モチベーションは上がるだろうか...

うーん、まぁ、ちゃんと実装してくれるIssuer/Marchantが出てくると良いですね。

以上です。

そういえば今年もアドカレやりまっす。

何人か参加表明をいただいております。 満員になったら私の6枠を減らしてもいいので是非ご参加ください。

ではまた。