13:58:46 RRSAgent has joined #apps 13:58:46 logging to http://www.w3.org/2016/12/14-apps-irc 13:58:52 Zakim has joined #apps 13:59:08 agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2016Dec/0033.html 13:59:11 Chair: Ian 13:59:13 Scribe: Ian 13:59:38 alyver has joined #apps 14:03:06 \me is starting to feel left out. 14:03:59 topic: Review Adam's lambda proposal 14:04:03 https://github.com/w3c/webpayments-payment-apps-api/pull/76/commits/9249ea31cb7b5295d19dd32efdf3754694691998 14:04:26 rouslan has joined #apps 14:04:27 https://github.com/w3c/webpayments-payment-apps-api/pull/76/commits/9249ea31cb7b5295d19dd32efdf3754694691998 14:04:33 present+ Rouslan 14:04:39 present+ Ian 14:04:43 present+ AdamR 14:04:45 present+ Andre 14:05:08 https://adamroach.github.io/webpayments-payment-apps-api/ 14:05:43 https://adamroach.github.io/webpayments-payment-apps-api/#payment-app-manifest 14:05:59 AdamR: If canHandle is absent then you are expected to handle all payment methods declared in the manifest 14:06:21 ...if present then expected to take in method data and details, and to iterate over them and return an object 14:06:37 ..the object has keys of options it can handle 14:06:43 q+ 14:06:51 ..the values are modifiers to the option (and -1 if no modifier) 14:07:14 ...a bit strange if "-1" is a common response (which I expect it will be) 14:07:27 ....a description for canHandle is somewhat informal (in 7.3 14:07:33 ...in section 8 it will be more formal. 14:07:48 ...we also probably want an extension point in PR API on determining what is an accepted method 14:07:55 ..the way that we do that will be based on this registered function 14:08:49 ...I think in PR API we need a clean extension point "Here is where you run the steps of payment apps" 14:08:50 ack r 14:09:10 rouslan: I noticed the callback function returns an object instead of interface/list of interfaces/dictionary/list of dictionaries 14:09:22 adamR: This is the best I could figure out based on your proposal. 14:09:35 ...with a dictionary you need to define the keys in the spec 14:09:43 ...if you think it should be a list we can spec it out that way as well 14:10:15 rouslan: we could change the proposed syntax to return a sequence of dictionaries 14:10:19 ...where each dictionary has two keys 14:10:40 AdamR: One key would be an id, the other would be an index 14:10:43 Rouslan: Yes 14:10:47 present+ Max 14:10:55 Rouslan: This also lets us add another value 14:10:59 AdamR: +1 14:11:45 IJ: You could also replace -1 with nothing, so that makes the common case easier 14:11:59 [ { “id”: “ABC” }, { “id”: “DEF”, “modifier”: “2” } ] 14:12:09 AdamR: +1 14:12:18 q? 14:12:33 IJ: What about the more formal definition? 14:12:46 AdamR: There are 16 baroque steps not worth reviewing here...but I want to highlight step 10 14:13:02 https://adamroach.github.io/webpayments-payment-apps-api/#matching 14:13:09 ...apparently this is relatively easy to implement 14:13:32 ..people are doing something like this (step 10) with packfiles 14:13:56 ...we may want some W3C-defined terms to define this "almost null" operating environment...but I would prefer to point to existing specs 14:14:02 s/packfiles/ “pac” files/ 14:14:25 IJ: Let's review offline...what should we pay close attention to? 14:15:05 AdamR: Focus on 7.3 (which will become sequence of dictionaries) and 8 14:16:24 AdamR: I'd like people to review before we merge 14:17:38 IJ: any links to the issue? 14:17:44 AdamR: There was a link that's still there 14:18:14 IJ: Proposed is 2 thumbs up means we can merge 14:18:20 (Ian will look at the IPR issue in github) 14:18:50 topic: Issue 73: Need to specify behavior for Clients.openWindow #73 14:18:55 https://github.com/w3c/webpayments-payment-apps-api/issues/73 14:20:09 Rouslan: Want to be able to open a window in a browser to authorize a payment 14:20:30 ...so when the browser invokes the service worker with the payment request event, at this point the app will want to call clients.openWindow to show a window to the user 14:20:41 ...the issue is that we need to make sure that this function call does not fail. 14:20:59 ...it's not clear whether the payment request is a user gesture. 14:21:21 ...to avoid inconsistencies in implementations we should specify in web payment app api that payment request handler in the service worker should be able to use clients.openWindow 14:21:32 AdamR: Yes, I think that's the intention 14:21:47 ...we did say previously that payment request show() should require some user interaction 14:21:50 q+ 14:22:15 rouslan; That's not specified explicitly. In Chrome, show() does not require user action; but user action is required to approve payments 14:22:24 ...BorisZ raised the question about ambiguity 14:22:55 ...one thing that I noticed that's not specified is that clients.openWindow needs to be supported 14:23:09 AdamR: My strong preference would be to require user gesture requirement on invoking PR API 14:23:23 ACTION: AdamR to raise an issue on PR API 14:23:33 ack a 14:23:38 alyver: Two things 14:23:42 q+ 14:23:52 ...first agree that user action should be required on invocation of PR API 14:23:58 ..the button has to be clicked in order to show the payment sheet 14:24:12 ...I have a question on clients.openWeb....is that a separate application window? Is this just desktop? 14:24:23 AdamR: The notion is that it will be implementation dependent. 14:24:47 ...in Firefox I expect that we will have a slide-down sheet that is used to select the payment app itself (and pick billing address, etc.) 14:25:01 ..and then as soon as the user submits that, we'll replace the contents of that space with something like a spinner 14:25:27 ...if the payment app calls openWindow, the construct will become the window. 14:25:35 ...but we should not constrain how other UAs do this 14:25:36 +1 14:26:12 https://www.w3.org/TR/service-workers/#clients-openwindow 14:26:52 IJ: How much do we need to specify here? Where are security aspects covered? 14:27:01 AdamR: I think security aspects we care about handled by service workers 14:27:25 https://w3c.github.io/webpayments-payment-apps-api/#payment-app-display 14:27:56 "Payment Apps that require user input can open a payment window using the clients.openWindow() method defined in [SERVICE-WORKERS]. " 14:28:01 Proposed change to something like: 14:28:19 "User agents MUST support clients.openWindow() method defined in [SERVICE-WORKERS] so that payment apps that require user input can open a window." 14:28:30 "User agents MUST support clients.openWindow() method defined in [SERVICE-WORKERS] so that payment apps that require user input can open a window to collect input." 14:28:33 AdamR: +1 14:29:20 IJ: what is the relationship of the rest of the first para of 10.3 to this new requirement? 14:34:30 IJ: I think we should put the selection bits in 9, and leave the display bits in 10, so the first para of 10.3 might be shrunk 14:35:26 Requirements: 14:35:36 1) Browsers must allow payment apps to invoke clients.OpenWindow() 14:35:55 “Because the user must interact with the browser to trigger a payment request, the user agent MUST treat a paymentrequest event as user interaction for the purposes of determining whether the service worker is allowed to open a window.“ 14:36:55 AdamR: In service worker spec, it says "you must not open a window unless there's been an associated user interaction event" 14:37:57 AdamR: Originally the expectation was that this would be at "selection of the payment app" 14:38:21 q+ 14:38:27 ...but we also want to optimize in some cases (no payment app selection) in which case the user interaction event has to go upstream to clicking the buy button. 14:38:50 ...currently PR API does not have a user interaction requirement (so we'll address that in a WPWG issue) 14:38:59 ..the use case I had in mind here was, e.g., micropayments 14:39:19 q+ 14:39:48 q+ to talk about payment app opening window v. payment app display 14:39:59 ack rouslan 14:40:39 rouslan: remember about user gestures that the way they are implemented, once they start there is a 200ms window, and there's an assumption of invocation by user 14:41:12 ...if the browser shows a UI to the user to review shopping cart before invoking payment app, then invoking the payment app will not be the user interaction 14:41:21 ...what AdamR writes above works. 14:41:22 ack ad 14:41:43 alyver: Rouslan said what I wanted to say...distinguish 2 user interactions (1) open payment request (2) open the payment app selected by the user 14:41:57 ...the second sentence is ambiguous; needs to specify the second interaction 14:41:59 ack me 14:41:59 Ian, you wanted to talk about payment app opening window v. payment app display 14:42:04 ack a 14:44:21 IJ: so clients.openWindow is not just for gathering user data; it's also for displaying yourself (to the extent you need to) 14:46:09 let's write scenarios: 14:46:20 * payment app needs no display, e.g., after first authentication within the same session 14:46:27 * payment app never needs display; just returns data 14:47:20 IJ: Can browser suppress display? 14:47:29 AdamR: Should be the payment app that does that on config 14:47:44 * payment app always has some user interaction 14:49:48 IJ: notes: 14:50:10 - service worker requires user interaction 14:50:44 - in some cases user will interact directly with payment app in a window invoked by the payment app 14:51:21 - but in some configurations (to streamline payments) the user may not have explicit user interact, and for the purposes of service workers requirement this specification considers invocation of payment request API to be the user interaction 14:54:11 IJ: this last bit feels like a note for readers 14:55:22 q+ to suggest Boris or Dominic to craft the exact language 14:56:00 ack rous 14:56:00 rouslan, you wanted to suggest Boris or Dominic to craft the exact language 14:59:23 q+ to give an example of where launching payment app with only the PR user interaction is necessary 14:59:33 ACTION: Ian to take a stab at rewriting the first paragraph of 10.3 14:59:52 (Question of whether "invocation of PR API" requires user interaction) 15:00:00 q+ 15:00:02 ack al 15:00:02 alyver, you wanted to give an example of where launching payment app with only the PR user interaction is necessary 15:00:39 alyver: One scenario where you might rely only on PR API invocation ... if a merchant specifies 2 payment methods and the user only has one payment app....shoudl that be launched automatically? 15:00:41 IJ: Yes! 15:00:49 (We have explicitly suggested that.) 15:01:32 https://github.com/w3c/webpayments/wiki/PaymentApp_Notes#user-experience-descriptions 15:02:03 IJ: Is user configuration a user action? 15:03:01 IJ: I will leave in a note on our wonderings about what constitute user gesture when we want automatic behavior 15:03:45 actions? 15:04:06 Adam: I think I want to drop my action on PR API 15:04:13 zakim, drop action 1 15:04:13 I don't understand 'drop action 1', Ian 15:04:18 rrsagent, drop action 1 15:04:33 Summary: 15:04:40 * People are going to review AdamR's lambda proposal 15:04:55 * Ian is going to look at 9.3 intro text with use cases, a requirement on UAs, and some notes on user gestures 15:05:01 Topic: Next call 15:05:16 4 Jan 2017 at 9am ET 15:05:22 rrsagent, make minutes 15:05:22 I have made the request to generate http://www.w3.org/2016/12/14-apps-minutes.html Ian 15:05:25 alyver has left #apps 15:05:32 rrsagent, set logs public 17:26:28 Zakim has left #apps 17:57:00 rrsagent, bye 17:57:00 I see 1 open action item saved in http://www.w3.org/2016/12/14-apps-actions.rdf : 17:57:00 ACTION: Ian to take a stab at rewriting the first paragraph of 10.3 [2] 17:57:00 recorded in http://www.w3.org/2016/12/14-apps-irc#T14-59-33