Token binding

Typically, a token requestor such as a merchant starts a token binding request through the TSP when the end user is ready to use a token for payment, or when the merchant can bind the token to a device or passkey. Binding verifies the end user and increases confidence in the legitimacy of the token usage.

D1 receives the request and orchestrates the workflow by using the registered data. The issuer backend does not need new APIs. The level of issuer backend involvement depends on the integration model selected by the issuer.

Because token binding involves a device, the issuer can define a list of untrusted devices during D1 onboarding. D1 uses this data to decline a binding request when the TSP provides the required device information.

The following table lists the information that the issuer can use to define untrusted devices:

Rule name	Description
Device types not trusted	The issuer can select device types it does not trust. For example, devices of type WATCH.
Device manufacturer	The issuer can list device manufacturers it does not trust.
Device manufacturer - OS version	If known, the issuer can specify an OS version it does not trust.
Device manufacturer - FW version	If known, the issuer can specify a firmware version it does not trust.

Without rules for untrusted devices, D1 always requires step-up authentication for each binding request.

Sequence diagrams

The following sequence diagrams show the full flow orchestrated by D1 and the level of involvement of the issuer backend.

Overview of the token binding flow.

If no untrusted devices have been defined, or if no device matches the defined rules, D1 always performs step-up authentication and provides the list of available ID&V methods.

For ID&V method prerequisites, see Prerequisites for ID&V methods.

OTP verification by SMS or email

The following sequence diagram shows the flow when the end user chooses OTP by SMS or email as the verification method:

OTP verification flow for token binding.

If the issuer backend manages OTP delivery, it can use the otp.reason field to distinguish this request from a Tokenization request. It can use deliveryChannel to determine the message type:

• otp.reason = DEVICE-BINDING
• deliveryChannel = SMS or EMAIL

Verification by the issuer application

The following sequence diagram shows the flow when the end user chooses the issuer application as the verification method:

Issuer application verification flow for token binding.

As described in the High-level flow section, the issuer backend must handle the integration required in step [02]. The shared data depends on the TSP. Compared with a Tokenization flow, use the following mapping to populate StepupAuthenticationResult correctly:

D1	Mastercard	Visa
authenticationId	authenticationCorrelationId	lifeCycleTraceID

Verification by issuer application with issuer-managed trigger

The issuer can support verification in the issuer application by using a PUSH message as the trigger instead of relying on the merchant application to trigger the issuer application.

This option is supported only under these conditions:

• The issuer supports Mastercard cards. Only Mastercard can propagate this type of ID&V option to the merchant.
• The issuer does not rely on the D1 OBO service to send messages to the end user. In that case, Thales cannot send the PUSH message on behalf of the issuer.

The following diagram shows this flow:

Issuer-managed trigger flow for token binding verification.

To identify this case, the issuer must check the following fields in the Deliver OTP API:

• otp.reason = DEVICE-BINDING
• deliveryChannel = PUSH
• deviceInformation.bindingReference
• digitalCardId

To report the result through StepupAuthenticationResult, the issuer must send the following value along with digitalCardId:

• authenticationId = bindingReference

In this case, no otp.value is provided.

The issuer is free to manage the PUSH message content and format.