13:43:07 RRSAgent has joined #apps 13:43:07 logging to http://www.w3.org/2017/01/04-apps-irc 13:48:44 TommyT has joined #apps 13:57:10 Meeting: Payment Apps Task Force 13:57:12 Chair: Ian 13:57:14 Scribe: Ian 13:57:30 Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Jan/0006.html 13:57:39 agenda+ Next meeting 13:57:47 agenda+ Developer call 13:57:59 agenda+ Filters 13:58:14 agenda+ Clients.openWindow 13:58:20 agenda+ Recommended payment apps 13:58:32 agenda+ FPWD planning 13:59:32 pascal_bazin has joined #apps 14:00:28 rouslan has joined #apps 14:00:46 present+ Rouslan 14:00:55 present+ 14:01:06 jnormore has joined #apps 14:01:09 alyver has joined #apps 14:01:10 present+ Pascal 14:01:11 present+ 14:01:15 present+ Tommy 14:01:17 present+ Andre 14:01:21 present+ Alan 14:01:29 zakim, who's here? 14:01:29 Present: Rouslan, Ian, Pascal, adamR, Tommy, Andre, Alan 14:01:31 On IRC I see alyver, jnormore, rouslan, pascal_bazin, TommyT, RRSAgent, Zakim, adamR, AdrianHB, Dongwoo, Ian 14:01:46 present+ Jason 14:02:18 agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Jan/0006.html 14:02:20 agenda? 14:02:34 zakim, take up item 1 14:02:34 agendum 1. "Next meeting" taken up [from Ian] 14:02:53 conorhwp has joined #apps 14:03:11 NEXT meeting (note day / time change): 10 January, 10:00 ET. 14:03:51 zakim, close item 1 14:03:51 agendum 1, Next meeting, closed 14:03:52 I see 5 items remaining on the agenda; the next one is 14:03:52 2. Developer call [from Ian] 14:03:54 zakim, take up item 2 14:03:54 agendum 2. "Developer call" taken up [from Ian] 14:04:06 Hello, I am having trouble both dialling in and webex. I'll be in shortly. 14:04:11 zakim, take up item 3 14:04:11 agendum 3. "Filters" taken up [from Ian] 14:04:35 https://github.com/w3c/webpayments-payment-apps-api/pull/78/commits/855790ae19152678a2f8f1695b1563ccb84fbd2e 14:04:51 https://github.com/w3c/webpayments-payment-apps-api/pull/76 14:05:44 (IJ will double check) 14:05:52 (I will update the ICS) 14:06:13 present+ AdrianHB 14:06:13 Present+ AdrianHB 14:06:53 +1 14:06:57 +1 14:06:57 PROPOSED: Merge the lambda proposal into the spec 14:06:58 +1 to merge 14:06:58 +1 14:07:02 +1 14:07:15 RESOLVED: to merge updated https://github.com/w3c/webpayments-payment-apps-api/pul into the spec 14:07:21 I am here now. 14:07:27 present+ Conor 14:08:04 zakim, close item 3 14:08:04 agendum 3, Filters, closed 14:08:05 I see 4 items remaining on the agenda; the next one is 14:08:05 2. Developer call [from Ian] 14:08:07 zakim, take up item 2 14:08:07 agendum 2. "Developer call" taken up [from Ian] 14:08:12 https://lists.w3.org/Archives/Public/public-payments-wg/2017Jan/0000.html 14:08:31 ( January 12th ) 14:08:52 Conor: Last November we had a dev call : http://lists.w3.org/Archives/Public/public-payments-wg/2016Nov/0031.html 14:08:58 ...would be good to catch up again 14:09:15 ...anyone welcome to join 14:09:35 IJ: Would be good to see if Facebook can also join 14:10:03 PROPOSED: 11:00 ET on 12 Jan 14:10:12 Conor: I'll send around more info about that time 14:10:28 ...outline agenda: updates, blockers, payment app specs 14:10:56 IJ: Would be good to get Amex on the call as well 14:11:21 zakim, close item 2 14:11:21 agendum 2, Developer call, closed 14:11:22 I see 3 items remaining on the agenda; the next one is 14:11:22 4. Clients.openWindow [from Ian] 14:11:24 zakim, take up item 4 14:11:24 agendum 4. "Clients.openWindow" taken up [from Ian] 14:11:30 https://github.com/w3c/webpayments-payment-apps-api/issues/73 14:11:36 https://github.com/w3c/webpayments-payment-apps-api/pull/78/commits/855790ae19152678a2f8f1695b1563ccb84fbd2e 14:12:19 https://github.com/w3c/webpayments-payment-apps-api/issues/73#issuecomment-269327967 14:12:43 TommyT: The spec currently says that if a payment app should use clients.OpenWindow, which makes sense since it exists. 14:12:55 ...BUT, currently implementations of client.OpenWindow are not necessarily suitable for showing payment app UI 14:13:07 ...I site the example of Chromium (Android) and Opera, both of which show a new tab 14:13:23 ...two tabs is not very useful..you don't want people to jump around between tabs 14:13:34 ...so what is the way forward? 14:13:37 q+ 14:14:00 ...I remember in the earlier version of the payment app spec there was a special version of the API for opening a window 14:14:03 ack ad 14:14:21 adamR: I think the text that's in there about it being contextual and implementation-specific. 14:14:42 ...I'm not necessarily opposed to adding a new API call. 14:15:08 ...the rationale for going to client.OpenWindow...that spec in service workers is pretty complicated and we didn't want to replicate it. 14:15:21 ...we shifted to using that function to avoid complicating our own spec 14:15:22 q? 14:16:14 q+ to ask how implementors see this being implemented by rich web apps on mobile? 14:16:17 ack Ad 14:16:17 AdrianHB, you wanted to ask how implementors see this being implemented by rich web apps on mobile? 14:16:53 AdrianHB: What's the issue exactly? Is it that developers are expecting consistent behavior from clients.OpenWindow? 14:17:32 Progressive Web App ? 14:17:57 q? 14:18:03 q+ 14:18:13 ack rous 14:18:14 yes, progressive web app 14:18:32 yes 14:18:51 rouslan: You could show them full screen without browser UI.... 14:18:57 ...it makes them look like native apps 14:19:11 ...I wonder if we can somehow launch apps as "progressive" web apps 14:19:31 ...where is this specified? 14:19:54 [We talk about App Manifest here] 14:21:43 https://github.com/w3c/manifest/ 14:22:05 https://www.youtube.com/watch?v=MyQ8mtR9WxI 14:22:46 ACTION: Rouslan to look into how progress web apps could help us address issue 73 14:23:00 http://caniuse.com/#feat=web-app-manifest 14:23:02 https://github.com/w3c/webpayments-payment-apps-api/pull/78/commits/855790ae19152678a2f8f1695b1563ccb84fbd2e 14:23:21 Propose we merge this text 14:23:41 +1 14:23:42 +1 14:23:55 +1 14:24:25 zakim, close this item 14:24:25 agendum 4 closed 14:24:26 I see 2 items remaining on the agenda; the next one is 14:24:26 5. Recommended payment apps [from Ian] 14:24:31 zakim, take up item 5 14:24:31 agendum 5. "Recommended payment apps" taken up [from Ian] 14:24:44 https://github.com/w3c/webpayments-payment-apps-api/issues/74 14:25:33 IJ: Rouslan, what were the requirements or wishes you heard from people? 14:25:52 Rouslan: we talked with some payment app developers that said that they plan to get their payment apps installed by making agreements with merchants 14:26:13 ...instead of putting buttons on pages, payment app providers will say how to do things with recommended payments apps using PR API 14:26:46 ...so the question is how do we suggest apps for the user to install 14:26:53 ..it depends on how we identify apps or methods 14:27:09 ..I think that issue is not entirely resolved...one way to identify apps is by service worker scope: origin + subpath 14:27:18 ...but from service worker scope you can't get the JS file to install it 14:27:25 ..unless that page, e.g., has a link to it 14:27:43 ..another way of suggesting a payment app or identifying a payment piece of information is to point to the actual service worker JS file 14:27:59 ...and in that file, there's a manifest...so you can install the service worker, and that installed the payment app using JS calls 14:28:20 ..but that's kind of ugly in terms of how to identify things...even if it's flexible 14:28:33 ...so the questions are: 14:28:39 * how to identify a recommended payment app 14:28:51 q+ 14:29:11 ..if the merchant accepts a payment method that has multiple apps, then the payment method (manifest) will need to identify also apps...and from there the browser could find out what apps to recommend to the user 14:29:17 q+ to talk about questions 14:29:39 Rouslan: Suggest we start with experimentation. Also, Ian also commented on the thread and I agreed with them 14:29:41 ack Adam 14:29:45 q+ 14:30:12 adamR: Regarding the first bullet points - if you point at the JS you don't have enough information. In registration you register the SW, and SUBSEQUENT to that you register a payment app manifest 14:30:22 q+ 14:30:41 ...I think the first bullet wouldn't work. I think that the second option is the best of the three that Rouslan listed 14:30:49 ack jn 14:31:14 jnormore: I have similar comments...the ugly URL can be prettied up by the payment provider 14:31:27 ...doesn't require app.js extension at the end 14:31:41 ...I think that the merchant should be able to provide human-readable name and icon 14:31:49 ...I think that third bullet is not practical 14:32:10 ...I think the merchant should provide the icon/name instead of relying on the browser getting it 14:32:20 ack rous 14:32:34 rouslan: Sounds like there's some consensus about second point - merchant-provided information 14:33:02 ...this is not necessarily a blocker...I think recommended payment apps are great but we can also do them in a later version of the payment app API 14:33:03 +q 14:33:06 ack n 14:33:09 ack jn 14:33:21 jnormore: In terms of "recommended" payment apps, this is definitely very important. 14:33:28 ack me 14:33:28 Ian, you wanted to talk about questions 14:34:27 q+ to mention existing discussion between manifest and serviceworker devs 14:35:08 https://w3c.github.io/webpayments-payment-apps-api/#selectable-app-information-display 14:37:05 q+ 14:37:11 q- 14:37:36 IJ: 14:37:45 Q. Should merchant provide metadata or should that be the payment app manifest? 14:38:05 Q. How does registration work when the user selects a recommended payment app (e.g., it's an option) 14:38:14 ack Adr 14:38:14 AdrianHB, you wanted to mention existing discussion between manifest and serviceworker devs 14:39:06 AdrianHB: In the manifest group, JakeA and a number of people started speaking about how manifest relates to service workers..they came up against the same issue - the need to register a service worker before the service worker can tell you about itself 14:39:15 ...manifests are just static files that the browser can just fetch 14:39:28 ...so I think this is another conversation we should have with Marcos and Jake 14:39:34 ...we should list our requirements clearly 14:39:54 ..I think I agree with Ian that it feels awkward for the merchant to label apps that are not theirs. 14:40:08 ...but I agree we don't want to show the user a service workers JS file URL 14:40:58 +1 14:41:20 +1 adam 14:41:36 IJ: Is registration needed when user selects a recommended payment app? 14:41:59 AdamR: I can easily see merchants wanting to provide their own text like "Save 5% with bob pay"...so I think there are use cases for merchant-provided metadata 14:42:02 Jason: +1 14:42:16 AdrianHB: Does it make sense for merchants to be able to supplement payment app metadata? 14:42:23 q+ 14:42:34 ...e.g., a brand would not want a merchant to use an old logo or, worse, provide their own icon for my brand 14:42:36 q+ 14:42:58 ...so I think naming the app or icons should be out of scope for the merchant but the merchant should provide supplemental info 14:43:00 ack jn 14:43:03 q- (Jason made my comment) 14:43:06 q- 14:43:19 jnormore: That's how it is today....merchants have to comply with branding requirements as part of relationships with payment providers 14:43:49 ...I think there are too many cons to restricting the merchant's ability to provide information that is displayed to the customer from the merchant standpoint 14:44:10 ..not just to indicate discount information, but if I have an agreement with a provider to show a different or better icon for my store, I need to be able to do that 14:44:13 q? 14:44:25 Summary: 14:44:45 * Some consensus around a combination of merchant-provided information about a recommended payment app + more details in a payment app manifest 14:44:51 q+ 14:45:25 jnormore has joined #apps 14:45:28 IJ: what's the impact on the spec? Is there merchant-provided name/icon and a link to SW JS? 14:45:28 ack Ad 14:45:41 adamR: So far we have not required an external payment app manifest.... 14:46:01 ...I hesitate to require it since so much will be redundant with registration data 14:46:23 ..on the question of whether we would need to instantiate a service worker in order to use the payment app, I think the answer is "yes" 14:46:38 ...due to execution environment of the service worker. 14:47:21 IJ: I am hearing that registration is a pre-requisite for web-based payment apps (in a service worker sense) 14:47:39 Jason: There are multiple concepts: 14:48:33 Can we limit the use of the word “register” in this context to the formal definition here, please? https://www.w3.org/TR/service-workers/#register-algorithm 14:48:40 a) Information sufficient to display a payment app for selection. For recommended payment apps, this comes from the merchant. 14:49:03 b) Service worker registration 14:49:17 c) user relationship to payment provider (e.g., getting a paypal account) 14:49:56 (That only is about the web based payment app case....for native apps there's some other way the browser knows about the payment apps) 14:50:52 IJ: Please clarify the relationship between the payment app manifest and the service worker 14:51:20 My favourite topic... The difference between a manifest and a manifest file 14:51:31 adamR: In service worker spec, there is an object called a "manifest" that has icons, options, etc.; it's a data structure that's instantiated by the script that registers the service worker; it's not a separate addressable file 14:51:58 ...a "manifest" can only be accessed by the thing accessing the service worker. 14:52:13 ..sequentially you cannot get the information in the manifest until after the SW has been registered 14:53:23 q+ 14:53:35 IJ: So the browser overrides the payment app manifest when the merchant provides icon/name? 14:55:04 -1 for merchant taking prec. As a user I don't expect the icon of something I installed to change 14:55:17 IJ: I am hearing that the merchant data overrides any registered data..and that registration of an unregistered recommended payment app happens upon selection by the user 14:55:23 ack rous 14:55:55 rouslan: There was a point about recommended payment app information overriding registered payment app info. I think that's too complex. If the payment app is registered already, the user agent should use that information. 14:56:04 +1 rouslan 14:56:23 Jason: +1 to rouslan 14:56:57 (Comment about user confusion if icon changes) 14:57:30 Jason: I feel we are coupling the "implementation" of a payment app (service worker) from the "definition" of a payment app (which is merchant-provided) 14:59:19 IJ: Simplest model for me is that "recommended" is simply "Show icon+logo, and register then run on user select" 14:59:59 IJ: Do we need to specify behavior for non-web recommended payment apps? 15:00:01 Rouslan: No 15:00:17 q+ to say that this still doesn't address the merchant wanting to incentivize use of an app 15:00:29 ack Ad 15:00:29 AdrianHB, you wanted to say that this still doesn't address the merchant wanting to incentivize use of an app 15:01:00 AdrianHB: If I don't have a payment app installed and the merchant recommends one, then they provide a name/icon. In the dialog is a set of recommended payment apps "Use Bobpay for 5%" 15:01:21 ..if I have bobpay installed, how does the merchant convey that information if the user can't override the label/icon? 15:01:51 ....so I think we need to balance merchant-provided info with user interface consistency and payment app registration-provided information 15:02:21 FYI re the manifest vs manifest file terminology: https://github.com/w3c/webpayments-payment-apps-api/issues/48#issuecomment-261474539 15:02:56 ACTION: Ian to summarize discussion on issue 74 thread and mention merchant-provided info when app already registered as a thing that needs to be addressed 15:04:10 alyver has left #apps 15:04:57 I have made the request to generate http://www.w3.org/2017/01/04-apps-minutes.html Ian 15:10:05 adamR? 15:10:16 I just loaded http://www.w3.org/2017/01/paymentapps-2017.ics 15:10:19 and it seems ok to me 15:10:29 It shows Tuesday at 10am ET 15:11:48 hmm 15:13:47 the ics is weird but does seem correct 15:13:54 Ian: Double-checking 15:14:11 There's a block called "VTIMEZONE" whose purpose is unclear to me 15:14:20 but later on in "VEVENT" it seems ok 15:14:51 specifically: 15:14:51 DTSTART;TZID="Eastern Time":20170110T100000 15:14:52 DTEND;TZID="Eastern Time":20170110T110000 15:14:52 RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=TU 15:25:09 Ian — sorry, had to hop on a short call 15:25:20 np 15:28:07 Ah! I see what happened. I took the ICS file from the emailed agenda, which I thought had been updated. 15:34:41 adamR has joined #apps 15:43:19 done 15:43:24 Thanks! 15:43:32 those things are generated by webex, I think, but I hand-removed from the version on the web 15:44:24 Yeah, calendaring is hard. Interpretations of .ics files are… quite varied. 15:44:47 I think Apple is off in the weeds here, but it’s the tool a lot of people have. 15:51:44 kayakalan has joined #apps 15:52:10 hello back 15:52:22 Ian2 has joined #apps 16:05:28 Ian2 has left #apps 17:11:04 adamR_ has joined #apps 18:51:01 adamR_ has joined #apps