RE: [Minutes] 13 November Card Payment Security Task Force call

Hi Adrian,

Thank you for sharing your thinking on the subject. It’s always good to learn about another perspective.

I believe the approach you’re suggesting leads to the very problem of “wallet/brand selector” that we want to avoid. In your example where merchant/SRCI constructs PR request with 3 PMIs referring to 3 distinct SRC Systems. Eventually that results with 3 payment handlers becoming available for the consumer to choose (MA, V and Amex). This is “wallet selector” or “brand selector”. We don’t want consumer to select a card brand or PH/wallet to pay with. EMVCo SRC is standard for remote commerce payments with the card so we believe consumer should be simply given choice of the card and nothing more.

In my opinion consumer should see single SRC-branded PH to pay with or even better all cards enrolled into any supported SRC System if the device can be recognised (=recognised returning user). I agree the former is PH distribution problem that we need to resolve, the former is simply not supported by the existing primitives in the browser i.e. Google Chrome.

Best Regards,
Tomasz

From: Adrian Hope-Bailie <adrian@coil.com>
Sent: 15 November 2019 10:35
To: Ian Jacobs <ij@w3.org>; Rouslan Solomakhin <rouslan@google.com>
Cc: Web Payments Working Group <public-payments-wg@w3.org>
Subject: Re: [Minutes] 13 November Card Payment Security Task Force call


CAUTION: The message originated from an EXTERNAL SOURCE. Please use caution when opening attachments, clicking links or responding to this email.


Hi all,

Sorry I couldn't join the call.
The time changes due to DLS have resulted in conflicts for me with meetings rooted in UTC.

Having reviewed the minutes I wanted to make a few points that may or may not be obvious:

 - The requirements imposed on a payment handler that purports to "support SRC" are defined by the payment method owner (EMVCo?) and enforced through the payment method manifest.
 - If there is a requirement that "Any SRC payment handler can enroll a card in any SRC system." then it would be up to the SRC payment method owners to devise a way to verify this for any payment handlers that wish to claim support for SRC and enforce it by including those handlers in the "allowed list" of the manifest.
 - Payment handlers are just code. It is possible that a single publisher (from a single origin) installs multiple payment handlers into a single browser (e.g. one per instrument) if that's desired. @Rouslan Solomakhin<mailto:rouslan@google.com> may tell me I'm wrong here.

It has been my understanding to date that the likely publishers of a payment handle that supports SRC will be SRCIs and DCFs, is that correct?

On that basis my suggestion would be the following:

 - Each SRC system define a unique URL based payment method identifier for SRC and should host a payment method manifest for SRC that is discoverable from that PMI URL
 - Each SRC system will define requirements for payment handlers that claim to support SRC and will only list handlers they have vetted in their own manifest
 - Each SRC system MAY define a default payment handler that will be used to bootstrap a user's browser in the case that they have no SRC supporting payment handlers installed.
 - Merchants that accept SRC will explicitly list the SRC systems from which they accept SRC by constructing a payment request with all of the PMIs form all of the SRC systems they support.

 - SRC systems can (outside of W3C) coordinate their efforts to define payment handler requirements and mechanisms for verification of payment handlers against those requirements
 - As such, it could be that the list of "approved" payment handlers is the same in all SRC system manifests however how this is coordinated (and whether these are super-sets of the shared list or simply exact copies) is outside the scope of what W3C and the browsers need to worry about.

For a user that has a fresh new browser and lands on a merchant page that supports SRC from 3 SRC systems (e.g. visa, mastercard, amex) the following happens:
(Let's also assume that the merchant acquirer is an SRCI and has their own PH)

1. The merchant constructs a PR with 4 PMI's (one for each SRC system and one with the PMI that is purely for their acquirer/SRCI's payment handler): e.g. https://visa.com/src<https://urldefense.proofpoint.com/v2/url?u=https-3A__visa.com_src&d=DwMFaQ&c=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY&r=gGO7JtsSyntBU-GDdHDB4l3lQwFRpuFyuge3kx2OlvY&m=he9AbNuUHZlbbJTWeZlUmUxndMit-2An2NmnLhI2ebI&s=2oj4MxllHTlBVcTUX-Y6E2UlcdYRbB6pxmmpa4LsDWU&e=>, https://mastercard.com/src https://amex.com/src<https://urldefense.proofpoint.com/v2/url?u=https-3A__amex.com_src&d=DwMFaQ&c=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY&r=gGO7JtsSyntBU-GDdHDB4l3lQwFRpuFyuge3kx2OlvY&m=he9AbNuUHZlbbJTWeZlUmUxndMit-2An2NmnLhI2ebI&s=GtYPaskceGVqWV_D9rXstNTiHuHyvrxoTzMJAWeMGZk&e=>, https://stripe.com/src<https://urldefense.proofpoint.com/v2/url?u=https-3A__stripe.com_src&d=DwMFaQ&c=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY&r=gGO7JtsSyntBU-GDdHDB4l3lQwFRpuFyuge3kx2OlvY&m=he9AbNuUHZlbbJTWeZlUmUxndMit-2An2NmnLhI2ebI&s=yimeeXCU6sa_7hdaCOym9mpA1_q9HOeI7EZ0pRJamfc&e=>
2. The browser is able to asynchronously discover and process the manifests for each of these before the user even hit's "Pay"
3. Assuming each manifest has a default payment handler defined the user will get prompted to pick one.
4. The user picks a PH and from there it's up to the PH to handle enrollment and handling the payment

Step 4 above could involve asking the user to select a DCF?

I may have this completely wrong but wanted to point out that there are a lot of options if you leverage the existing primitives the browser is already providing.

Adrian


On Wed, 13 Nov 2019 at 20:32, Ian Jacobs <ij@w3.org<mailto:ij@w3.org>> wrote:
Hi all,

Minutes from today’s discussion on user experience assumptions and requirements related to SRC:
 https://www.w3.org/2019/11/13-wpwg-minutes<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_2019_11_13-2Dwpwg-2Dminutes&d=DwMFaQ&c=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY&r=gGO7JtsSyntBU-GDdHDB4l3lQwFRpuFyuge3kx2OlvY&m=he9AbNuUHZlbbJTWeZlUmUxndMit-2An2NmnLhI2ebI&s=jYd8WEYTPcTStvM79z5doGP0betLqBrSHOozqCxjihU&e=>

Next call: 27 November

Ian

--
Ian Jacobs <ij@w3.org<mailto:ij@w3.org>>
https://www.w3.org/People/Jacobs/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_People_Jacobs_&d=DwMFaQ&c=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY&r=gGO7JtsSyntBU-GDdHDB4l3lQwFRpuFyuge3kx2OlvY&m=he9AbNuUHZlbbJTWeZlUmUxndMit-2An2NmnLhI2ebI&s=GiDRYkdniW4S72I19-cBEihGif9MuUrWNwMDRjrEe0E&e=>
Tel: +1 718 260 9447




CONFIDENTIALITY NOTICE This e-mail message and any attachments are only for the use of the intended recipient and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, any disclosure, distribution or other use of this e-mail message or attachments is prohibited. If you have received this e-mail message in error, please delete and notify the sender immediately. Thank you.