W3C

3DS Task Force

22 Aug 2018

Agenda

Attendees

Present
Ian, stpeter, asolove, Jonathan, jimmy_wardrope
Regrets
Ken
Chair
Ian
Scribe
Ian

Contents


<scribe> Scribe: Ian

check in on Adam Solove review

https://github.com/w3c/3ds/issues/8

asolove: I reviewed the spec and compared to our internal implementation and documentation from our provider
... asked what cases, data, are missing from this spec

https://w3c.github.io/3ds/index.html

scribe: one thing I note is

a) Is 3ds required or not

b) If 3ds is required, is a challenge required?

scribe: they are not the same thing
... we either need more values or two flags with the necessary values
... what happens in the sheet (e.g., address) might change the merchant preference on the fly for "required" v. "optional" v. "don't do 3ds"
... the spec talks about data that the merchant needs to provide
... or that the payment handler needs to gather from the user
... 3DS requires shipping address if for physical goods. ... so we may need to pass the shipping address to the payment handler, or the payment handler may need to show UI to the user
... in short the 3DS spec may not speak to this data directly but will need to require that it be available
... e.g., email and some phone number

IJ: We may need to discuss this around payment-handler...requests for browser-stored data.
... that topic has come up previously

asolove: Moving on...payee data will depend on existing relationships
... there's 3ds data and may be extra network-specific data
... here are things that the merchant is likely to provide: order number, merchant id, acquirer id, acquirer merchant id, merchant name,

opt in to encrypted or tokenized card number

scribe: 'merchant id' is the network's id for the merchant; their acquirer may have a different id for the merchant (also to be included)
... the spec also allows the merchant to opt-in to encrypting the PAN in the response or getting a tokenized card
... some of these may be optional in 3DS for payment handlers

IJ: We have a transaction id through PR API; likely different from order id

stpeter: It seems to me that there might be other data of interest
... e.g., item data

asolove: I only went through and looked at the "absolutely required for 3DS2"
... but there's a long list of optional data.
... it may not be worth enumerating yet

jonathan: I will send data I gathered that is necessary for merchant identification

[Returning to use cases]

asolove: One case - merchant wants to do 3DS and if they do it, they want the issuing bank to do a challenge
... e.g., for high-value transaction

Another case - merchant says "If the bank is willing to do 3DS, that's fine, but no step-up"

Another case - merchant needs to do 3DS and don't want challenge flow

scribe: those cases lead to some observations about response data as well

Cases:

===

(See Cardinal's 3DS2 result test cases)

if we add a requestLevel=never3DS, then returned data shape is different

is the shape of returned data then specified by the host payment method?

if there's an error during 3ds, or ACS is unavailable or times out

if 3ds required, handler should prompt for another form of payment

if 3ds not required, handler maybe falls back to returnign card/token without performing 3ds.

there are lots of case intersections, for example:

if 3ds is required but merchant specifies frictionless, what do we do if frictionless denied?

give up and ask for another payment method from the customer?

try 3ds again and allow a challenge?

===

asolove: It might be interesting for payment handlers to handle some of these cases in a standard fashion, and to enable merchant to configure behavior.
... so if the merchant says "I never want 3DS" then the response data will not be there
... if there is an error or timeout, then we have some more cases
... if 3DS is required but there's error, there are questions about whether the error should be exposed to the merchant, or whether the payment handler should retry() before going back to the merchant
... or if there is an error and 3DS is not required, then perhaps the payment handler should be able to try another card
... if we split our options into "is 3DS required?" and "is challenge required?"

IJ: My gut response is that the merchant should regain control

asolove: It's possible for PR API to fail due to lack of match, or from the user canceling, but this is the first example where the payment sheet can fail partway through the transaction based on a third party response. Should the handler own the error and offer a retry? Or should the handler return data to the merchant?

jonathan: What are failure modes specifically? E.g., OTP password error?

asolove: That's one case, although in that case the customer probably understands.
... I am more interested in cases like ACS times out or is unavailable, so something that is invisible to the user
... 3DS protocol fails behind the scenes before the user sees something from the issuer.

IJ: What happens today between, say, merchant and Stripe when these things happen?

asolove: See the Cardinal docs....there are dependencies on network or others
... e.g., in some failures, the merchant is prohibited from doing anything with card data after failure and must request a new payment method.
... there are some use cases where there are partial successes...
... or some cases that are much rarer such as ACS time-out
... and a few others that are not exactly a failure
... in these cases it's up to the PSP or merchant whether they can use the card data "without 3ds" and use the card data to authorize payment

IJ: Do we need more response data ?

asolove: We could add two more flags to let the merchant know what case they are dealing with

<scribe> ACTION: asolove to mention in his post flags we could add to response data to give merchant more information about what their options are after some edge cases of partial success or failure

asolove: the section on privacy and data gathering is important
... the big question is what will browsers implement, what will payment handlers do, and how to comply with the 3DS spec via method_url custom fingerprinting mechanism that browsers could provide
... the method_url is the fingerprinting script that the issuing bank runs in the merchant page

IJ: 23 October "auth" discussion at TPAC
... I am meeting with Adam Powers today to discuss TPAC agenda

jonathan: I think we need to agree on use cases we want to cover
... need a session on leveraging device info from web authn
... need a session on tokenization
... there are a few tracks

<scribe> ACTION: Jonathan to write up a proposal for how to organize TPAC discussion around 3ds, tokenization, authentication

asolove: Do we have anyone who has customer relations in the payment space who is interested in the webauthn space?
... some issuing banks?
... I'd love to work with a bank or klarna

IJ: At TPAC - bank of America, barclays, capital one, klarna, worldpay
... should I make an introduction?

asolove: Yes, let's take to email

Next call

5 September

Summary of Action Items

[NEW] ACTION: asolove to mention in his post flags we could add to response data to give merchant more information about what their options are after some edge cases of partial success or failure
[NEW] ACTION: Jonathan to write up a proposal for how to organize TPAC discussion around 3ds, tokenization, authentication
 

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/08/22 16:05:00 $