Card Payment Security Task Force

01 May 2019



Ian Jacobs (W3C), Dean Ezra (Barclays), David Benoit (Reach), Jalpesh Chitalia (Visa), Rouslan Solomakhin (Google), Mark Cline (Visa), Laura Townsend (MAG), Ramesh Gorintla (Discover), Matt Detert (MAG), Jonathan Grossar (Mastercard), Ken Mealey (American Express)


SRC notes for discussion

IJ: Who reviewed it? (Jalpesh, Rouslan did)

<Zakim> rouslan, you wanted to give some initial feedback

rouslan: Overall, looks about right. I like the idea of launching 3DS from inside the payment handler, and also recognize the use case where merchant does so.
... but in the payment handler modal window, good place to do 3DS
... I have a question about user consent to install a payment handler

IJ: JIT payment handlers don't get events

Rouslan: In current world, merchant trusts apps and allows those apps to present UX to the user
... so JS on merchant site can run and do things.
... in payment request and payment handler land, it is analogous. merchant indicates supported payment methods
... I would not want to introduce a prompt "Would you like to install visa checkout"
... if the merchant is ok with the payment handler, it should be ok for the handler to get data

Rouslan: it is true that canMakePayment() does not fire until there is user interaction
... so we have protections about silently listening to things

jalpesh: I did not read the text as harshly as Rouslan is describing. I believe the intent was to leave the implementation to the user agent, and this was also general (not specific to SRC)

deanezra: I also read it to mean "when they press the pay button, and they select handler, that's the "consent"

rouslan: It sounds like people are in alignment with the current Chrome implementation, so should not be a problem.

Ian: Want to help improve the wording?

rouslan: I will think about it.

jalpesh: I'd like to speak to the 3DS piece as well
... I would like to call it "assurance"...will be done at the DCF level
... how the assurance happens is up to the SRC system.

Jonathan: If the merchant asks to use 3DS we would use 3DS

Jalpesh: Does a merchant ask for "auth" or "3DS"
... if the merchant asks for "auth" that can be implemented in different ways by the SRC system.

IJ: So in the "goals" change "3DS' to "assurance"?

Jalpesh: But the merchant still may wish to choose 3DS

IJ: Proposed to refer to "assurance "in goal (mention 3DS) and also in design considerations to call out 3DS as an explicit choice

Jalpesh: Ok by me.

IJ: I hear "allow for other protocols" and also "3DS must be explicitly nameable"

Jalpesh: Thanks for beginning to write these things down; this looks much better after several weeks of discussion.

IJ: Any other first-pass comments?

Ramesh: I agree with the point about assurance abstraction and 3DS as one instance

Jonathan: Do we refer here to the identification of the customer?

IJ: Is it part of the SRC w3c document or just SRC?

Jalpesh: I think the customer identity is not part of this wiki.

Jonathan: We assume that the consumer will be identified by the payment handler

<scribe> ACTION: Ian to start a new section of the SRC wiki on assumptions, including customer identity out of scope

<Zakim> rouslan, you wanted to ask whether payment handler would authenticate the consumer using webauthn / oauth 2.0 / and so on.

rouslan: Do people expect the payment handler to identify the user using Webauthn or OAUTH?
... e.g., allow the user to get the email address...is that what people expect payment handlers to do?

Jalpesh: I think that's a broader question than just SRC. But in the SRC context, at a minimum we'd like the payment handler to receive some sort of unique session id.
... we want payments to work, for example, whether the user is logged into their gmail account or not
... WebAuthn *might* suffice
... How the payment handler identifies the user is up to the payment handler.
... I heard Rouslan asking specifically whether the expectation was the use of WebAuthn and/or OAUTH
... I think if a session / device identifier is available that would suffice
... my understanding (and JG) is that WebAuthn would not alone suffice.

Jonathan: The payment handler could use Oauth today and use the identity through that flow. I don't think WebAuthn will yet work to collect user identification.

Jalpesh: So I suggest we leave "out of scope"

Rouslan: +1

IJ: So I am hearing "how the payment handler identifies the user for SRC transactions" is outside the scope of this document.
... we would point to good practice

rouslan: I think you captured the point

<Zakim> rouslan, you wanted to ask Ian when privacy / security / TAG reviews happen?

rouslan: When should we get TAG / privacy review.

IJ: We got TAG and privacy review before the first CR
... +1 but we should down a bit more

<Zakim> rouslan, you wanted to say OK to write down more, but suggest that the reviews should be light weight, if possible.

rouslan: I think it's fine to write more down to frame the topic; I have seen text saying even an explainer can be reviewed by the TAG
... I'd prefer that this not be called a "review" but something lighter-weight...put information on their radar.

IJ: Do we need supportTypes?

<jalpesh> Sorry joining back on phone

IJ: Do we need tokenUsageType?
... Any other matching type data for this method?

Jalpesh: I did not yet get through input/output details. I need to spend more time on that; will provide feedback next week.
... my initial thought is that supportedTypes might be useful but also adds complexity and we may not need for version 1
... Interesting from feature perspective, maybe not for v1

lte_: In a situation of a credit transaction, that transaction will route through SRC to the appropriate system.
... it has to go through the owning system
... in a debit scenario, merchants may want to route internally
... at what point does / can a merchant make a decision for routing purposes

jalpesh: Here's my Visa-specific response. Any SRC credential will have the same transaction processing flexibility as basic card. The merchant does not need to provide that information before the SRC call.

lte_: Once tokenized, you lose ability to route on an alternative network.

Jonathan: I would have to double check, but I think it's likely the same as Visa..I will check.

IJ: I am hearing from Visa that there's no implication that "getting a token" means necessarily cannot make routing choice.

lte: How is PAN determined for routing choice?

Ramesh: No comment at this time.

lte_: If a token is passed, I don't know where in the process a decision is made "debit" or "credit" for routing purposes.

<scribe> ACTION: Jonathan to look into answer to lte's question about routing flexibility wrt Mastercard tokens

<trackbot> Created ACTION-115 - Look into answer to lte's question about routing flexibility wrt mastercard tokens [on Jonathan Grossar - due 2019-05-08].

lte: I would like to see a write-up of where during or after the (SRC) flow decision can be made re: routing

Jalpesh: For Visa, if credit or debit is returned, existing routing choices apply.

lte_: There is no routing option for tokens today.

Jalpesh: We do have routing options with tokens today; we can chat more offline about this.
... in-app is consistent with in-store

Ramesh: I think there are multiple options here. In an SRC world, mostly the default behavior is likely to be a token. The merchant might also say "I can handle PCI data" so perhaps the SRC system should be able to yield the PAN as well.

IJ: Would that be part of an SRC system?
... is there an input preference bit?
... dynamicDataType?

Jalpesh: Yes, we can have a merchant preference bit in input

benoit_: I agree tokens can be a pain to deal with notably for routing...would it be possible for the merchant to provide a public key when setting up the SRC interaction and say "I want encrypted card info"

IJ: +1 to orthogonal concerns (1) encryption (2) what data you get back

Next meeting

15 May

Summary of Action Items

[NEW] ACTION: Ian to start a new section of the SRC wiki on assumptions, including customer identity out of scope
[NEW] ACTION: Jonathan to look into answer to lte's question about routing flexibility wrt Mastercard tokens

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/05/01 21:33:48 $