Re: PMI Proposals and Discussion Tomorrow

Hi Zach,

Thanks for putting this together. I won't be on the call today unf so here
are a few comments from my side:

1. I have a strong aversion to the default behavior for browsers, when
encountering a payment method identifier URL, being to block apps from
other origins. The ability to limit the payment apps that are allowed for a
payment method should be opt-in not opt-out. We have no legacy of existing
apps and methods that we need to cater for or that will break by making
this opt in. Anyone publishing a payment method will know from day 1 that
in order to limit the apps that can be used they need to publish a manifest.

2. We need to think about when the browser will fetch the manifest and how
often it checks for updates. Also, what it does if the manifest changes and
an app's permission to process that method is revoked. All for discussion
at TPAC!

3. I'd recommend that payment apps also have a URL identifier that also
points to a manifest and that things like the icons and alternative
platform versions can be put in there rather than in the method manifest.
The method manifest only needs to provide the URL identifiers of the apps
it supports, recommends or has as its default. All of the app related stuff
you had in your example is already in app manifest. [1]

4. I see the value of short strings for developers but that means payment
method identifiers have no context outside the browser. Perhaps we should
use URLs for these too and browsers will simply offer a short-string alias
that can be used in the API?

5. Lastly, can you push these changes to the WG repo where the original
copy of your proposal is? That helps track changes and gives us a canonical
place to find the proposal.

Thanks again for helping to make progress on this,


On 1 September 2016 at 01:59, Zach Koch <> wrote:

> Hi WG Members,
> I've updated the Payment Method Identifier proposal
> <> [1] and
> written an extension of it proposing a new Payment Manifest
> <> [2]
> file. I'm hoping we can discuss these on tomorrow's call. Here are the
> points worth highlighting:
> * It came up in discussion
> <> that
> URNs have minimal value and instead add an extra burden on web developers.
> This argument seem strong to me, and as such, I propose we replace URNs
> with strings. I realize we have gone back-and-forth on this, but given the
> arguments, strings seem best.
> * In the same discussion, it was brought up that URLs are only valuable as
> identifiers if something lives at that URL. The payment manifest proposal
> is an attempt to explain what this could look like and why it's valuable.
> For tomorrow's call, I would like to focus on getting consensus on the
> following points:
> 1.) Absolute URLs will be used to identify proprietary payment methods
> 2.) Strings will be used to identify open payment methods and will be
> maintained by the WG
> 3.) Every payment method must have an associated payment-manifest file (or
> similar)
> 4.) There must be some standard way to access that payment-manifest file
> (or similar)
> Note that I don't think we need to agree exactly how (3) and (4) should
> work right now, we just need to assume that they will exist so we can
> unblock work. I hope that leading up to TPAC and during our time together
> we can hack out exactly how they should work and meet all of the various
> use cases the group cares about.
> Looking forward to discussing.
> Thanks,
> Zach
> [1]
> [2]

Received on Thursday, 1 September 2016 07:48:32 UTC