Card Payment Security Task Force

Action item review

Ian: I will try Mike West again next week to see if he will come to a meeting to talk to us about the Credential Management API

Lawrence: Which credentials do you get through that API?

Ian: I think intent is mostly name/password or other auth credentials but I'm not sure.

Summary of different ways to get credentials from previous call:

- user identity is established directly with the payment handler

- asks the browser for info about user identity

- delegation

deanezra: merchant passed data?

Jalpesh: This is broader than SRC

Benoit: To facilitate payment in an SRC context (once you've chosen payment handler)
... what identity information would be needed to be passed back through payment request to the merchant

Ian: This is about payment handler using identity to get instruments

deanezra: That is where identity will be a problem. There's an interaction where SRC goes to the acquirer and you have to prove the user is who is....

<jalpesh> +1

lawrence: I had the same question

jalpesh: I agree with that. It is payment handler's responsibility to establish user identity.
... it's up to the payment handler how they will do that
... expecting payment handler to rely on the merchant feels difficult to me
... for one, merchants might not want to share information about their customers with other parties
... second, the payment handler can establish identity (because they have relationship with the consumer)

deanezra: In the case of WebAuthn, you could have the payment handler be the relying party
... but the bigger issue is doing it again for every card that comes from each different bank.
... you can't pass web authentication from one origin to another.
... the expectation is you log into the payment handler and expect your cards to appear.
... but would the handler need to ask each bank to authenticate?

lawrence: I think it's a bank decision.
... I'm pretty sure that any bank would say "in order for me to release a card; I need to be absolutely sure ... and that is likely to mean the bank will ask the user to log in... especially under GDPR"

deanezra: I think this is an open question
... does SRC mean that N logins will be required?

lawrence: there is a regulatory angle as well as a liability angle

jalpesh: To me, the ability of an SRC system to present a step-up. That's optional from an SRC specification perspective. The SRC gets data and determines whether to do the step up
... I agree that "3 cards from 3 banks" does create a tricky situation. Even if the hint was provided by the merchant, it's still complex to use within an SRC system if there's not a sufficient level of confidence in the payment handler

deanezra: This will be a common issue with payment handlers, right?

jalpesh: Payment handlers can have an established process for how they assert identity. And that process can be established and understood with the SRC system.

deanezra: Is that in place?

jalpesh: The aspect of merchant providing a hint without any assertion, that will become more complicated for getting the list of cards.
... the assertion has a JWT format
... the identity provider is an SRC system..that may in turn need to be extended to additional trusted entities
... if we extend to merchants, then we complicate the PH abstraction if every merchant needs to know the src system
... I think for our SRC system it would be a security issue...whether payment handlers trust merchants and how they do so

benoit: Question about these step-up notices from issuing banks.
... isn't the step up only required upon selection of card (not just display of list of cards)

lawrence: Need some authentication before returning list of payment handlers
... we need to look into GDPR about whether regulators would be comfortable with returning a list without auth

stpeter: My read of the SRC spec is that, yes, there would be a binding step before all that happens
... random people won't be able to make requests on my behalf

lawrence: I agree

<Benoit> agree

lawrence: so the question is: as a consumer, I need to do the security check and probably need to do one time per issuer
... it would be helpful to map out the flow for a "new to SRC payment handler" user
... and determine what a consumer has to do to make a payment
... if we think there's too much friction, we could look for solutions to reduce friction

jalpesh: +1

<deanezra> +1

Jalpesh: Agree there are multiple flows: card entry, card selection
... the payment handler does a binding to an identity at the time a card is entered
... the payment handler presents binding to the SRC system
... once that's done, on repeat purchase, the payment handler provides the same identity to the SRC system and the system would consistently provide the same card or list of cards

<scribe> ACTION: Jalpesh to create flow descriptions for how the user journey would work for SRC payment handlers

See previous flow diagrams.

<trackbot> Created ACTION-124 - Create flow descriptions for how the user journey would work for src payment handlers [on Jalpesh Chitalia - due 2019-07-31].

deanezra: On the hint from a merchant. it sounds like it was a request. Do we have a sense of how real that is?

IJ: Mastercard mentioned it last week

deanezra: It would be good to hear from merchants on this

Editor's note: Created Issue 23 after the call to track the flow diagrams around user journey with SRC payment handlers.

TPAC agenda

https://github.com/w3c/webpayments/wiki/FTF-Agenda-201909

Jalpesh: POC is a great outcome.
... what's next step after Mastercard demo?

IJ: Demo that shows usage of the spec

Jalpesh: Would be great to have browser participation
... or some other payment handler

lawrence: +1 to a POC..
... regarding the question of reaching the larger audience, a POC will help with the technical points, but if we think about how to measure success of this work,
... is whether consumers click on the button? Will merchants integrate?
... so I think consent from the broader audience involves answering the question of how to get more merchants and users to be more comfortable with this.
... can we go back to the questions of "what problems are we trying to solve"?
... and who are the target merchants?
... I think it would be good to list the problem statements and be able to show that we are ticking them off.

Next meeting

7 August