3DS Task Force

Agenda

[Draft] 3-D Secure 2 with Payment Request API

Draft spec

IJ: Anybody look at the document?

stpeter: Not yet.

IJ: Brian, please send me merchant data

Brian: I have started this; WIP

MikeH: Are we looking at the browser as a 3DS requestor?
... and the merchant is providing a minimum set of data required for the browser to then invoke a message?

IJ: Today assuming (in short run) that it will be third-party payment handler
... rather than the browser

Ken: I did hear interest in Singapore and intend to pursue

IJ: I am also interested in how WebAuthn fits into this topic, even if it's not the focus of this specification.

https://github.com/w3c/webpayments/wiki/FTF-Oct2018

Mike: Looking at response example in section 2.2 you have eco, av, transStatus.
... we also need a DStransactionID

scribe: but there may not be a DSTransactionID if payment handler works directly with the issuer

IJ: Use case of issuing bank is the payment handler distributor
... but in that case, 3DS may not be invoked at all

Brian: If there is no 3DS Server, it's not 3DS.

IJ: So what bit do we need if this is 3DS?

Mike: Amex will need a DSTransactionID

Brian: That's potentially part of the output.
... we need DSTransID

<scribe> ACTION: Mike Horne to identify any other response data

<scribe> ACTION: Ian to add DSTransID to the spec

Prototyping

IJ: Is it time? Too early? What do we need to get to that point

Adam: The main thing is to have a 3DS2 thing to work against
... I have had that there might be some networks ready to pilot
... would be great to be put in touch with anyone who is ready to pilot
... to have a DS that does 3DS2 that we could prototype against

IJ: Would be great to be able to show something at TPAC 2018

<scribe> ACTION: Ian to reach out to browser vendors to organize a chat in July to see if any new thoughts on 3DS, and to share the draft spec.

(Ian will aim for 25 July)

https://github.com/w3c/payment-handler/issues/298

Adam: There's a relationship between that issue and any fingerprinting that we need to figure out.

User preference for strong auth?

IJ: Should we update the spec to add mention of a user preference for strong auth (rather than data sharing)?

stpeter: May need some user research on this
... some people strongly prefer convenience, others are more privacy-centric
... we should be sure to talk to people about the sliding set of values that align with behaviors
... but in general I like your suggestion

<scribe> ACTION: Ian to raise an issue about representation of user preference in the spec

Ian: I will add a hook to the spec

stpeter: And I will raise this issue internally at Mozilla

Next meeting

25 July