Re: Payment App API: updated flow description

This thread, which was started between a few members of the Payment Apps TF
has some relevance to an issue now being discussed at length on the
lists[1].

As such, I am copying the list to ensure we have it publicly available as
part of the discussion.

[1]  https://github.com/w3c/webpayments-payment-apps-api/issues/48

On Fri, Jan 13, 2017 at 7:28 PM, Jason Normore <jason.normore@shopify.com>
wrote:

> > Without a manifest file we are forced to get app meta-data by executing
> a registration script before registration to see what data it might provide
> if we ran the registration. Yuck.
>
> I strongly agree with this statement and is the main reason I was a
> proponent of the separate payment app manifest that defines the extra
> information required to display and instantiate or install it (pointer to
> service worker js). BUT I think this statement in the proposed changes
> takes care of this: "To recommend a payment app, a merchant provides a
> payment app identifier (PAI), name, and icon information.". I actually like
> this better because it gives more control to the merchant.
>
>
> Jason
>
> On Fri, Jan 13, 2017 at 10:15 AM Ian Jacobs <ij@w3.org> wrote:
>
>>
>> > On Jan 13, 2017, at 9:07 AM, Adrian Hope-Bailie <adrian@ripple.com>
>> wrote:
>> >
>> > Two concerns with the proposed approach:
>> >
>> > 1. Browsers index service workers based on the scope URL not the script
>> URL so we risk having multiple payment apps that conflict in scope and
>> therefor cannot co-exist.
>>
>> That sounds like a reasonable statement and I don’t know enough about
>> service workers:
>>  https://www.w3.org/TR/service-workers/#model
>>
>> AdamR made the point that we should talk with service worker experts to
>> ensure we get this right. :)
>>
>> > 2. Without a manifest file we are forced to get app meta-data by
>> executing a registration script before registration to see what data it
>> might provide if we ran the registration. Yuck.
>>
>> Why do you need to know “what it might provide”?
>>
>> What is the difference between getting the manifest data from a file and
>> getting the manifest data via a script?
>>
>> For me the difference is “we already have tools in place to do it via a
>> service worker install event” and don’t need to ask the browser to invent
>> anything new.
>> >
>> > I agree that derived URLs are also ugly so perhaps we should be
>> consistent with the approach for Payment Request and have the identifier
>> URL return the manifest (a JSON file) and also support link headers for
>> getting the payment app URL without downloading the manifest.
>> >
>> > So there are two URLS:
>> >
>> > 1. The service worker scope and manifest file URL are the same.
>> > 2. The service worker script is at another URL which is listed in the
>> manifest and also available through link relations headers (consistent with
>> PR).
>>
>> Maybe we should get on a call to work through this. As a last resort I
>> will put this on next week’s Payment App TF agenda.
>>
>> Meanwhile, I’ll ping Jake Archibald.
>>
>> Ian
>> --
>> Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
>> Tel:                       +1 718 260 9447 <(718)%20260-9447>
>>
>>
>>
>>