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
15 May