- From: Ian Jacobs <ij@w3.org>
- Date: Mon, 23 Jan 2017 13:19:24 -0600
- To: Payments WG <public-payments-wg@w3.org>
Participants in the payments app task force,
We meet 24 January at 10am ET.
Previous meeting 17 January:
https://www.w3.org/2017/01/17-apps-minutes
WebEx: http://www.w3.org/2017/01/paymentapps-2017.ics
Ian
========
It's been an active week so there is a lot to discuss!
-----------
Recent changes to the spec:
https://w3c.github.io/webpayments-payment-apps-api/
* Integrated changes re: recommended apps, registration, display of windows
* Integrated PaymentAppResponse dictionary
-----------
Issue 79: How does the payee provide information about recommended payment apps?
https://github.com/w3c/webpayments-payment-apps-api/issues/79
Action AdamR 20170110: Draft how PR API would change to allow-payee
recommended payment apps, due 24 January.
-----------
Issue 73: Need to specify behavior for Clients.openWindow
https://github.com/w3c/webpayments-payment-apps-api/issues/73
Action 20170104: Rouslan to look into how progress web apps could help
us understand how to manage UI in different contexts.
See also Jenan's comments:
https://github.com/w3c/webpayments-payment-apps-api/issues/73#issuecomment-273369385
We've updated the spec text:
https://github.com/w3c/webpayments-payment-apps-api/issues/73#issuecomment-273380883
----------
Issue 92: Payment app decline
https://github.com/w3c/webpayments-payment-apps-api/issues/92
NOTE: We will distinguish the original issue from a separate
issue on recommended payment app security.
See Ian's summary of apparent consensus:
https://github.com/w3c/webpayments-payment-apps-api/issues/92#issuecomment-274097944
----------
Issue 90: Clarification on Payment App "Options"
https://github.com/w3c/webpayments-payment-apps-api/issues/90
Let's clarify whether option display is always required (in which case
Zach will object) or whether options may be implemented, and when they
are we have some requirements.
----------
Issue 91: Why does a Payment App need to see the line items
https://github.com/w3c/webpayments-payment-apps-api/issues/91
Propose we keep requirement and add a bit of explanatory text.
Ian happy to propose an edit.
----------
Marco's proposal
https://lists.w3.org/Archives/Public/public-payments-wg/2017Jan/0070.html
Some other issues are affected by Marcos' proposal: 92, 83, 74, 73, 69, 48
Some notes about Marcos' proposal:
* He proposes that some functionality be removed from PR API
(namely, the browser collecting data through a native UI). I think
we should not discuss that in this task force and, for now, assume
we will continue to get information via the payment app request.
* He proposes that we offload icons and labels to payment app
manifest. I would like to discuss a cascade model where the browser
uses those if available, otherwise it's possible for the app to
specify information as a backup.
* He proposes moving away from having a monolithic payment
app manifest (and using setManifest) to more granular control of
payment methods, etc. I have heard some support for that.
* He proposes a "canHandle" model that exposes more information
to payment apps before they are selected. In the past we have
cited privacy as a reason not to do so.
* Regarding payment method specific filters, his proposal does not
address them explicitly. Marcos indicated that the generic function
approach we are proposing has problems, so we need to revisit that
proposal (e.g., either to address Marcos' concerns, or return to
a less generic approach where we specify, for example, one
algorithm per payment method, to be implemented by the payment app).
* He proposes one payment app per origin. I don't support that approach.
Jake Archibald suggests that the origin is very important in the UI
for security (agreed).
* Regarding identification of payment apps:
- If we drop recommended payment apps, then I don't know how important
it remains for us to define a payment app identifier.
- If we keep PAIs, then Jake has suggested that we use the scope
URL as a unique identifier. There can be more than one of these
per origin. This would not be sufficient, however to get the
service worker code (which would append more path to the scope).
- So we could talk about PAI for matching (scope-based) and remain
silent on "where to get service worker code" since that URL may not
play any special role in the spec.
* We need to review associating openClientWindow with the payment
request event rather than taking a service worker approach (cf
Adam Roach).
----------
Recommended payment apps and security
Right now anyone can recommend any payment app. Does that create
new security issues beyond what merchants can do today? What should
we do (if anything) to improve security of recommendations?
AdamR pointed out to me that whitelists and blacklists won't help
us out, because sites and app providers could collude.
=======
Next meeting
* 31 January
========
Other issues
https://github.com/w3c/webpayments-payment-apps-api/issues
--
Ian Jacobs <ij@w3.org>
https://www.w3.org/People/Jacobs/
Tel: +1 718 260 9447
Received on Monday, 23 January 2017 19:19:31 UTC