request_params

This page is for notes about 3DS2 flows with Payment Request API in mind. Questions? Ian Jacobs <ij@w3.org>.

Example Payment Request Data for Token and Strong Authentication

const methodData = [{
  supportedMethods: ["tokenized-card"],
  data: {
    supportedNetworks: ['mastercard','visa', 'amex', 'discover', 'jcb','unionpay'],
    supportedTypes: ['credit','debit'],
    keyProviderURL: 'https://pspKeyProvider.example/tokenizedCardPublicKey',
    strongAuth: ['3DS2', 'U2F'], //Means: require one of 3DS2 or FIDO U2F
  }
}];

const details = { ...total, etc.... };

new PaymentRequest(methodData, details);

U2F Flow with third party payment app from issuing bank

• User selects Web-based payment handler mybank.com (issuing bank).
• Mybank.com uses Web Authentication API to authenticate the user.
• Payment handler returns W3C tokenized card payment data, which includes issuer-generated cryptogram, part of subsequent authorization request.

3DS2 Flow with third party payment app from issuing bank

• User selects Web-based payment handler mybank.com (issuing bank).
• Mybank.com initiates 3-D Secure 2 flow as Requestor.
  • Frictionless flow: no further user action required.
  • Challenge flow: payment app authenticates the user with Web Authentication or other method.
• Payment handler returns W3C tokenized card payment data which includes issuer-generated cryptogram, part of subsequent authorization request.

Notes and Questions

• The point of this exercise is to see whether we can do very little from a Web API perspective to support different strong authentication flows, including but not limited to 3-D Secure 2.
• From further discussion it seems like there might be multiple parties that would potentially want to express a preference for strong authentication, in order: issuers, merchants, users.
• Adam Solove indicated that merchants might not be comfortable passing data through a 3-D Secure server with whom they do not have an existing relationship. In this model, there is no 3-D Server; the issuer has the data it needs via the payment handler to do the risk analysis (or have its ACS do so).
• In the code example strongAuth is a simple mechanism for the merchant to request some form of strong authentication activity on the user side. Does that make sense? What values might be useful? Absence of strongAuth would mean "do not do strong authentication". (Otherwise, the merchant's PSP might get data back that it does not know how to deal with.)
• User authentication to the issuing bank while making a payment with the bank's app seems like a good fit from a user experience perspective.
• The way 3-D Secure 2 is deployed today (on the merchant side) is that the user has no software installation obligation. There will be challenges in getting user adoption of payment handlers. That challenge might go down in the case of browser-as-payment-handler.
• 3-D Secure 2 risk analysis involves some merchant data. What is the minimum amount of data that the merchant would have to send through the Payment Request API to enable the ACS to do the analysis? If the data is sensitive, could the merchant pass through a URL so that the ACS can request the data if needed? Because the merchant's origin is known to the payment handler, the URL could be matched against it for security. Or, if there are proprietary mechanisms for communication between parties, the merchant origin might suffice to establish the end point (thus no URL required).