14:55:44 RRSAgent has joined #apps 14:55:44 logging to http://www.w3.org/2017/01/24-apps-irc 14:56:00 conorhwp has joined #apps 14:56:08 zakim, clear agenda 14:56:08 agenda cleared 14:56:13 Meeting: Payment Apps Task Force 14:56:15 Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Jan/0079.html 14:56:17 Chair: Ian 14:56:37 Ian has changed the topic to: 24 Jan agenda https://lists.w3.org/Archives/Public/public-payments-wg/2017Jan/0079.html 14:57:16 alyver has joined #apps 14:58:43 pascal_bazin has joined #apps 15:00:17 frank has joined #apps 15:00:34 Hi. Joining the call now 15:00:40 jnormore has joined #apps 15:01:15 present+ 15:01:18 present+ Evgeny 15:01:20 present+ Andrew 15:01:26 present- Andrew 15:01:28 present+ Andre 15:01:31 present+ Frank 15:01:34 present+ Pascal 15:03:23 present+ Conor 15:03:27 present+ Jason 15:03:31 present+ Mathieu 15:03:33 present+ Adam 15:03:41 zakim, who's here? 15:03:41 Present: Ian, Frank, AdamR, jnormore, rouslan, alyver, Max, Evgeny, Andre, Pascal, Conor, Jason, Mathieu 15:03:44 On IRC I see jnormore, frank, pascal_bazin, alyver, conorhwp, RRSAgent, Zakim, adamR, AdrianHB, Dongwoo, Ian 15:04:18 agenda => https://lists.w3.org/Archives/Public/public-payments-wg/2017Jan/0079.html 15:04:35 mathp has joined #apps 15:04:42 q+ 15:04:48 ack conor 15:04:49 Evgeny has joined #apps 15:05:14 topic: Recent changes 15:05:18 * Integrated changes re: recommended apps, registration, display of windows 15:05:18 * Integrated PaymentAppResponse dictionary 15:05:44 rouslan has joined #apps 15:05:48 present+ rouslan 15:06:05 Topic: Issue 79 15:06:10 AdamR: Let's wait; some things are in flux 15:06:32 topic: Issue 92 15:06:38 https://github.com/w3c/webpayments-payment-apps-api/issues/92 15:08:47 IJ: Proposed no change to the spec, and maybe some good practice written down 15:09:00 +1 15:09:17 +1 15:09:42 RESOLVED: Close issue 92 with recommendation that the payment app not silently "not match" and instead inform the user of reasons for not accepting payment request 15:11:04 Topic: Issue 94 explicit permission 15:11:04 https://github.com/w3c/webpayments-payment-apps-api/issues/94 15:11:24 AdamR: Seems there is support at a high level for ensuring user permission 15:11:35 ..but there's an architectural question 15:12:41 q+ 15:12:48 ack mat 15:14:11 I can 15:17:03 adamR: I would like to see the conversation in the other thread play out 15:17:25 ...would be good to get an agreement in principle to have an explicit call to the user requesting permission to register a payment app 15:17:50 IJ: Is it different from the way we do it today? 15:18:23 adamR: Yes, there will be an explicit call to a function asking permission, INSTEAD of having the permission request be implicit in the actions that would require permission 15:18:44 q+ 15:19:04 ...from the user experience perspective, it should be the same permission request 15:19:07 ack rou 15:19:28 rouslan: I think the UX would have to change. The site has the freedom to request permission first and register the app 2 days later. 15:19:52 + 15:19:54 q+ 15:20:00 ...so the user experience needs to be "Would you allow this SIITE to register a payment app?" 15:20:17 ...I think that it should be that each app requests permission, and users should not grant permission for future apps from the site 15:20:19 ack adam 15:20:38 adamR: the way that users are usually prompted is yes/always/never 15:20:50 ...so if a user is prompted to install and the user answers "always" then it won't be a surprise 15:21:13 ..if the user answers "yes" then it would not happen 2 days later since that would be a separate session 15:21:21 rouslan: I am concerned about 4 buttons in a user experience 15:21:36 adamR: Typically what we do is we have yes/no + expansion buttons 15:21:43 ...you can see this when a site asks for camera permission 15:21:58 rouslan: Do you see a use case for sites to continuously install payment apps? 15:22:18 adamR: Yes, versioned apps. or different branded apps depending on my account type 15:23:50 Rouslan: https://www.dropbox.com/s/3smzrf6t64c15yp/Screenshot%202017-01-24%2009.22.36.png?dl=0 15:24:32 rouslan: To be clear, the presense of both “Don’t Share” and “not now” is a problem, and I think it’s going to be fixed soon. But you get the idea. 15:24:45 rouslan: Does "push" allow for continuous install? 15:24:58 IJ: I don't expect background updates to happen while I'm visiting other sites. 15:25:15 adamR: If the service worker is on the same URL, it's not a new installation...it's just the app change. 15:27:22 IJ: I am hearing (1) get consensus here for explicit user permission (2) figure out details of how via github 15:27:39 +1 15:27:39 +1 15:27:43 +1 15:28:33 RESOLVED: Get explicit permission from user to approve the service worker registration. Figure out how on github 15:28:58 Topic: Issue 95 15:28:58 https://github.com/w3c/webpayments-payment-apps-api/issues/95 15:29:21 Monolithic data registration v. granular data registration 15:29:53 q? 15:30:03 AdamR: I need to respond to this thread 15:30:28 ...when a web site asks for a payment, there might be multiple matching apps and user needs to be able to select from among them 15:31:43 IJ: Thread on that issue gets into the manifest topic.... 15:32:21 PROPOSED: Move from monolithic get/setManifest to more granular functions to get/set/delete data necessary for payment apps 15:32:41 IJ: Are people ok to move in that direction. 15:32:45 +0.5 15:33:00 +1 15:33:04 IJ: One piece of rationale was you only need to update the things you need to update 15:33:06 q+ 15:33:07 +0 15:33:11 1- 15:33:15 q+ 15:33:28 AdamR: I think there was also a comms issue here of calling this "manifest" 15:33:38 ...my sense is that this change is isomorphic. 15:33:50 ...if you specify one you could implement the other via a polypill 15:33:56 s/polypill/polyfill/ 15:34:04 ...I am fine to move in this direction. 15:34:04 q? 15:34:08 ack math 15:35:31 [Discussion of "data for a given app" and "multiple apps"] 15:35:49 mathp: Would that create a state of stale payment methods? 15:37:05 ...suppose a payment method has been removed from the user account. 15:37:49 q+ 15:37:58 ....it may be simpler to just say to an app "Here's the current state" without having to query it, etc. and do things more fine-grained 15:38:27 ack con 15:39:10 conorhwp: I think it would be simpler to have just a simple object and let the app developer abstract way the construction of it 15:39:26 ...I'd rather see a single object 15:39:28 ack jno 15:39:45 jnormore: I agree the approaches are equivalent...I would lean towards consistency with other APIs 15:40:00 ...what are good practices...let's take that into account 15:40:03 q? 15:42:44 IJ: Should we bundle filters and payment methods? 15:42:59 AdamR: I am treating them separately. Later we can decide how to set/get filters 15:43:11 happy to continue discussion on github 15:44:08 IJ: I am wondering if we should bundle payment method info and handler info since they are closely related. We could avoid duplication and management of changing data over time. 15:44:50 AdamR: I was thinking you do one payment option at a time 15:45:03 ..and each option can take more than one payment method potentially. 15:45:14 ..I think Marcos' document gets it right 15:45:18 q? 15:45:43 +1 15:45:45 +q 15:45:51 ack conor 15:46:08 conorhwp: I am ok with the proposal 15:47:22 Proposal: 15:47:29 * Move away from monolithic set manifest 15:47:34 * Avoid the word manifest 15:47:47 * Create some number of more specific get/set/delete functions 15:48:07 * Maintain the possibility of specifying the "current state" of payment method support in one call 15:48:53 AdamR: I am more comfortable giving more fine-grain, and then showing people how to set the whole state at once 15:48:58 ...basically showing the polyfill 15:49:31 mathp: For an app it will be difficult to know what payment methods were there previously 15:50:31 ..want to make it easy to put the best state from the server into the app 15:50:36 adamR: Would 'Delete all" work? 15:52:04 mathp: Fine-grain control may introduce bugs....raises maintenance cost 15:52:52 [No resolution] 15:53:04 mathp: I will weigh in on GitHub with my concern 15:53:35 Topic: Issue 98 15:53:36 https://github.com/w3c/webpayments-payment-apps-api/issues/98 15:53:48 AdamR: Marcos clarified he means permission grants not "one app per site" 15:53:54 ..if that's the case we should all be on the same page. 15:54:14 Topic: Issue 97 15:54:14 https://github.com/w3c/webpayments-payment-apps-api/issues/97 15:54:30 AdamR: I am hearing a slight leaning toward a specific method on the event itself to open windows 15:54:44 ...one reason is that it might be reusable in other contexts (so not specific to payemnts) 15:54:52 ..but that might require additional coordination on this pattern 15:56:20 https://github.com/w3c/webpayments-payment-apps-api/issues/97#issuecomment-274787159 15:57:06 IJ: Who should we get to look at this issue (other than the usual suspects)? 15:57:41 Should we close 73 in favor of 97? 15:59:17 q+ 15:59:20 ack rouslan 15:59:27 IJ: Should payment app be required to show its origin to the user? 15:59:39 rouslan: I think the web browser will handle that but ok to put in the spec as a recommendation 16:00:31 RRSagent, make minutes 16:00:31 I have made the request to generate http://www.w3.org/2017/01/24-apps-minutes.html Ian 16:01:13 topic: Next meeting 16:01:16 31 January 16:01:24 RRSAgent, make minutes 16:01:24 I have made the request to generate http://www.w3.org/2017/01/24-apps-minutes.html Ian 16:01:29 RRSagent, set logs public 16:01:48 alyver has left #apps 16:29:25 jnormore has joined #apps 18:02:41 Zakim has left #apps