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

On 2019-11-19 13:09, Adrian Hope-Bailie wrote:
> Clarifying question:
> 
> (I have asked this before but so far have no answer so it's hard to fully understand how you envision SRC working)
> 
> What entities do you envision publishing payment handlers?
> Are these companies that we would call "wallets" today like PayPal, Google Pay etc?
> Would the networks (SRC systems) each publish a payment handler?

Isn't this kind of a generic problem with Web based payment handlers?
Pre-provisioning potentially 100 000 (one for each bank), effectively "empty" wallets?

Maybe I'm just stupid, but I don't understand how this is supposed to work except maybe[*] for a handful of giants.

Anders

*] If they "retire" their current, AFAICT, quite versatile native wallets.
> 
> 
> On Sat, 16 Nov 2019 at 01:46, Chitalia, Jalpesh <jchitali@visa.com <mailto:jchitali@visa.com>> wrote:
> 
>     Hi Adrian, ____
> 
>     __ __
> 
>     Thank you for your comments.  in your example when merchant invokes 4 PMIs, issues exist with following use cases:____
> 
>     __ __
> 
>      1. If the consumer is recognized by one or more PH, they’d still be first selecting the PH before they can select an instrument. ____
>          1. that can result in back and forth UX if they choose on PH1 but the instrument they want to pay with is in PH3.____
>      2. Consumer is recognized by one of the three PHs (e.g. Visa DCF), the orchestration across other DCFs is not possible (??) to fetch list of all instruments upfront. ____
>      3. If the user is not recognized or for a recognized user there are no instruments, consumer must select a PH before they can add one.  Depending on instrument they add, this may need switching back to another PH. ____
> 
>     __ __
> 
>     I am thinking phone conversation will be simpler than emails.  Happy to find time offline in convenient timezone.  Including @Grossar, Jonathan <mailto:Jonathan.Grossar@mastercard.com> @Blachowicz, Tomasz <mailto:Tomasz.Blachowicz@mastercard.com> in this discussion.____
> 
>     __ __
> 
>     -jalpesh____
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     *From: *Adrian Hope-Bailie <adrian@coil.com <mailto:adrian@coil.com>>
>     *Date: *Friday, November 15, 2019 at 1:36 AM
>     *To: *Ian Jacobs <ij@w3.org <mailto:ij@w3.org>>, Rouslan Solomakhin <rouslan@google.com <mailto:rouslan@google.com>>
>     *Cc: *Web Payments Working Group <public-payments-wg@w3.org <mailto:public-payments-wg@w3.org>>
>     *Subject: *Re: [Minutes] 13 November Card Payment Security Task Force call
>     *Resent-From: *<public-payments-wg@w3.org <mailto:public-payments-wg@w3.org>>
>     *Resent-Date: *Friday, November 15, 2019 at 1:35 AM____
> 
>     __ __
> 
>     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://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 <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
> 
>         Next call: 27 November
> 
>         Ian
> 
>         --
>         Ian Jacobs <ij@w3.org <mailto:ij@w3.org>>
>         https://www.w3.org/People/Jacobs/
>         Tel: +1 718 260 9447
> 
> 
> 
> 
>         ____
>

Received on Wednesday, 20 November 2019 05:34:10 UTC