12:54:28 RRSAgent has joined #apps 12:54:28 logging to http://www.w3.org/2016/10/05-apps-irc 12:54:30 Zakim has joined #apps 12:54:46 Ian has changed the topic to: Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2016Oct/0005.html 12:55:01 Meeting: Payment Apps Task Force 12:55:04 agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2016Oct/0005.html 12:55:08 Chair: Ian 12:55:14 agenda+ trust 12:55:19 agenda+ native app integration experience 12:55:24 agenda+ registration 12:55:27 agenda+ getting to FPWD 12:55:32 agenda+ other issue review 13:02:21 present+ Ian 13:02:24 present+ Tommy 13:02:27 present+ Pascal 13:02:44 jnormore has joined #apps 13:02:47 regrets+ Max 13:03:09 present+ adamR 13:03:42 betehess has joined #apps 13:03:49 betehess has left #apps 13:03:59 present+ jnormore 13:05:57 zakim, take up item 1 13:05:57 agendum 1. "trust" taken up [from Ian] 13:08:51 q+ 13:08:59 IJ: What mechanisms do we need for trust in web-based payment apps? 13:09:04 ...e.g., whitelists? 13:09:19 adamR: What are the attacks we are worried about? I think many of them are addressed by the web platform directly. 13:09:34 ...I would not put more protections around them except where the platform does not already support them. 13:09:49 +1 not the browsers place 13:09:50 ...I don't think the browser should play a role in the ecosystem that involves whitelists 13:10:17 ...the prospect of consistent white lists across browsers would be near impossible (hard already with certs) and that would make web-based payment apps DOA. 13:10:21 q+ 13:10:34 ..and if we enable the merchant to do whitelists, then we've made payment method concept obsolete. 13:10:45 ...so -1 to whitelisting by browser/merchant 13:10:49 ack ad 13:10:52 ack jnormore 13:11:45 jnormore: My biggest concern as a merchant representative is trust between payment service and merchant. Browser has no place determining what customer can use and what merchant can offer. 13:12:01 ...but I do think that the merchant should be able to express which apps it prefers. 13:12:16 ...I do know merchants who would go further and want to restrict apps that users can use 13:12:20 q+ 13:12:24 ack ad 13:12:39 adamR: Can you speak more about trust concerns from payment requestors? 13:13:29 jnormore: I think the most important concern is "what the user experiences" 13:15:19 IJ: One point AHB made was that if browsers curate in some fashion, that users be able to override browser warnings (cf certificates) 13:16:47 IJ: What lessons have been learned from plug-ins, for example, that we might anticipate here? 13:17:10 adamR: Plug-ins and add-ons...not sure we can learn a lot there. Add-ons largely had free run of the browser...the Web is moving away from both of those models. 13:17:17 ...both Mozilla and google are deprecating npapi. 13:17:26 ...we are moving in the direction of web extensions 13:17:41 ...all of that said, what is being proposed for web based payment apps is taking this even further 13:17:52 ...all you can do with a web application are things you can do on the web.... 13:17:57 ...they can only operate in the scope they are allowed to 13:18:14 ...we are only adding two small things for payments: (1) being pulled up for a match and (2) thin amount of communication 13:18:21 ...I don't think the latter changes the security properties. 13:18:37 pascal_bazin has joined #apps 13:19:47 IJ: Any other mechanisms necessary re: user experience? 13:20:24 adamR: I am sympathetic to that concern...but we should also not support a "best viewed with" perspective 13:21:21 jnormore: As long as the merchant has some ability to push recommendations to the customer, I think that addresses the problem 13:21:43 q+ 13:22:03 ack pas 13:24:48 zakim, take up item 2 13:24:48 agendum 2. "native app integration experience" taken up [from Ian] 13:24:53 See Rouslan document -. https://docs.google.com/document/d/1izV4uC-tiRJG3JLooqY3YRLU22tYOsLTNq0P_InPJeE/edit?usp=sharing 13:25:55 zakim, take up item 3 13:25:55 agendum 3. "registration" taken up [from Ian] 13:26:27 (Payment options) 13:27:12 q+ 13:27:30 Proposed: Version has app-level granularity in the mediator. 13:27:33 ack ad 13:27:33 +1 13:27:41 +1 13:28:18 adamR: I think what we have in the payment app spec supports payment options...there's a mechanism to display that and give info of which was selected back to the payment app. 13:28:28 ...I think this adds almost no complexity and allows significantly better user experience. 13:29:20 IJ: Please say more about why you support removal. 13:29:38 TommyT: I'm happy with keeping things simple in v1...if it turns out it's not a lot of complexity, I'm not against keeping it in. 13:30:23 jnormore: I also want to keep things simple. I think there is complexity about what is shared with whom. 13:31:47 IJ: Can we design in a way that browsers MAY use this. 13:32:12 adamR: The way I put the text together is there is an ID for each option. When the payment app gets control, it gets the ID of the selected option 13:32:28 q+ 13:32:31 ..if you want the browser to be able to render options or just the app, then 13:33:09 ...we make the ID nullable; if it shows up as null then the payment app would be required to figure out which option to user, probably by querying the user. 13:33:20 present+ AdrianHB 13:33:33 ...the one last thing I want to say on this is that we (mozilla) have been speaking to payment providers and they seem awfully hung up on being able to represent some card art. 13:33:41 ...this seems to be a high order priority for them 13:33:59 ...so given that priority + low complexity I would be inclined to keep 13:35:12 adamR: Having it be "optional" makes this more complex (for app providers) 13:35:27 AdrianHB: Right, app providers have to handle both cases (ID present or not) 13:35:44 jnormore: There's an implication here of registration (IDs for options) 13:35:53 ...would this still work when there is not registration? 13:36:37 adamR: I don't yet understand how unregistered payment apps work (and how they communicate payment methods and payment options)...once we figure that out it should be straightforward to communicate option information 13:36:59 ...what I envision we will probably have is an ephemeral registration - same information is communicated but that data is subsequently forgotten 13:37:57 IJ: +1 to ephemeral registration model 13:38:16 +1 13:38:36 IJ: I would like to add a note in the spec that unregistered apps would communicate in the same was (and same data) as registered payment apps; just the data is forgotten 13:38:51 ACTION: jnormore to write up this point on ephemeral exchange of data for unregistered payment apps 13:38:58 q? 13:39:04 ack jn 13:39:43 IJ: I am hearing more people prefer keeping payment options for now 13:40:08 ACTION: Ian will restore payment options 13:40:17 AdrianHB: We'll want to circle back with Rouslan 13:40:58 zakim, take up item 4 13:40:58 agendum 4. "getting to FPWD" taken up [from Ian] 13:41:23 IJ: Shane has done reviews 13:41:28 ...awaiting reviews from zach + Max 13:42:31 Plan: 13:42:32 q+ to ask about implementors 13:42:42 * Get reviews from zach, max 13:42:47 * Make edits and resolve other issues to the extent we can 13:43:23 * Either week to review + CFC / or / CFC directly here 13:43:24 ack Ad 13:43:24 AdrianHB, you wanted to ask about implementors 13:43:48 AdrianHB: I wanted to note a few conversations I've had in Lisbon and find out from Adam and Tommy what the plan is for implementation of the payment app spec. 13:44:15 ...I think some folks thing of web based payment apps as a desktop phenomenon 13:44:29 ...so for some vendors there may not be web-based payment apps in the near term. 13:44:43 q+ 13:44:46 ...Mozilla / Opera / Samsung are best candidates for implementation right now 13:44:50 q+ 13:44:54 ack adamR 13:44:55 q+ 13:45:21 adamR: I am not in position to give a timeline right now...when we implement PR API my expectation is we will implement payment app API in parallel 13:45:35 ack To 13:45:54 TommyT: We are very interested in web based payment apps 13:45:58 ...also native apps 13:46:09 ...the only thing that has kept us from doing a proper integration is the state of the spec 13:46:14 (Hey!!!!! :( ;) 13:46:46 +1 - we also need interest from app publishers to publish web-based apps 13:47:26 q+ 13:47:30 ack me 13:47:49 IJ: I have been talking with some companies about web-based payment apps 13:48:04 jnormore: We are interested from the merchant perspective AND from the payment provider perspective in web-based payment apps 13:48:33 ...regarding web-based payment apps and desktop, I disagree....I think it's EVEN MORE important on mobile 13:48:53 ...that web-based payment apps be considered a mobile offering as well 13:49:01 Great! 13:50:42 IJ: I have also heard that having web-based on mobile will be useful (e.g., convenience stores + digital offers) 13:51:06 IJ: My thought is that implementation experience will pick up (I hope) after FPWD 13:52:28 q+ to discuss Mahesh's proposal 13:52:34 topic: Detecting if payment app available 13:52:40 Mahesh proposal -> https://github.com/maheshkk/webpayments/wiki/Detecting-if-payment-app-is-available 13:52:44 ack me 13:52:48 ack AdrianHB 13:52:48 AdrianHB, you wanted to discuss Mahesh's proposal 13:53:10 (We will leave it for tomorrow's conversation) 13:53:37 AdrianHB: I think that one CAN do what Mahesh wants through hacky methods and we can't prevent; so making it cleaner is appealing 13:53:58 I have made the request to generate http://www.w3.org/2016/10/05-apps-minutes.html Ian 13:54:26 Topic: Getting PR API to CR 13:54:42 AdrianHB: I think app implementation experience (both native and web) will give confidence in shape of PR API 13:55:18 adamR: I look forward to hearing back from Zach 13:56:04 AdrianHB: I think that integration of some push-based payment methods is valuable right now (re: shape of PR API) 13:56:16 I have made the request to generate http://www.w3.org/2016/10/05-apps-minutes.html Ian 13:59:30 Topic: Next meeting 13:59:33 12 October 13:59:37 rrsagent, make minutes 13:59:37 I have made the request to generate http://www.w3.org/2016/10/05-apps-minutes.html Ian