- From: Adrian Hope-Bailie <adrian@hopebailie.com>
- Date: Thu, 1 Sep 2016 09:48:00 +0200
- To: Zach Koch <zkoch@google.com>
- Cc: Payments WG <public-payments-wg@w3.org>
- Message-ID: <CA+eFz_JfNmLs0NuX2axpiGgMrPa13TAavNok1wB=FkPd5tH1zA@mail.gmail.com>
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, Adrian [1] https://www.w3.org/TR/appmanifest/ On 1 September 2016 at 01:59, Zach Koch <zkoch@google.com> wrote: > Hi WG Members, > > I've updated the Payment Method Identifier proposal > <https://github.com/zkoch/zkoch.github.io/blob/master/pmi.md> [1] and > written an extension of it proposing a new Payment Manifest > <https://github.com/zkoch/zkoch.github.io/blob/master/payment-manifest.md> [2] > file. I'm hoping we can discuss these on tomorrow's call. Here are the > points worth highlighting: > > * It came up in discussion > <https://github.com/w3c/webpayments-method-identifiers/issues/9> 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] https://github.com/zkoch/zkoch.github.io/blob/master/pmi.md > [2] https://github.com/zkoch/zkoch.github.io/blob/master/pay > ment-manifest.md >
Received on Thursday, 1 September 2016 07:48:32 UTC