トークンバインディング

通常、マーチャントなどのトークンリクエスタは、エンドユーザーがトークンで支払う準備ができたときにトークンバインディング要求を開始します。トークンバインディングはトークンの使用を制限し、その正当性への信頼性を高めます。

D1 は要求を受け取り、登録済みデータを使用してワークフローをオーケストレーションします。イシュアバックエンドには新しい API は不要です。イシュアバックエンドの関与レベルは、イシュアが選択した統合モデルによって異なります。

トークンバインディングにはデバイスが関与するため、イシュアは D1 オンボーディング中に信頼しないデバイスタイプを定義できます。D1 は、このデータを使用して、TSP が必要なデバイス情報を提供した場合にバインディング要求を拒否します。

次の表には、イシュアが信頼しないデバイスを定義するために使用できる情報を示します:

ルール名

説明

信頼しないデバイスタイプ

イシュアは、信頼しないデバイスタイプを選択できます。たとえば、次のタイプのデバイスなどです WATCH.

デバイス製造元

イシュアは、信頼しないデバイス製造元を一覧表示できます。

デバイス製造元 - OS バージョン

既知の場合、イシュアは信頼しない OS バージョンを指定できます。

デバイス製造元 - FW バージョン

既知の場合、イシュアは信頼しないファームウェアバージョンを指定できます。

信頼しないデバイスに関するルールがない場合、D1 は常に ステップアップ認証 を各バインディング要求に対して必要とします。

次のシーケンス図は、D1 がオーケストレーションする全体のフローと、イシュアバックエンドの関与レベルを示しています。

信頼しないデバイスが定義されていない場合、または定義されたルールに一致するデバイスがない場合、D1 は常に ステップアップ認証 および利用可能な ID&V 方法の一覧を提供します。

ID&V の前提条件については、 ID&V 方法の前提条件.

次のシーケンス図は、エンドユーザーが検証方法として SMS またはメールによる OTP を選択したときのフローを示しています:

この ステップアップ方法を配信 ステップでは 08 は依然として OTP を配信 API に対応します。この API は、選択された ID&V 方法、この場合は OTP を配信します。

イシュアバックエンドが OTP 配信を管理する場合、 OTP を配信 API を実装し、 otp.reason フィールドを使用して、この要求とトークン化リクエストを区別する必要があります。これには deliveryChannel を使用してメッセージの種類を判別できます:

次のシーケンス図は、エンドユーザーが検証方法としてイシュアアプリケーションを選択したときのフローを示しています:

で説明したとおり、高レベルフローセクションでは、イシュアバックエンドはステップで必要な統合を処理する必要があります [02]。共有データは TSP に依存します。トークン化フローと比較して、次のマッピングを使用して StepupAuthenticationResult を正しく設定します:

Mastercard

Visa

authenticationId

authenticationCorrelationId

lifeCycleTraceID

イシュアは、PUSH メッセージを使用してイシュアアプリケーションでの検証をサポートできます。これにより、マーチャントアプリケーションがイシュアアプリケーションを起動することに依存せずに済みます。

このオプションは、次の条件下でのみサポートされます:

イシュアは Mastercard カードをサポートしています。この種の ID&V オプションをマーチャントに伝播できるのは Mastercard のみです。
イシュアは、エンドユーザーにメッセージを送信するために D1 OBO サービスに依存していません。その場合、Thales はイシュアに代わって PUSH メッセージを送信できません。