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

Hi Tomasz, Jalpesh,

The basic primitive for this API is payment handlers.

> 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)

If EMVCo wants users to only have a single option then it should publish
that single payment handler and each SRC system should specify that PH as
the default in it's manifest.
In this case you'd have the benefit of the "skip-the-sheet" and JIT
features so if the PR only lists SRC systems as supported payment methods
the user will be taken straight into that payment handler.

The point is, you are looking for some common functionality for all SRC
systems to bootstrap the user into their specific DCF published PH for
future payments.
This common functionality should be published as a payment handler, not
built into the browser.

> [this] is simply not supported by the existing primitives in the browser
i.e. Google Chrome.


I don't think this is true, have you tried writing a single generic SRC
Payment Handler that is the default for all SRC systems?

I assume once this common payment handler is invoked the idea is for the
user to identify themselves to the handler which can go and find the known
instruments for the user OR the user begins enrolling by providing their
card details?

At this point I think you expect to be able to pick a specific DCF that you
want to invoke (provided by the SRC system that the users card is issued
by?) and for that different handler to take over?
(I'm still confused by the DCF model without having any examples of who can
be a DCF and what capabilities they have to load user's instruments from
various SRC systems)

Another clarifying question:
As a user visiting a merchant for the first time with no payment handlers
installed what do you expect me to be prompted with?
E.g. Assume the merchant accept Googler Pay, Apple Pay and SRC, I should
have 3 choices: Google Pay, Apple Pay and << INSERT OPTION HERE>>
I assume this could be "EMVCo SRC" but that's not very useful to users, so
what would it be?

Adrian


On Fri, 22 Nov 2019 at 13:51, Blachowicz, Tomasz <
Tomasz.Blachowicz@mastercard.com> wrote:

> 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
> <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> 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>
> 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.
>