WebAuthn and SPC

Business Overview

Secure Payment Confirmation (SPC) is a proposed web standard that allows customers to authenticate with their card issuer, bank, or other payment service provider using a platform authenticator:

  • Touch ID / Face ID on a macOS device
  • Windows Hello on a Windows device

SPC is designed to enable streamlined SCA for the purpose of completing online payment transactions. It enables a consistent authentication experience across websites/Merchants and provides cryptographic evidence that the Cardholder has accepted the terms of the transaction. These terms include the Merchant details, the payment instrument, and the total amount of the transaction. When a Merchant or Issuer invokes the SPC API, the Browser displays the elements of the transaction in a secure modal window, and the Cardholder is asked to verify as illustrated below.

WebAuthn User Experience

Once the SPC Transaction Data has been verified by the Cardholder, the Cardholder is then prompted to authenticate using the Platform Authenticator integrated with their device.
There are two steps to use SPC – registration and authentication:

  • Registration: the Cardholder links their device to a Relying Party. The Relying Party may be a payment network, bank, or other payment service provider.
  • Authentication: the Cardholder uses the registered device to confirm their identity with the Relying Party directly from the Merchant’s platform before confirming payments.

This White Paper focuses on the Authentication stage of SPC and assumes that registration of the Cardholder’s credential has already occurred and is outside the scope of the Core Specification.

Benefits by Actor

Merchant
  • enables seamless shopping while ensuring Cardholder privacy and maintaining the highest levels of security
Issuer
  • allows Issuers to leverage FIDO standards for authentication approval
Cardholder
  • provides a consistent authentication experience across different websites and platforms

Technical Features

Overview

SPC is built upon WebAuthn and designed specifically for payment purposes. As WebAuthn credentials are registered for specific domains, these credentials cannot be used to authenticate on unregistered sites that may be impersonating a Merchant. This feature makes WebAuthn effective against phishing attacks. SPC is available for browsers built using Chromium software (such as Microsoft Edge or Google Chrome).
SPC adds a payment information layer on top of WebAuthn enabling the card issuer or bank to provide a consistent payment experience. Once a payer registers an authenticator with the Relying Party, it can be used to authenticate on different Merchant sites. The Relying Party can also choose to use the payment credential as a regular WebAuthn credential.

Preconditions

The ACS has an enrolled FIDO Authenticator on the device for the Cardholder.
The 3DS Requestor and/or the ACS have detected that the Cardholder Browser supports the related SPC APIs (allow=”payment *; publickey-credentials-get *”). For the ACS, this information can be obtained via the Browser User-Agent data element or via data obtained using the 3DS Method.

Table 4.2 below lists the data elements that may be provided in relation to SPC, whereas Table 4.3 lists the data elements that may be provided in relation to the SPC Transaction Data Object

Table 4.2:  3DS Data Elements Related to Secure Payment Confirmation

 

Data Element/
Field Name

Description

Version

3DS Requestor Authentication Information

Information about how the 3DS Requestor authenticated the Cardholder before or during the transaction.

2.3.1

3DS Requestor Prior Transaction Authentication Information

Information about how the 3DS Requestor authenticated the Cardholder as part of a previous 3DS transaction.

2.3.1

3DS Requestor SPC Support

 

Indicate if the 3DS Requestor supports the SPC authentication.

Note: If present, this field contains the value Y.

2.3.1

ACS Information Indicator

 

Provides additional information for a particular Protocol Version to the 3DS Server. The element lists all applicable values for the card range.
Example:
{
“acsInfoInd”:[“01″,”02″,”03″,”04”,“05”,”06″,”07″]
}

2.3.1

Authentication Method

 

Indicates the list of authentication types the Issuer will use to challenge the Cardholder, when in the ARes message or what was used by the ACS when in the RReq message.

Note: For 03-3RI, only present for Decoupled Authentication.

2.3.1

SPC Transaction Data

Information that the 3DS Requestor passes in the SPC API for display in the Smart Modal Window.

2.3.1

Transaction Status

 

Indicates whether a transaction qualifies as an authenticated transaction or account verification.

The Final CRes message can only contain a value of Y or N or D.

Transaction Status = C or S is not allowed for Device Channel = 3RI.

2.3.1

WebAuthn Credential List

List of credential IDs registered for the Cardholder Account Number.

2.3.1

Table 4.3: 3DS Data Elements Related to the SPC Transaction Data Object

 

Data Element/
Field Name

Description

Version

Additional Data

For SPC API enhancement, to be defined in a future 3DS specification release

2.3.1

Challenge

Random string generated by the ACS to prevent replay attacks.

2.3.1

Challenge Information Text

Text provided by the ACS to be displayed during the SPC authentication.

2.3.1

Currency

Transaction amount currency to be displayed during the SPC authentication

2.3.1

Display Name

Card or product name (Payment Instrument) to be displayed during the SPC authentication.

2.3.1

Icon

Card image (Payment Instrument) URL or Data URL to be displayed during the SPC authentication.

2.3.1

Issuer Image SPC

 

Issuer logo or Image URLs or Data URLs to be displayed during the SPC authentication.

Includes at minimum the Default Image and at maximum the three Fully Qualified URLs or Data URLs defined as default, dark mode or monochrome images of the Issuer Image SPC.

Default Image
  Field Name: default
Dark Mode Image
  Field Name: dark
Monochrome Image
  Field Name: monochrome

Example Fully Qualified URL:
“issuerImageSpc”:{
“default”:”https://acs.com/defaultspcimage.png”}

Example Data URL:
“issuerImageSpc”:{     “default”:”data:image/png;base64,iVBORw0KGgoAA…”}

2.3.1

Payee Name

 

The display name of the payee that this SPC call is for (e.g., the Merchant).
Matches the Merchant Name from the AReq message.

2.3.1

Payee Origin

 

The origin of the payee that this SPC call is for (e.g. the Merchant).
Matches the Payee Origin from the AReq message.

2.3.1

Payment System Image SPC

 

Payment System logo or Image URLs to be displayed during the SPC authentication.

Includes at minimum the Default Image and at maximum the three Fully Qualified URLs defined as default, dark mode or monochrome images of the Payment System Image SPC.

Default Image
  Field Name: default
Dark Mode Image
  Field Name: dark
Monochrome Image
  Field Name: monochrome

Example Fully Qualified URL:
“psImageSpc”:{
“default”:”https://ds.com/defaultspcimage.png”}

Example Data URL:
“psImageSpc”:{
“default”:”data:image/png;base64,c2RzYWRhc2Q…”}

2.3.1

Timeout

The number of milliseconds before the request to sign the transaction details times out.

2.3.1

Value

Transaction amount as a decimal value to be displayed during the SPC authentication.

2.3.1

WebAuthn SPC Extension Indicator

For SPC and WebAuthn API enhancement.

2.3.1

Merchant-Initiated SPC Flow

Overview

The SPC authentication can be initiated by the 3DS Requestor via an extra AReq/ARes message pair instead of the standard browser challenge flow.

Sequence Diagram

  1. The Cardholder interacts with the 3DS Requestor using a browser on their device.
  2. The 3DS Requestor initiates communication with the 3DS Server and provides the necessary 3DS data to the 3DS Server to start the Cardholder authentication.
  3. The 3DS Server sends the Authentication Request (AReq) and indicates that the 3DS Requestor can support SPC authentication for the transaction and that the Browser supports the SPC API
    1. Support is indicated by setting the 3DS Requestor SPC Support = Y.
  4. The ACS receives the AReq and recognises that SPC-based authentication is supported. It determines that SPC is the selected authentication method and returns an Authentication Response (ARes) containing:
    1. Transaction Status = S
    2. WebAuthn Credential List: The list of enrolled FIDO credentials associated with the Cardholder.
    3. SPC Transaction Data containing:
      1. Challenge data: Random string generated by the ACS to prevent replay attacks.
      2. Challenge Information Text: Text provided by the ACS to be displayed during the SPC authentication.
      3. Currency: Transaction amount currency to be displayed during the SPC authentication.
      4. Display Name: Card or product name (Payment Instrument) to be displayed during the SPC authentication.
      5. Icon: Card image URL or Data URL to be displayed during the SPC authentication.
      6. Issuer Image SPC: Issuer logo or Image URLs or Data URLs to be displayed during the SPC authentication.
      7. Payee Name: The display name of the payee that the SPC call is for (the Merchant).
      8. Payee Origin: The origin of the payee that the SPC call is for (the Merchant)
      9. Payment System Image SPC: The Payment System logo or Image URLs to be displayed during the SPC authentication.
      10. Timeout: The number of milliseconds before the request to sign the transaction details times out.
      11. Value: Transaction amount as a decimal value to be displayed during the SPC authentication.
      12. WebAuthn SPC Extension Indicator: For SPC and WebAuthn API enhancement.
  5. The 3DS Server sends the necessary information from the ARes message to the 3DS Requestor, in particular, the WebAuthn Credential List, and the SPC Transaction Data.
  6. The 3DS Requestor invokes the SPC API against the WebAuthn Credential List returned in the ARes and provides the SPC Transaction Data as an input.
  7. The Cardholder confirms the transaction details.
  8. The Cardholder authenticates using the FIDO Authenticator on their device.
  9. The 3DS Requestor initiates a second 3DS Authentication Request with the 3DS Server and provides the SPC Assertion Data output from the SPC API to the 3DS Server.
  10. The 3DS Server sends the second AReq message containing:
    1. The FIDO Assertion Data via the 3DS Requestor Authentication Data object using a 3DS Requestor Authentication Method = 09.
    2. A new 3DS Server Transaction ID.
    3. The 3DS Requestor Prior Transaction Authentication Information object, which includes:
      1. 3DS Requestor Prior Transaction Reference = ACS Transaction ID from the prior ARes message indicating that SPC authentication is to be performed.
      2. 3DS Prior Transaction Authentication Method = 05 (SPC authentication).
      3. 3DS Requestor Prior Transaction Authentication Timestamp.
  11. The ACS receives the second AReq and determines the disposition of the transaction by evaluating the Assertion Data and responds with an ARes message. The ACS does its evaluation by verifying:
    1. The signature in the Assertion Data
    2. The consistency of the transaction data between the first and second AReq messages
    3. The consistency of the Assertion Data with the data from the AReq message.

Note: It is expected that, if the Assertion Data is verified correctly, no further challenge is needed and the 3DS Server will then receive an ARes message with Transaction Status = Y. However, the ACS is able to respond with any applicable Transaction Status, including Transaction Status = C, if the ACS determines that an additional challenge is necessary.
Note: The DS may act as the FIDO Relying Party and perform some or all the actions described for the ACS within the SPC flow.

 Merchant-Initiated SPC Flow

User Experience

Issuer-Initiated SPC Flow

Overview

When the ACS initiates and performs an SPC authentication as part of a challenge, the steps are identical to a standard Browser flow, where SPC authentication is used instead of the other 3DS challenge methods. This section outlines some of the details and values for specific steps when an ACS performs an SPC authentication as part of the Challenge Flow.

Sequence Diagram

  1. The Cardholder interacts with the 3DS Requestor using a Browser on a consumer device.
  2. The 3DS Requestor initiates communications with the 3DS Server and provides the necessary 3DS data to the 3DS Server to initiate Cardholder authentication.
  3. The 3DS Server sends the Authentication Request (AReq).
  4. The ACS receives the AReq and recognises that there is a pre-registered FIDO Authenticator on the device for the Cardholder. It determines that SPC will be selected as the authentication method and returns the 3DS Server an Authentication Response (ARes) containing:
    a. Transaction Status = C
    b. Authentication Method = 14 (SPC)
  5. The 3DS Requestor accepts the request for challenge and posts the CReq message using an HTTP POST through the Cardholder Browser HTML iframe to the ACS URL received in the ARes message.
  6. The ACS receives and processes the Challenge Request (CReq) message from the Browser.
  7. The ACS invokes the SPC authentication (SPC API) against the credentials registered for the Cardholder and the device using, for example, a JavaScript.
  8. The Cardholder authenticates using the FIDO Authentication on their device (for example, using Windows Hello or Apple Touch ID).
  9. The ACS retrieves, evaluates, and verifies the Assertion Data from the SPC Browser API.
  10. The ACS determines the challenge outcome and sends the Results Request (RReq) message to the 3DS Server through the DS.
  11. The 3DS Server receives and processes the RReq message, and responds with a Results Response (RRes) message to the ACS.
  12. The ACS receives the RRes message and responds with the Final Challenge Response (CRes) message.

User Experience