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

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://mastercard.com/src https://amex.com/src,
https://stripe.com/src
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
>
> Next call: 27 November
>
> Ian
>
> --
> Ian Jacobs <ij@w3.org>
> https://www.w3.org/People/Jacobs/
> Tel: +1 718 260 9447
>
>
>
>
>
>