- From: Ian Jacobs <ij@w3.org>
- Date: Tue, 24 Jan 2017 10:27:00 -0600
- To: Payments WG <public-payments-wg@w3.org>
Minutes from today’s call: https://www.w3.org/2017/01/24-apps-minutes.html Next meeting: 31 January. Ian P.S. Sorry for wrong date in the original subject line; I hope nobody missed the meeting due to that error. > On Jan 23, 2017, at 1:19 PM, Ian Jacobs <ij@w3.org> wrote: > > 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 > > > > > -- Ian Jacobs <ij@w3.org> https://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447
Received on Tuesday, 24 January 2017 16:27:07 UTC