Re: [Minutes] 4 Mar 2020 card payment security task force call

On Thu, Mar 5, 2020 at 9:03 AM Ian Jacobs <ij@w3.org> wrote:

>
> > On Mar 5, 2020, at 5:30 AM, Adrian Hope-Bailie <adrian@coil.com> wrote:
> >
> > Hi all,
> >
> > Sorry I couldn't join this call.
> > With regard to the cross-origin PH installation, would this flow work?
> >
> > Assuming there is:
> >  1. an "Add Card" payment handler hosted on the "src.org" origin
> >  2. SRC system payment handlers at "src-system1.com" and "
> src-system2.com" origins
> >
> > Flow:
> > 1. The user invokes the "Add Card" PH which calls openWindow and shows a
> UI hosted under the src.org origin.
>
> Hi Adrian,
>
> I think the observation was that the add card payment handler could not be
> installed “just-in-time” if it was referenced by the payment method
> manifest of src-system1.com.


A tiny clarification: ... if it was *only* referenced by the payment method
manifest of src-system1.com, then JIT is not possible. The only solution to
enable this flow is to change the browser, but needs a security discussion.

If src.com also hosts a payment method manifest, and merchants also include
src.com PMI in their request, then the JIT flow would work. This is the
second option from here:
https://github.com/w3c/src/wiki/ProposedArchitecture#Installation-of-multiplexing-handler-from-another-origin

I read Adrian’s original email as the latter, but realize now that it’s
actually ambiguous...


>
> One proposed idea is to have a PMI for the Add Card payment, whose payment
> method manifest can refer to it from the same origin.
>
> Ian
>
> > 2. The use captures their card details and depending on which network
> the card is from the PH submits these to a server at the appropriate SRC
> system which returns a redirect URL.
> > 3. The user is redirected to a page hosted at either "src-system1.com"
> or "src-system2.com" origin. (Part of the data passed in the redirect is
> a context identifier that is used when the SRC system redirects back later)
> > 4. The user enrolls their card on the SRC system which installs the
> necessary Payment Handler from that origin
> > 5. The user is redirected back to a page on src.org along with the
> context identifier allowing the "Add Card" payment handler to continue
> where it left off (re-establish comms with the service worker via
> PostMessage) and return a response to the calling page via
> PaymentRequestEvent.
> >
> > The SRC payment handler is now installed for the enrolled card (even
> though this initial response was proxied via the add card PH the first
> time).
>
> --
> Ian Jacobs <ij@w3.org>
> https://www.w3.org/People/Jacobs/
> Tel: +1 718 260 9447
>
>
>
>
>
>