3DS 2.0 and Payment Request API

Brian Piel Slides

See minutes from first part of discussion from 7 November.

Manash: Why is 3D Secure important to payments?
... There is a disparity between physical payment approval rates (96%) and digital (83%)
... the merchant's number one metric is CONVERSION RATES
... at the same time, regulatory requirements (India, Singapore, Europe, ....) will require 3DS 2
... when a merchant is looking at a web-based payment method, they would always see where the highest conversion will be in a manner compatible with regulation.
... so PR API adoption will be influenced by these factors
... There has been an evolution from 3DS 1.0 to 3DS 2.0 (and now 2.1)
... In India, they mandated 2 factor....so with Uber it was not a good user experience
... so Uber had to partner with Paytm
... but with 3DS 2.0, the experience is more involved.
... there is a risk-based assessment hosted by an issuer or issuer vendor...and that systems looks at multiple factors to make a step-up decision
... thanks to that, step-up decreases by 95%. Furthermore, depending on geography, there may be other benefits such as liability shift
... In PR API we are looking at several relevant payment methods and use cases. In the Basic Card use case, the user is stepped up each time to enter CVV
... one thought that we have is that if the browser becomes a 3DS 2.0 requestor then the browser would no longer have to enter CVV and no step up would be required
... at the same time, in addition to the superior user experience, we would provide something that the merchant needs (namely regulatory compliance).
... What is the developer requirement for the merchant?
... burden is small..they indicate they do 3DS 1.0...the delta from the merchant perspective is small
... so the main implementation burden is either on browser or payment apps
... this allows you to get scale
... suppose there are 100K merchants, 10 large payment apps, and 4 browsers
... I think that by doing this we will help drive merchant adoption of PR API

Jayakumar: A couple of things I want to add...
... the volume of 3DS transactions is growing
... more and more schemes are adopting it
... it's not just a payment transaction, it's also trying to do card provisioning in the ecosystem
... you can use 3dS 2.0 to provision
... The other key thing I see is that it sits between the pay button and the success screen, so feels very natural to associate with PR API.

@@: Who shows the challenge to verify your identity?

Manash: In the basic card there is a card-on-browser version or a third party payment app
... in card-on-browser case, they can invoke 3DS 2.0 and they would display the popup

Brian: You interact directly with the bank.
... in case of browser it would be a frame, but in 3DS 2.0 there are more options
... redirects are removed

Manash: For the third party payment app case, it's the requestor
... the payment app invokes 3DS 2.0 and is responsible for showing the step-up flow

jenan: What is the data that needs to be sent?
... What is the data flow exactly?
... if the browser is implementing directly, to whom does it speak?
... When step-up happens, what does it look like?
... can it be structured data and present a custom UI?
... are there cases where that does not work?
... When it is HTML from the issuer, what are the guarantees around those frames (and how well that renders)?
... Can the frame ask for sensitive data?

Christiaan: Does it always have to be HTML rendered?

Brian: There is a 3DS SDK option that can be built to spec
... you can embed that in your apps, and there is a different browser-based flow.
... the UI is specified as well, so the step-up is specified
... all payment brands will look the same

[Brian demo]

[3DS Ecosystem Components] - merchant domain, interop domain, issuer domain

Brian: 3dS is communication among parties and the interop domain is about routing

[Flow diagram in the EMV arch spec]

Brian: The more data that comes in the better the risk assessment: device + consumer + transaction.

Brian: Phased messaging: auth, then challenge, then results

Manash: Suppose you are talking about the basic card flow...if PR API does not implement 3DS 2.0, the merchant would have to host the 3DS 2.0 client and invoke the 3DS 2.0 server.
... and EVERY merchant would need to do that
... but if the browser or payment app implements the 3DS 2.0 requester, the entire experience happens within the payment flow (and user would not have to enter CVV)
... in that particular flow, when the 3DS 2.0 requestor calls the API, they will send data points to the server...that data set is publicly available.
... it has multiple components (info about the merchant, information about the device, information about the browser)

Brian: Boils down to device, user data (e.g., shipping address) and transaction data

MattS: Does the browser have the necessary data to invoke the 3DS 2.0 server?

Manash: Good point
... as part of the evolution that we can do: figure out whether 3DS 2.0 would be viable in the browser.
... (Note that 3DS 2.0 production will be released mid 2018)
... we do not think that there's much impact on Payment Request API itself.

MattS: I am trying to get a feel for, e.g., data leakage risks.

Sachin: IMO the data is available among the three parties...but I agree we need to look more closely at the data leakage issue.

@@: Does the merchant need to do a risk assessment on every transaction?

scribe: there could be multiple merchants using the same issuer
... if the issuer has to make a risk assessment but does not have risk assessment data from the browser, that could be limiting

Manash: There is authentication model data available during user selection of instrument
... all that data constitutes a unique flow.

@@: Suppose I was at Flipkart and was stepped up and then visited another merchant...the issuer would not have access to the data

Brian: Currently there is a process that allows for zero-pixel iframe
... there could be opportunities to enhance that

shift4sms: From my understanding, you are requesting all the data but most was optional

Brian: 3DS 2.1 was released recently; we expect to update each year
... Regarding frictionless - if we can share the data in and out we don't necessarily need to do step-up
... there are regional requirements.
... the issuer may live in a region where the issuer is mandated to do a step up and the issuer can say "I need to do this"
... if the merchant does not want to step-up, then would be declined
... focus for this group is on the requestor environment
... how can we enhance it and make it easier overall

shift4sms: Is the 3DS auth process happen with the payment auth request?

Manash: pre authorization

IJ: Can we talk about webauthn + token + PR API?

Manash: One of the data points is also "what is the authentication mechanism that the user used?"
... our colleagues from the WebAuth WG are working on that particular spec (FIDO-style auth for web pages)
... that could be one of the areas we continue to collaborate on - the authentication info is one of the data points

Use Cases

Brian:

• payment authentication at time of payment; provides a risk based assessment, and framework for issuer-based cardholder challenges
• Non-payment auth: used for verification of account based on cardholder data + risk-based assessment + framework. Used, e.g., at provisioning
• 3DS 2.0 server initiated, when no consumer is present. Here the issuer can validate data (and there is no step-up since no customer)
  ... that's another extension to the spec to allow it to be more flexible

MattS: Is this specifically for card authentication?
... is there an application beyond cards?
... eg., PSD2 would be interesting
... do you have any adoption information outside of card-based payments?

Brian: We don't have public information at this time.
... We look forward to more industry input (including from this group)

Manash: If the WPWG feels that there are good things to influence in that spec development, that could be useful

Brian: Goal was to have a uniform challenge look and feel whatever the card brand, and whether native app, HTML app, or browser

Sachin: You said that for apps, that the UX is managed by the SDK...
... is that flow also available on the Web?

Brian: In the current iteration, no.

shift4sms: How do you whitelist all issuers in the world?

Christiaan: My web page will not accept the iframe

[Passcode entry template]

[ingle select template]

<JK> wanted to highlight that the current version of the 3ds 1.0 protocol will be live till early 2020.

[Multi-select template]

[Out-of-band template]

Christiaan: Is there polling?

Brian: Currently not, but it has been discussed for future iterations

Christiaan: Can I just put a meta refresh in my page? or XHR?

Brian: Could; but currently does not

@@: In the native case, is the page challenge rendered still HTML?

Brian: No, SDK manages it

Christiaan: Is that what Apple is using?

@@: If SDK-based what stops merchant from slurping up all the credentials?

Brian: that's one of the known security issues. We have 4 separate security reviews; involves merchant validation
... there is an IETF best practices doc that requires for OAUTH to use new Safari view-controller or windows token broker

Manash: We have identified some areas to look more into:

• Merchant pain points
• Technology evaluation and business evaluation to solve those pain points
• We need to engage with different groups to see whether it makes sense to have 3dDS 2.0 as part of w3c work, and if so how we take the next steps.

RESOLUTION: Manash will chair a new 3dS task force in the WPWG for next steps

Manash: I will need support from browsers and merchants and merchant platforms

<andrelyver_> Happy to help