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

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

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

Received on Thursday, 5 March 2020 14:03:24 UTC