14:52:55 RRSAgent has joined #apps 14:52:55 logging to http://www.w3.org/2017/01/17-apps-irc 14:53:11 agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Jan/0054.html 14:53:16 Meeting: Payment Apps Task Force 14:53:18 Chair: Ian 14:53:19 Scribe: Ian 14:53:35 agenda+ recent edits 14:53:47 agenda+ payment app identifiers 14:53:53 agenda+ Tommy's pull request regarding PaymentAppResponse Dictionary 14:56:28 agenda+ Clarity on whether top-level displayItems sent to payment app 14:56:55 agenda+ Issue 73: Need to specify behavior for Clients.openWindow 14:57:02 agenda+ Issue 83: payment-manifest.json and canHandle function 14:57:06 agenda+ FPWD goals 14:57:14 agenda+ Next meeting 14:59:19 frank has joined #apps 14:59:30 alyver has joined #apps 15:00:42 jnormore has joined #apps 15:00:56 present+ 15:00:59 present+ Frank 15:01:04 present+ AdamR 15:02:00 present+ jnormore 15:02:26 rouslan has joined #apps 15:02:31 present+ 15:02:42 +1 15:03:09 present+ alyver 15:03:16 regrets+ Tommy 15:03:48 zakim, take up item 1 15:03:48 agendum 1. "recent edits" taken up [from Ian] 15:03:57 https://w3c.github.io/webpayments-payment-apps-api/ 15:04:04 Integrated revised model text (notably around recommended apps) 15:04:04 https://github.com/w3c/webpayments-payment-apps-api/commit/5de10a295f00c1161a55d286413253e8467491a5#diff-eacf331f0ffc35d4b482f1d15a887d3b 15:04:23 Max has joined #apps 15:04:51 present+ Max 15:05:15 zakim, take up item 2 15:05:16 agendum 2. "payment app identifiers" taken up [from Ian] 15:05:23 We are still wrestling with what identifiers we have and what they 15:05:23 identify. The spec now talks about PAI's identifying service worker code: 15:05:23 https://w3c.github.io/webpayments-payment-apps-api/#identification 15:05:23 AdrianHB has a counter proposal: 15:05:23 https://github.com/w3c/webpayments-payment-apps-api/issues/48#issuecomment-261775283 15:07:24 IJ: Anybody want to weigh in on the choice between PAI points to service worker code VERSUS PAI points to manifest file 15:07:59 zakim, take up next item 15:07:59 agendum 1. "recent edits" taken up [from Ian] 15:08:06 zakim, close item 1 15:08:06 agendum 1, recent edits, closed 15:08:07 I see 6 items remaining on the agenda; the next one is 15:08:07 3. Tommy's pull request regarding PaymentAppResponse Dictionary [from Ian] 15:08:07 zakim, close item 2 15:08:08 agendum 2, payment app identifiers, closed 15:08:08 I see 6 items remaining on the agenda; the next one is 15:08:08 3. Tommy's pull request regarding PaymentAppResponse Dictionary [from Ian] 15:08:10 zakim, take up item 3 15:08:10 agendum 3. "Tommy's pull request regarding PaymentAppResponse Dictionary" taken up [from Ian] 15:08:20 https://github.com/w3c/webpayments-payment-apps-api/pull/84 15:09:09 https://github.com/w3c/webpayments-payment-apps-api/pull/84/files 15:09:24 q+ 15:09:27 ack jno 15:09:42 https://github.com/w3c/webpayments-payment-apps-api/issues/81 15:10:14 jnormore: Makes sense to me. 15:10:31 +1 15:10:43 RESOLVED: Merge Tommy's PR. 15:10:55 zakim, close item 3 15:10:55 agendum 3, Tommy's pull request regarding PaymentAppResponse Dictionary, closed 15:10:57 I see 5 items remaining on the agenda; the next one is 15:10:57 4. Clarity on whether top-level displayItems sent to payment app [from Ian] 15:11:00 zakim, take up item 4 15:11:00 agendum 4. "Clarity on whether top-level displayItems sent to payment app" taken up [from Ian] 15:11:29 https://w3c.github.io/webpayments-payment-apps-api/#sec-app-request-data 15:12:01 Issue 8 15:12:01 Is the specification missing the top level "displayItems"? 15:12:52 q+ 15:12:55 https://w3c.github.io/browser-payment-api/#paymentdetails-dictionary 15:13:09 q+ 15:13:11 IJ: Are we missing display items? 15:13:23 Rouslan: Seems like a bug; we should be sending displayItems to the app 15:13:27 ack rou 15:13:29 ack ada 15:13:38 adamR: My recollection is that this was done intentionally. 15:13:42 q+ 15:13:54 q+ 15:14:01 ...as a matter of privacy...if I am buying something I don't want a payment provider to know about, that might not be something I want passed along. 15:14:02 q+ 15:14:12 ack jn 15:14:47 jnormore: It's pretty common for merchants to prefer to not want to pass that along, but it's also common for them to not care, in order for the payment provider to offer a better experience, e.g., to show the items to the user 15:14:53 ..I would lean in the direction of "OPTIONAL" 15:14:59 ...as a reflection of status quo 15:15:01 ack rouslan 15:15:09 q+ 15:15:17 rouslan: If I recall, android pay requires total and displayItems are OPTIONAL 15:15:51 q+ 15:15:54 jnormore: From a merchant perspective, the diff between providing between Android Pay and a third party...in the case of Android Pay you are not passing it to a third party...you are just passing to the device for display 15:16:04 ...that's when it becomes a concern from a merchant perspective. 15:16:05 ack fr 15:16:28 frank: We do prefer to have the shopping card items to do risk assessment and to improve user experience. 15:16:34 ...it should definitely be optional 15:16:42 ack ad 15:17:01 adamR: Regarding the display, these items are still going to be displayed to the user as part of checkout... 15:17:12 ...as far as making them optional, that sounds like a reasonable compromise 15:17:36 ...so we'd need a flag in PR API to indicate whether to pass details on to the payment app 15:17:41 ack me 15:17:55 ian: I also heard people might hesitate to pay if they don't see what they are paying for. 15:18:10 q+ 15:18:26 ...especially in a context where you are doing other things, e.g., relate to coupons 15:18:28 ack frank 15:18:55 frank: To add to that, in our context, the payment does not happen at the time of purchase. We extend credit, and payment happens at a later stage, and the user needs to see that data when the payment has to happen post purchase. 15:19:08 q+ 15:19:12 ack rouslan 15:19:25 rouslan: I would prefer not to have another flag in payment request API 15:19:25 +1 15:19:27 +1 15:19:30 q+ 15:20:00 q- 15:21:10 rouslan: PROPOSED - details are optional at PR API level (as the spec already says), but if provided are sent to the payment app. E.g., we could add guidance to merchants to not show sensitive names. 15:21:17 +1 15:21:28 +1 15:21:29 +1 15:21:32 +0 15:21:51 +1 15:22:25 IJ: Should we update the spec to indicate display items and that it will be null if not provided in PR API? 15:22:40 ACTION: Ian to update the spec to indicate display items and that it will be null if not provided in PR API 15:23:06 zakim, close this item 15:23:06 agendum 4 closed 15:23:07 I see 4 items remaining on the agenda; the next one is 15:23:07 5. Issue 73: Need to specify behavior for Clients.openWindow [from Ian] 15:23:10 zakim, take up item 5 15:23:10 agendum 5. "Issue 73: Need to specify behavior for Clients.openWindow" taken up [from Ian] 15:23:18 previous action - Rouslan to look into how progress web apps could help 15:23:18 us understand how to manage UI in different contexts. 15:23:43 https://github.com/w3c/webpayments-payment-apps-api/issues/73#issuecomment-273119925 15:24:35 rouslan: Spoke about this a bit. The consensus in Google seems that "progressive web apps" will not be of much help; but we have to keep looking into this. 15:24:53 ...I still think it's right but they were tepid; so maybe I need to explain better. 15:25:13 +q 15:25:24 ack fr 15:25:56 frank: The current implementation, when the web-based payment app is opened in a separate tab, .... I share the concern that that's probably not the best UX and also problematic with it being separate from the merchant site from a flow perspective. 15:26:01 q+ 15:26:21 ack ad 15:26:37 adamR: I still think that if we are concerned about the tab experience, we need to point out how that can arise. 15:27:05 https://w3c.github.io/webpayments-payment-apps-api/#payment-app-display 15:27:28 q+ 15:28:22 AdamR: It's still a note: 15:28:23 "Implementations may vary on how windows open. For example, while opening an entirely new window is possible, it is more likely that the contents will be rendered in a way that makes it more obvious that the interactions pertain to the payment transaction. The opening of a payment app window versus other types of windows can be distinguished based on the event type the user agent is using to grant permission to open a window. " 15:28:34 adamR: We can make it normative if we feel it's important to do so. 15:28:37 ack rous 15:28:53 rouslan: +1 to adamR...I think this should not be a different API call. 15:29:04 ...in terms of making sure that the window looks correct, that should not be in this spec. 15:29:27 ...I think we should wait for browsers to implement this, and then provide suggestions if they get it wrong 15:30:20 IJ: that suggests a change to "must call clients.openWindow()" 15:31:55 q+ 15:31:57 adamR: It's not clear to me what bad scenarios will arise by calling clients.OpenWindow 15:32:00 ack frank 15:32:13 q+ 15:32:17 frank: Tommy's point is that client.OpenWindow() does open in another tab 15:32:19 ack rous 15:32:38 q+ 15:34:07 q- 15:34:07 adamR: User agent should render this in a way that is different from normal windows, to make it clearer to the user that this is part of a payment flow. 15:34:24 ..and the user agent can use information (as the note points out) to determine when to do so 15:34:27 q+ 15:34:48 frank: I thought opening tab was standard behavior 15:34:58 adamR: Spec says "new browsing context" but doesn't say tab..it's left up to the user agent 15:35:05 ack rous 15:35:30 ok. great 15:35:39 rouslan: I think that Tommy's implementation uses the default implementation. But we would do a custom implementation before releasing that would do the right thing wrt opening a payment window 15:35:48 [Rouslan leaves] 15:37:38 (We have not looked at issue 10 and 11 lately) 15:38:30 AdamR: I think we need more service worker expertise here. 15:39:17 https://w3c.github.io/webpayments-payment-apps-api/#payment-app-display 15:39:44 I have it as 10.4 15:39:57 10.4! 15:41:43 ACTION: Ian to revisit 10.4 to make clear that (1) we want payment apps to use the standard API call but (2) what happens will be UA-determined given this a payment context (3) some guidance about not confusing the user 15:42:08 (IJ I will get rid of the first note and integrate better) 15:42:19 I will ping Tommy on the edits 15:42:35 zakim, close this item 15:42:35 agendum 5 closed 15:42:36 I see 3 items remaining on the agenda; the next one is 15:42:36 6. Issue 83: payment-manifest.json and canHandle function [from Ian] 15:42:40 zakim, take up item 6 15:42:40 agendum 6. "Issue 83: payment-manifest.json and canHandle function" taken up [from Ian] 15:42:49 https://github.com/w3c/webpayments-payment-apps-api/issues/83 15:44:38 AdamR: canHandle() appears in code. This is not in a JSON file 15:44:50 https://w3c.github.io/webpayments-payment-apps-api/#register-example 15:46:16 ...I would not call the JS objects in the example "JSON". 15:46:26 ..there's a separate topic - we want to make those objects serializable JSON 15:46:39 s/JSON/as JSON 15:46:42 ...if we have a reason to do that. 15:46:44 q+ 15:46:49 ack frank 15:46:54 Example 1: Payment App Registration 15:47:24 frank: why are "quotes" there? 15:47:31 IJ: What should happen there? 15:47:57 AdamR: Suggest removing quotes 15:48:01 (IJ will do that) 15:48:09 q? 15:50:10 (We also look at Rouslan's comment) 15:50:48 adamR: Right now if you are a mediator trying to determine matches, you can do so by looking at payment methods and calling canHandle() 15:51:05 ..but if we move to an event model, you need to find the service workers and see if canHandle() there 15:51:24 ..but the big issue is that canHandle() needs to run in a particular context...making it harder to do Rouslan's approach 15:53:49 ACTION: AdamR to weigh in on issue 83 on (1) JS v. JSON...and we are fixing quotes; and there is no file required and (2) canHandle() should not be an event 15:54:03 (IJ sees typo in enabled methods: canHandl) 15:54:26 zakim, close this item 15:54:26 agendum 6 closed 15:54:27 I see 2 items remaining on the agenda; the next one is 15:54:27 7. FPWD goals [from Ian] 15:54:34 zakim, take up item 7 15:54:34 agendum 7. "FPWD goals" taken up [from Ian] 15:56:15 IJ: Other than the list in the agenda, anything else obvious we should address before requesting FPWD? 15:56:16 (No replies) 15:56:23 Topic: Next meeting 15:56:30 24 Jan 15:56:40 ...we will review Adam's text on issue 79 15:56:56 ...and also revised text around 73 (from Ian) 15:57:14 ...another topic raised by Jake Archibald - can we have an end-to-end example of how things work? 15:58:10 alyver has left #apps 16:07:56 rrsagent, make minutes 16:07:56 I have made the request to generate http://www.w3.org/2017/01/17-apps-minutes.html Ian 16:07:59 rrsagent, set logs public 16:20:52 rrsagent, make minutes 16:20:52 I have made the request to generate http://www.w3.org/2017/01/17-apps-minutes.html Ian 16:20:59 RRSAgent, set logs public