13:52:32 RRSAgent has joined #apps 13:52:32 logging to http://www.w3.org/2016/11/30-apps-irc 13:52:52 Meeting: Payment Apps Task Force 13:52:54 Chair: Ian 13:52:57 Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2016Nov/0067.html 13:53:01 agenda? 13:53:06 zakim, clear agenda 13:53:06 agenda cleared 13:56:21 TommyT has joined #apps 13:56:43 jenan has joined #apps 13:58:16 regrets+ Conor 13:58:31 regrets+ Jason 13:59:51 Ian has changed the topic to: 30 Nov agenda https://lists.w3.org/Archives/Public/public-payments-wg/2016Nov/0067.html 14:01:59 rouslan has joined #apps 14:02:14 present+ Rouslan 14:02:57 WebEx phone gateway is down for now 14:03:04 So you need computer audio I think 14:03:08 present+ Jenan 14:03:10 present+ Alan 14:03:13 present+ Rouslan 14:03:14 present+ 14:03:16 present+ Tommy 14:03:19 present+ Adam 14:03:29 regrets+ AdrianHB 14:03:39 topic: Next meeting 14:03:43 7 Dec 14:04:14 Tuesdays, 10am ET or 11am ET (for 1 hour) 14:04:23 Should we change to that time? 14:04:23 +1 either 14:04:53 Tommy: -1 14:05:00 Tommy: But I can live with it 14:05:05 +1 either 14:06:37 https://github.com/w3c/webpayments/wiki/PaymentApp_Notes 14:07:25 topic: Recent spec edits 14:07:32 WebIDL fix 14:07:32 https://github.com/w3c/webpayments-payment-apps-api/pull/71/commits/738e08739133a6e52482db7446b473ad7fe2f64b 14:08:06 Tommy edits regarding cancelation and failure handling: 14:08:06 https://github.com/w3c/webpayments-payment-apps-api/commit/9dcf7d251d1c1f00b13825f96123d5dcc124e105#diff-eacf331f0ffc35d4b482f1d15a887d3b 14:08:41 Tommy: Main thing I did was to say that the rejection of the promise is not necessarily fatal. 14:08:53 ...the user agenda can decide what to do next. 14:09:29 alyver has joined #apps 14:09:40 topic: Issue 69: What does Icon mean? 14:09:46 https://github.com/w3c/webpayments-payment-apps-api/issues/69 14:09:56 q+ to talk about icon 14:10:11 Proposal: 14:10:22 1) We refer to web app manifest rather than roll our own 14:10:28 2) We decide how much of that spec to reference 14:10:59 ack rous 14:10:59 rouslan, you wanted to talk about icon 14:11:14 rouslan: I think you expressed my view - we should reference web app manifest 14:11:19 ...and follow their examples. 14:11:26 ...this will benefit implementers 14:11:50 https://www.w3.org/TR/appmanifest/#manifest-and-its-members 14:13:13 IJ: Do we need all the manifest members? 14:13:13 q+ 14:13:15 ack rous 14:13:31 rouslan: That's a hard question to answer here; I think we should continue discussion on GitHub 14:14:52 http://caniuse.com/#search=manifest 14:15:29 AdamR: Marcos may have an opinion on referencing it (re: stability) 14:16:29 IJ: Should I update the spec to say "we are looking at referencing web app manifest" 14:16:51 AdamR: +1 to reusing the two names from that spec, and leaving a note to say we are looking into importing or referencing web app manifest 14:17:05 ..please include in examples so people can understand 14:17:25 ACTION: Ian to update the manifest information with pointer to this issue and updated member names 14:17:49 topic: Filtering 14:17:56 previous action - AdamR to take a stab at writing up description of payment app function to return boolean if filter matches; see 14:17:56 https://www.w3.org/2016/11/02-apps-minutes.html#item03 14:18:57 AdamR: It was not clear from our last chat was whether we want to define a lambda-based mechanism, or if we want something else 14:18:57 q+ 14:19:22 ack rou 14:19:37 rouslan: On declarative v. procedural.... 14:20:07 ...data v. function 14:20:27 rouslan: I prefer the lambda approach 14:20:33 s/something else/an algorithm for matching capabilities of payment apps with filters described by payment requests/ 14:20:44 ...I think Adam wanted to be sure that the function could not access the network...I'm not sure how easy that would be to enforce 14:21:11 ....what would be good as well is a timeout 14:21:24 ...e.g., 400ms 14:21:44 q+ 14:22:02 adamR: Will require some time to discuss; find out how sandboxes are described elsewhere 14:22:21 IJ: EME 14:23:16 https://www.w3.org/TR/secure-contexts/ 14:23:26 https://www.w3.org/TR/secure-contexts/#monkey-patching-sandbox-flags 14:23:36 https://www.w3.org/TR/html51/browsers.html#parse-the-sandboxing-directive 14:24:39 AdamR: There's a chance that this is unique and will get odd glances 14:24:50 IJ: Due date? 14:24:57 AdamR: Regrets for 7 Dec 14:25:27 ...suggest we review this 14 Dec 14:25:39 topic: Issue 12: Passing details on payment options 14:25:44 https://github.com/w3c/webpayments-payment-apps-api/issues/12 14:26:35 q+ 14:26:36 IJ: New views on this? 14:26:38 ack rous 14:26:42 q- 14:26:53 Rouslan: It seems that it's not too difficult to support options 14:27:05 ...but we haven't blended the UI of options and payment apps 14:27:10 ...we are still undecided on this 14:28:16 IJ: Should we have the spec say "provide option data and display may vary" or wait more to get experience? 14:28:32 adamR: I am ok with current approach for the time being 14:29:03 q+ 14:29:04 ..I think that if some browsers display options, there will be pressure on browser vendors to display 14:29:33 IJ: The spec could say "browsers and payment apps may exchange option information" 14:29:49 AdamR: I'm ok to wait to see how things land and update the spec 14:31:19 ...I prefer that the data structures be defined and to say that display of option is done at the preference of the browser 14:31:34 ...if not displayed, then the field could come through undefined 14:31:51 ..the issue is "more clicks" from the user to make things happen when they can't choose options directly 14:31:55 ack r 14:32:11 rouslan: I am recalling recent conversations on blink list about size of spec 14:32:27 ...so let's be more specific and say user agent SHOULD display options 14:32:43 ...and UA gets to experiment with exact user experience 14:33:25 s/size/vagueness/ 14:33:40 AdamR: If option is not displayed, need to send appropriate (null) data to the payment app 14:33:52 q+ 14:33:55 ack jen 14:34:16 [jenan asks UI question] 14:35:21 https://github.com/w3c/webpayments/wiki/PaymentApp_Notes#user-experience-descriptions 14:36:36 IJ: Yes, options might enable user to pick card (e.g.,) straight from mediator UI 14:37:07 AdamR: Goal is to minimize user actions 14:37:09 roger, thanks! 14:37:35 Summary: 14:37:49 - include option data in the communications between mediator and payment app 14:38:00 - mediator SHOULD display options 14:38:34 - where user selects option, that information sent to the payment app 14:38:46 (AdamR: Yes, via a unique ID) 14:39:03 - where mediator does not support options, then ID is null to payment app 14:39:31 +1 to MUST 14:39:38 q+ say again? 14:39:42 ack rou 14:39:51 zakim, clear queue 14:39:51 I don't understand 'clear queue', Ian 14:39:56 zakim, drop say 14:39:56 sorry, Ian, I can't do that anymore 14:40:00 zakim, clear the queue 14:40:00 I don't understand 'clear the queue', Ian 14:40:04 queue== 14:40:27 rouslan: chrome shows most frequently used payment option, and user can expand to view all of them 14:40:39 ...so does that mean we are not displaying all options (and violate MUST)? 14:41:05 Tommy: It's easier to implement MUST than SHOULD 14:41:16 q+ 14:41:19 ...since we need to implement support for payment apps that supply options and those that don't 14:41:39 ...the MUST here is on the mediator, but there's an option for payment apps (to have options or not) 14:41:45 ...are both options and not-options legal? 14:41:49 ack je 14:42:02 q+ 14:42:12 jenan: What about language that the user must be able to select all options (rather than speak about display) 14:42:23 +1 14:42:24 1- 14:42:27 q- 14:42:28 +1 14:42:47 rouslan: Yes, +1 to language about user must be able to select all options 14:44:13 ACTION: Ian to update the spec to talk about options, user selection of options 14:44:27 topic: Opera / Samsung update 14:44:57 IJ: How is it going? can we help you as a group? 14:45:10 Tommy: I have received a lot of requests from third party payment app implementers 14:45:17 ..and they want a platform to test apps 14:45:37 ...so I wanted to see if I could implement this in Chromium, and our colleague from Samsung has started implementing the difficult stuff. 14:45:40 ...so I'm going to let him! 14:45:49 ..I will try to tackle some of the easier problems 14:46:10 ...we would like to be able to make some prototype versions of Chromium for app implementers to test 14:46:24 ...not sure how long it will take us...we've built some pieces but not put them together yet 14:50:42 IJ: We could organize a hackathon (e.g., Boston) 14:50:42 OR 14:50:52 ..in Chicago around our FTF meeting (if we have it in march) 14:51:55 Tommy: We should be able to have something together in Q1 14:52:27 Topic: other issues 14:52:27 https://github.com/w3c/webpayments-payment-apps-api/issues 14:54:13 Regarding issue 23 14:54:21 AdamR: I think that is mostly covered by our shift to service workers 14:54:29 ..there are still questions about what permissions we expect the apps to use 14:54:52 ...I think we want apps to have access to the web platform (e.g., cameras, etc for authentication or QR codes) 14:54:55 ...it is a question we need to address 14:55:08 ...I do expect the question will come up later 14:56:27 Topic: Next week's call 14:56:46 Ian: AdamR, perhaps you can weigh in by email on this proposal: 14:56:46 https://github.com/w3c/webpayments-payment-apps-api/issues/48#issuecomment-261786242 14:59:17 rrsagent, make minutes 14:59:17 I have made the request to generate http://www.w3.org/2016/11/30-apps-minutes.html Ian 14:59:22 rrsagent, set logs public 16:55:59 Zakim has left #apps