14:00:04 RRSAgent has joined #apps 14:00:04 logging to http://www.w3.org/2017/08/22-apps-irc 14:00:28 Meeting: Payment Apps Task Force 14:00:29 Chair: Ian 14:00:42 Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Aug/0014.html 14:03:49 frank has joined #apps 14:03:57 https://lists.w3.org/Archives/Public/public-payments-wg/2017Aug/0014.html 14:04:01 present+ Frank 14:04:11 Topic: Moving the Payments Apps discussions to Thursday's meeting 14:04:49 +1 14:05:09 alyver has joined #apps 14:05:20 (IJ talks about moving agenda to Thursday calls starting after PR API CR) 14:05:25 present+ alyver 14:05:35 https://lists.w3.org/Archives/Public/public-payments-wg/2017Aug/0014.html 14:06:08 +1 14:06:27 (Some support for doing this) 14:07:00 topic: CanMakePaymentEvent 14:07:30 https://github.com/w3c/payment-handler/pull/170#issuecomment-318779874 14:09:44 IJ: Any suggestions for how to make progress? Rouslan and I are planning to chat with AdamR 14:11:32 IJ: One idea froM Rouslan is "send less data" (e.g., just PMIs and related filters) to reduce (but probably not eliminate) fingerprintability 14:11:57 present+ Ken 14:12:31 q+ 14:12:32 IJ: Privacy issue is payment app knowing where you are shopping 14:12:33 ack aly 14:12:50 Ken has joined #apps 14:14:24 present+ Sachin 14:14:40 IJ: Options we have discussed: 14:14:52 - merchant does computation (but then merchant knows everything about user environment) 14:15:02 - browser does computation (but browser vendors have said they don't want to do that) 14:15:19 - payment app does computation via lambda run by browser (but marcos has indicated this is not viable in JS) 14:15:35 - payment app does computation itself (but raises privacy issues about knowledge about merchants where I am shopping) 14:16:12 https://github.com/w3c/payment-handler/pull/170#issuecomment-318801051 14:16:19 q+ to ask whether anyone remembers the problem with capability filtering 14:17:05 ack rouslan 14:17:05 rouslan, you wanted to ask whether anyone remembers the problem with capability filtering 14:17:42 rouslan: One things we might proposal is to use capability filtering for basic card (in-browser computation) but for other payment methods invoking canMakePaymentEvent 14:20:21 rouslan: basic card or other w3c-defined payment method spec 14:21:25 q? 14:24:07 AdrianHB has joined #apps 14:24:41 IJ: My expectation is to chat more with AdamR about this. 14:24:59 Topic: Example from Rouslan on two service workers 14:25:04 https://github.com/rsolomakhin/rsolomakhin.github.io/blob/master/pr/sw.md 14:25:19 q+ to talk about this example. 14:25:55 IJ: High level questions - is this the right design? Should we include it in the spec? elsewhere? The use case is "two payment apps from the same origin" 14:26:16 rouslan: The example shows 2 scopes...allows compartmentalization of payment instruments 14:26:19 ack rous 14:26:19 rouslan, you wanted to talk about this example. 14:26:28 ...e.g., the biz wallet and personal wallet from the same company 14:26:42 ...I think having two service workers with different scopes is the best way today to do this 14:27:06 ...soon after I did this example, some of our partners came to us and said they needed this functionalitty 14:27:14 ..and they tried it and said "This doesn't work!" 14:27:32 ...so I looked into it more deeply and it turns out that there was a Chrome bug ("one payment app per origin") 14:27:37 ...we've fixed that bug and now the examples work 14:28:05 IJ: Were the partners thus satisfied? 14:28:07 rouslan: Yes 14:28:16 q+ to ask how the icons etc work with scopes? 14:28:19 ack adr 14:28:19 AdrianHB, you wanted to ask how the icons etc work with scopes? 14:28:23 present+ adrianhb 14:28:43 AdrianHB: My question is how do the manifests work with different scopes? 14:28:55 ...is that how you will have different icons and labels? 14:29:06 rouslan: We want to use Web App manifests 14:29:47 ...currently, when service worker is registered, we look for manifest file and pull icons and name from there. 14:29:55 ...you could have to create 2 manifests for 2 apps 14:30:07 s/2 manifests/2 web app manifests/ 14:30:18 ...you need to register 2 different payment handlers 14:30:32 ...We are currently doing this, but I'm not sure if this approach is the best 14:30:40 ..it does not use the payment method manifest 14:30:53 ...another approach might be to think about the scope as the payment method 14:31:07 ...and follow the payment method manifest spec to download the manifest instead of using the link from the web page 14:31:28 ...one advantage of this approach is that "recommended applications" (if we go that route) can be proposed 14:31:45 ....the payment method manifest itself points to the web app manifest 14:32:06 ...if we continue to rely on a web app manifest file linked from an HTML page, it's not clear how we could do recommended payment apps 14:32:09 q+ 14:32:23 ...so specific design may change but ultimately we get name/icon from web app manifest 14:34:21 https://w3c.github.io/payment-method-manifest/ 14:34:27 q+ 14:34:53 https://w3c.github.io/payment-method-manifest/#manifest-example 14:36:07 AdrianHB: Going through payment method manifest may be problematic for basic card wallets with personal/business distiction 14:36:34 ack rous 14:37:23 rouslan: Regarding overlapping scopes...if you have /webpayments and /webpayments/personal, I think that the question of which worker gets invoked is defined in the spec (e.g., "most specific service worker") 14:37:53 ...in terms of the web app manifest "scope," I hadn't considered that previously 14:38:03 ...that's a really interesting idea that we should try to integrate into the payment handler spec and our implementation 14:38:10 ...I think we need to get some more implementation experience as well 14:40:06 Proposed: Rouslan to add an issue about adding an example illustrating 2 payment apps from the same origin, and linking to his evolving example code 14:40:36 +q 14:40:39 ack me 14:40:40 ack rous 14:40:56 ACTION: Rouslan to add an issue about adding an example illustrating 2 payment apps from the same origin, and linking to his evolving example code 14:41:26 Ian: This is actually closest to issue 153, so maybe just update your examples 14:41:32 RRSAGENT, make minutes 14:41:32 I have made the request to generate http://www.w3.org/2017/08/22-apps-minutes.html Ian 14:41:37 RRSAGENT, set logs public 14:42:14 topic: #178: Default handler icon. Can we make progress on this? 14:42:34 https://github.com/w3c/payment-handler/issues/178#issuecomment-309778321 14:42:36 q+ 14:43:08 ack rouslan 14:43:19 rouslan: For default icon we are still gathering implementation experience 14:43:49 ...we need to consider scope as AHB suggested, need more implementation experience 14:44:22 Topic: #173 Ability to set default instrument for given handler 14:44:44 rouslan: Not sure how much excitement there is for this notion (either from google or mozilla). 14:45:14 ...behavior is not yet clear 14:45:31 ...perhaps a more concrete proposal would help, but I suggest that we postpone discussion for now 14:46:24 AdrianHB: Regarding issue 173, I think we've not had much discussion about the issue 14:47:10 https://github.com/w3c/payment-handler/issues/173#issuecomment-317497373 14:47:58 ACTION: Ian to put issue 173 on this week's WPWG call 14:48:35 Topic: 190: respondWith behavior not specified 14:48:41 q+ 14:48:47 ack rouslan 14:48:57 rouslan: I think this is currently in progress. 14:49:25 ...a Chromium review expressed concern in reviewing paymentrequest.respondWish() and asked for more defined behavior. 14:49:40 ...I think that review of the PR is ongoing 14:49:46 s/respondWish/respondWith/ 14:50:31 Topic: 116: Relation between merchant order of payment methods and 14:50:31 payment app order of instruments. 14:50:55 https://github.com/w3c/payment-handler/issues/116#issuecomment-317890522 14:51:24 IJ: Propose we give Ken a week to add his proposal 14:53:02 Topic: Next meeting 14:53:17 29 Aug 14:53:24 +1 to move conversation to Thursday call. Do we know if other implementors are showing interest in Payment Handler? (i.e. Microsoft, Apple etc) 14:53:31 q+ 14:53:34 ack rous 14:54:38 I wonders if they will stop joining Thurs calls if we just focus on Payment Handler 14:55:50 I have made the request to generate http://www.w3.org/2017/08/22-apps-minutes.html Ian 14:56:02 alyver has left #apps 15:35:39 adamR has joined #apps 15:47:18 cweiss has joined #apps 16:07:50 adamR has joined #apps 17:18:31 Zakim has left #apps