13:01:41 RRSAgent has joined #apps 13:01:41 logging to http://www.w3.org/2016/08/03-apps-irc 13:02:08 agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2016Aug/0031.html 13:02:22 present+ Ian 13:02:27 present+ JNormore 13:02:35 present+ Tommy 13:04:05 regrets+ AdrianHB 13:05:51 agenda+ Registration 13:05:54 agenda+ Selection 13:05:56 agenda+ Trust 13:06:00 agenda+ Design considerations 13:06:04 agenda+ Priority edits 13:06:07 agenda+ TPAC planning 13:06:18 Ian has changed the topic to: https://lists.w3.org/Archives/Public/public-payments-wg/2016Aug/0031.html 13:06:53 present+ Ben 13:07:07 zakim, take up item 1 13:07:07 agendum 1. "Registration" taken up [from Ian] 13:07:39 Issue 8: Is registration "necessary"? 13:07:39 https://github.com/w3c/webpayments-payment-apps-api/issues/8 13:07:39 Action: JasonN to write a proposal about minimizing the effort to 13:07:39 register payment apps, calling out merchant recommendations, browser 13:07:39 recommendations, and user initiated registration 13:07:41 ben has joined #apps 13:07:52 JNormore: I will have it for 10 August meeting 13:07:59 zakim, close item 1 13:07:59 agendum 1, Registration, closed 13:08:00 I see 5 items remaining on the agenda; the next one is 13:08:00 2. Selection [from Ian] 13:08:04 zakim, take up item 2 13:08:04 agendum 2. "Selection" taken up [from Ian] 13:09:31 q+ 13:09:42 ack kjnormore 13:09:44 ack j 13:10:06 jnormore: I chatted with Zach about this. From a merchant perspective, especially in the early days (while still working on adoption of payment apps) 13:10:29 ...some merchants may want to show a single button, for example. 13:10:52 ...I would (as a merchant) want to have a single button to instantiate the payment app without the customer having to do a second thing. 13:11:02 IJ: +1; that's what this issue is about. 13:12:44 IJ: There's a second case where the payment app returns immediately based on what the user has selected in the user agent's display 13:12:52 jnormore: "Headless app" 13:13:40 IJ: Questions 13:13:50 1) Do we need to specify anything related to the user experience (or just guidance)? 13:14:10 2) To enable the desired UX, do we need to specify anything (e.g., some data that payment apps need to do the right thing)? 13:14:25 jnormore: +1 to guidance 13:14:36 ...I think most payment apps will seek the best experience 13:15:21 IJ: I can see the spec saying "when only one matching app, UA SHOULD bypass the selection box and go straight to launch" 13:17:30 present+ Kepeng 13:18:27 Kepeng has joined #apps 13:18:58 q+ 13:18:59 IJ: E.g., does the user agent need to tell the payment app "This one was selected"? If so that seems to be part of the standard. 13:19:28 ack To 13:20:09 Tommy: We're talking about skipping selection in the UA and headless payment apps...what I want to avoid happening is to enable the user to click a button and then payment happens without consent from the user. 13:20:21 q+ 13:20:29 ...if user agent and payment app are both at liberty to automate, you might have too easy of an experience 13:20:30 ack jnormore 13:20:51 jnormore: There are two views on whether that experience is great or dangerous. 13:21:21 would be good to see some UX mock ups - is that possible? thx 13:21:55 IJ: +1 to calling out the consent point and letting the UA or payment app manage it 13:23:40 IJ: +1 to writing up how different experiences will work 13:23:51 ...I am happy to be part of a team to write that up. 13:23:54 Ben: I can help 13:24:20 ..it would be worth documenting them to be on same page and see whether we've thought through the potential experiences 13:25:18 ACTION: Ian to organize a chat with Ben on writing down different user experiences 13:25:28 Ben: Let's try to look at the whole user experience 13:26:17 ...will help get consistency and interop 13:26:35 What should be the user experience when an app is 13:26:35 recommended for two methods? (issue 11) 13:26:40 https://github.com/w3c/webpayments-payment-apps-api/issues/11 13:28:14 IJ: +1 to tommy's suggestion we remain silent on this 13:28:27 +1 13:28:57 I have made the request to generate http://www.w3.org/2016/08/03-apps-minutes.html Ian 13:29:13 rrsagent, set logs public 13:29:25 zakim, close this item 13:29:25 agendum 2 closed 13:29:26 I see 4 items remaining on the agenda; the next one is 13:29:26 3. Trust [from Ian] 13:29:27 zakim, take up item 3 13:29:27 agendum 3. "Trust" taken up [from Ian] 13:32:37 q+ 13:32:49 ack jnormore 13:32:56 jnormore: There are two sides to this question ... 13:33:10 ...from a merchant perspective I definitely want control and to tweak which payment apps I accept 13:33:17 ...which payment apps convert the best 13:33:53 ...from the customer experience, if we allow merchants to restrict payment apps, it requires that the customer install multiple payment apps for the same payment method. So that will complicate the user experience for the same payment method 13:35:04 IJ: How might this play out? 13:35:19 IJ: E.g., will merchants gravitate towards a small number of apps? 13:35:30 jnormore: Today merchants have "multiple payment apps" today 13:36:04 ben: If you look at what goes on in the real world: merchants accept payment methods, and users have preferences ... but it's up to the merchant who decides what they accept 13:36:33 ...I think that consumers are used to transacting that way...if you take that experience and put it into that scenario, it will mirror today's world 13:41:30 Ben: I think having options is the right way to go 13:41:34 ...give consumers options 13:41:44 ...each option will have strengths 13:42:03 q+ to ask whether merchant can help instantiate the user's payment app 13:43:03 Ben: Some options will work better in some scenarios than others 13:43:05 ack me 13:43:05 Ian, you wanted to ask whether merchant can help instantiate the user's payment app 13:44:06 q+ 13:44:17 IJ: Would it be useful if a merchant already has this data (e.g., card info stored) that the merchant can recommend an app and the data is already in the app 13:44:39 ack jnormore 13:45:01 jnormore: I'm not sure that we'll find any merchants willing to pull stored data out of a vault and pass it to another vault. 13:45:11 ben: Also some PCI issues 13:45:13 ...and privacy as well 13:46:16 IJ: The merchant could share a token and the payment app could send that back 13:46:45 Ben: If the PSP can act as TSP that might be interesting. 13:49:04 IJ: What is the app identification mechanism? What do we need? URLs? Origins sufficient? 13:49:24 jnormore: I would lean towards granular approach. I don't think domain will suffice 13:50:25 Max has joined #apps 13:51:12 present+ Dapeng 13:51:50 Two app identification use cases: 13:51:52 * recommended apps 13:52:02 * I only support X, Y, Z (filter by merchant) 13:52:46 ACTION: Ian to add to design considerations the app identification bits for this issue 13:52:59 q? 13:53:03 zakim, close this item 13:53:03 agendum 3 closed 13:53:04 I see 3 items remaining on the agenda; the next one is 13:53:04 4. Design considerations [from Ian] 13:53:06 zakim, take up item 4 13:53:07 agendum 4. "Design considerations" taken up [from Ian] 13:53:20 Review action - Conor and JasonN will send comments on the text. 13:53:25 JasonN: I will send notes later today 13:53:37 ...most of my comments are around open and proprietary 13:54:05 ..I think we should dig into that more..the industry is currently weighted towards proprietary and standardization effort are weighted towards open 13:54:21 zakim, close this item 13:54:21 agendum 4 closed 13:54:22 I see 2 items remaining on the agenda; the next one is 13:54:22 5. Priority edits [from Ian] 13:54:34 zakim, take up item 5 13:54:34 agendum 5. "Priority edits" taken up [from Ian] 13:55:09 - app identification 13:55:15 - merchant filter on apps 13:55:25 - user experience recommendations 13:55:37 - registration bits 13:55:57 https://github.com/w3c/webpayments-payment-apps-api/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aclosed%20 13:56:02 - JavaScript listener 13:56:13 - proportion of payment request data sent to app (resolved) 13:56:34 IJ: we have editors for some of those things, not all. 13:56:48 ...maybe AdrianHB needs to write up the JS bits 13:57:05 IJ: I can write up the "subset of payment data" part 13:57:34 zakim, take up item 6 13:57:34 agendum 6. "TPAC planning" taken up [from Ian] 13:57:37 What goals should we have? 13:57:49 +q 13:58:14 ack Max 13:58:52 Max: Does "user experience recommendations" include what we discussed in London? 13:58:55 Ian: Yes. 13:59:02 Max: I can help with user experience bits 14:00:35 IJ: One goal would be to have (1) mature spec and (2) strong design considerations that have support so that => there is strong support at TPAC for going to FPWD. 14:00:39 +1 14:01:10 Topic: next meeting 14:01:14 10 August 14:01:24 (Any regrets?) 14:01:28 I have made the request to generate http://www.w3.org/2016/08/03-apps-minutes.html Ian 14:01:34 rrsagent, set logs public