- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 2 Mar 2017 13:19:11 -0600
- To: Bazin Pascal <Pascal.Bazin@gemalto.com>
- Cc: Payments WG <public-payments-wg@w3.org>
Hi Pascal, Thanks for the feedback on: https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130 See comments and notes on small changes based on your feedback. Ian > I reviewed the status of Key Issues, https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130 > Not much to say, a few remarks and some questions, but please read the following with a lenient attitude, I may missed that some of those points have already been raised and closed. > > - Permission > o The user must grant permission to an origin. Should we explain that the permission is possibly bound to a limited payment-app scope. Is that accurate? (I am asking because I don’t know.) My (incomplete) understanding is that the sort of permissions we are talking about are for the origin. Thus, we don’t have finer grained permissions. What did you have in mind? > - Registration/Capabilities > o Is the reference to the Payment Method Manifest Specification still relevant ? Yes. That is because payment manifests MAY include some information about payment apps (e.g., icons, labels). For Web-based payment apps we don’t have that information in a separate manifest file; it is provided via the API. So if you want to refer to a Web-based payment app from a payment method manifest, it’s not yet clear to me what you can or can’t say, or the relationship to the API. We still need to figure this out. > and what about the use cases described there (payment app authorized origins, digital signature,…) ? Some of the information is not about payment apps, so that information remains in place, and is not necessary to discuss in the payment app API (or whatever we name it). > - Invocation > o A payment handler having zero payment methods is not very useful ! Now reads: "To handle payments, an origin has at least one and possibly many service worker registrations.” > - Selection of Options > o Am I right to think that whatever the app option selected, it refers to the same and only one registered app-related payment handler ? That is my understanding. Now reads: "Users agents may wish to enable the user to select individual displayed Options, in essence launching the payment handler that registered that option. The payment handler would receive information about the selected option and could, in essence, begin to take action (thus eliminating the extra click to open the payment app and then select the option)." > - Implementation questions > o Could start with a list of possibly not-supported features. I don’t understand the comment. Can you provide some examples? -- Ian Jacobs <ij@w3.org> https://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447
Received on Thursday, 2 March 2017 19:19:20 UTC