14:48:33 RRSAgent has joined #apps 14:48:33 logging to http://www.w3.org/2017/01/31-apps-irc 14:48:50 Meeting: Payment Apps Task Force 14:48:53 Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Jan/0104.html 14:48:55 Chair: Ian 14:49:04 regrets+ Frank 14:49:20 Ian has changed the topic to: 31 Jan agenda https://lists.w3.org/Archives/Public/public-payments-wg/2017Jan/0104.html 14:56:56 alyver has joined #apps 15:01:21 present +alyver 15:03:02 present+ AdrianHB 15:03:03 present+ 15:03:56 pascal_bazin has joined #apps 15:05:40 present+ 15:05:44 zakim, who's here? 15:05:44 Present: AdrianHB, Ian, adamR 15:05:46 On IRC I see pascal_bazin, alyver, RRSAgent, Zakim, adamR, AdrianHB, Dongwoo, Ian 15:05:54 present+ alyver 15:05:57 present+ pascal 15:06:00 present+ rouslan 15:06:05 zakim, who's here? 15:06:05 Present: AdrianHB, Ian, adamR, alyver, pascal, rouslan 15:06:07 On IRC I see pascal_bazin, alyver, RRSAgent, Zakim, adamR, AdrianHB, Dongwoo, Ian 15:06:31 topic: Proposal for moving forward 15:06:36 https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130 15:06:37 rouslan has joined #apps 15:06:45 present+ 15:07:09 IJ: Have people had a chance to review this? 15:08:39 q+ to make a few comments re the proposal, didn't have a chance to respond 15:09:35 ack AdrianHB 15:09:35 AdrianHB, you wanted to make a few comments re the proposal, didn't have a chance to respond 15:09:55 AdrianHB: Some other things I had wanted to point out that did not make it into the proposal, and Dave Longley commented on this as well. 15:10:35 Payment apps are not "just service workers"; we've spoken about them that way before and I think that has created confusion. 15:10:49 ...I prefer that we model the world as "Payment apps are web apps with special features are are defining for payments" 15:11:57 ...I think the proposal says this to those coming in cold; but for those who have been following the discussion, it might need more clarification 15:12:29 q? 15:13:03 https://lists.w3.org/Archives/Public/public-payments-wg/2017Jan/0105.html 15:14:39 q+ 15:15:01 IJ: The first question is about payment app identity, use of origin...and whether we want to enable display of two payment apps from the same origin (e.g., consumer and corporate) in the sheet. 15:15:02 ack rous 15:15:29 rouslan: Based on our experience with android payment apps, we have found that the concept of one payment app per origin works well and is easy to implement. 15:15:42 q+ to discuss why you need to identify a payment app and differentiate between giving the user choices in the UI 15:15:51 ...android pay we show as a single item in the UI...but when you launch the app, you can change accounts (which might have different cards associated with them). 15:16:37 ...so I support and implementation experience with native that we keep to a minimum the number of payment apps per origin, with "1" being the best solution. 15:16:39 q? 15:16:43 q+ 15:16:46 ack Ad 15:16:50 q? 15:16:54 q+ adamR 15:16:57 ack Adr 15:16:57 AdrianHB, you wanted to discuss why you need to identify a payment app and differentiate between giving the user choices in the UI 15:17:12 AdrianHB: I think what Rouslan is talking about is "options presented to the user" which is supported by the spec. 15:17:27 ...options can be presented to the user (icons, labels) 15:17:38 ..if we can talk about multiple options per origin we can probably address use cases. 15:18:43 IJ: We have two use cases for identification: (1) recommended (2) payment method manifest 15:18:45 q+ 15:18:49 AdrianHB: For the second use case I think origin suffices 15:19:51 ...and start_url can be used to point to code 15:19:53 For my upcoming comment: https://dl.dropboxusercontent.com/u/53717247/amex.png 15:20:09 q+ 15:20:18 q+ to speak to display of apps 15:20:22 ack ada 15:20:47 adamR: I don't think payment options satisfies the use cases I think I've heard; see https://dl.dropboxusercontent.com/u/53717247/amex.png 15:21:17 ..the prospect of mashing business and consumer as options under one app would not have worked 15:21:34 ...I think we have use cases for more than one thing per origin. 15:21:36 q? 15:21:38 ack rouslan 15:22:02 I think that adamR's use case could be addressed by two payment apps at business.amex.com and personal.amex.com. 15:22:18 rouslan: I think it is ok to not handle recommended payment apps today. Merchant can attempt to show() and if that doesn't work, then the merchant can show users links 15:22:48 AdrianHB: I think asking busineses to change their URLs — which some consider part of their branding — to accomodate this kind of thing is letting the tail wag the dog 15:22:56 q? 15:23:07 q+ to talk to subdomains 15:23:14 ack me 15:23:14 Ian, you wanted to speak to display of apps 15:23:40 Ian: Let's hold off discussing recommended payment apps for now; main question is "whether 2 things from same origin can appear in the sheet" 15:23:43 ack AdrianHB 15:23:43 AdrianHB, you wanted to talk to subdomains 15:23:58 q+ 15:24:24 AdrianHB: I agree with AdamR that asking businesses to change URLs is not ideal, but I've had this discussion with web app sec before. 15:24:40 ...I am concerned that we are going down the wrong path by delineating apps from the same origin 15:24:47 ...I think it suffices that apps can register options 15:25:06 ..but if you want to offer two things that are more serrated, you should do it at more origins (e.g., using subdomains) 15:25:07 q? 15:25:09 ack ad 15:25:51 adamR: I think what we need is the concept of "two things" (whatever they are called, but a level above options) 15:26:30 q+ to clarify if this is just a UI req? 15:26:35 ...so perhaps we don't call these different things "apps" but I think it's a valid use case 15:26:40 ack Ad 15:26:40 AdrianHB, you wanted to clarify if this is just a UI req? 15:26:48 AdrianHB: Is this just a UI requirement? 15:27:04 ...if so, that sounds to me like a new proposal, but one that would not be problematic 15:27:53 ...on the other hand, I don't want to go too far down the road into UI 15:28:42 ...instead I would say "let's agree that permissions are for origin, and if we need to handle use cases with UI requirements, let's work on that" 15:28:44 adamR: +1 15:29:59 AdrianHB: So I am hearing (1) a payment app is a specialization of a web app, identified by origin (2) AdamR suggests we need some granularity in choices presented to the user (more nesting). 15:30:16 AdamR: This is not really just UI; it's semantics 15:30:36 AdrianHB: Agreed, change UI to UX 15:31:02 ..the ability is for payment app publishers to organize options presented to the user 15:31:10 ...I think we need to spell out the use cases more clearly 15:31:10 q+ 15:31:48 IJ: Has this come up, Rouslan, in native? 15:32:26 rouslan: This hasn't come up. We do use the web for some identity verificaiton 15:32:39 ..the security there comes from the fact that the identifying URL is owned by the payment app distributed 15:33:07 ...we care that the URL is secure (HTTPs)..the separation among origins does not affect us 15:33:08 ack pascal_bazin 15:33:40 pascal_bazin: It seems that registering a payment app means that the payment app needs to be defined in the merchant's security domain. 15:33:52 ...this would be a limitation..it would mean that merchants need to implement more 15:34:14 q+ 15:34:30 q- 15:37:24 IJ: I am hearing ok to think of 1 payment app per origin but need to flesh out use cases for more levels of organization from the payment app side. 15:37:35 +1 15:37:37 +1 to use cases 15:37:58 I'd be willing to help with use cases 15:38:13 but looking for other volunteers :-) 15:38:26 ACTION: alyver to write up use cases for additional organizational capabilities for payment apps (within a model of one app per origin0 15:38:47 IJ: says "wallet" smirkingly 15:38:52 Off the top of my head, use cases are: 15:38:52 1. White label payment apps 15:38:52 2. Multiple profiles with a single provider (business vs personal) 15:38:52 3. Multiple instruments held with a single provider 15:38:55 AdamR: Don't smirk; that might be useful 15:40:18 Topic: Things that require permission or that don't 15:40:39 AdamR: We need to be clear on what requires user consent and what can happen automatically. 15:40:55 ...I think the proposal says that registering for events requires permission but registering payment method support does not. 15:41:07 ...do others agree (and can we write that down clearly)? 15:41:17 +1 15:41:19 +1 15:41:23 +1 15:41:45 ACTION: Ian to update the proposal to reflect one app per origin and highlight need for user cases regarding granularity 15:41:59 ACTION: Ian to update the proposal to clarify what requires permission and what can happen automatically 15:42:18 Topic: Filtering 15:43:54 The comment Ian refers to is here: https://github.com/w3c/webpayments-payment-apps-api/issues/99#issuecomment-276264871 15:44:09 q+ to ask some clarifying q's re filtering 15:44:44 IJ: we have establish where filtering happens, and if in the payment app, how to address concerns about functions 15:44:46 ack adr 15:44:46 AdrianHB, you wanted to ask some clarifying q's re filtering 15:45:17 q+ 15:45:43 AdrianHB: I wanted to be sure I am on same page as others. My understanding is that PR API does filtering on payment method and basic-card 15:45:54 IJ: I don't think that's it. It think browser is implementing filtering "as a payment app' 15:47:11 q+ 15:47:14 ack adamR 15:47:59 IJ: I understand: 15:48:05 - Mediator filters on payment methods 15:48:36 - Mediator queries payment apps to see which ones that support those payment methods can handle this payment request 15:48:46 - Mediator displays the resulting subset 15:48:50 - User picks one to continue 15:49:41 IJ: Browser acts as payment app for basic card and in that capacity does filtering. 15:50:18 q+ 15:50:25 ack me 15:50:37 ack adam 15:51:30 IJ: We have determined both that we don't expect browsers to implement generic filtering (based on what they told us) , and therefore that payment apps will need to do the filtering. 15:51:50 ...then the question is how to ensure privacy in the mediator query phase. 15:52:56 adamR: Did anyone lay out an algorithm for generic filters? 15:53:02 Ian/AdrianHB: Yes. 15:54:50 https://github.com/w3c/webpayments-payment-apps-api/issues/96#issuecomment-275445099 15:54:53 AdamR: I think we should revisit browser doing canHandle, limiting to strings 15:55:43 https://github.com/w3c/webpayments-method-identifiers/issues/5 15:56:04 https://github.com/w3c/webpayments-method-identifiers/issues/5#issuecomment-225665121 15:59:18 IJ: But down side of this approach is we don't know what the generic filtering language ACTUALLY requires. 16:00:36 IJ: Suppose we do browser implementation of canHandle. When does the browser get the data? 16:00:56 If static at registration, ok. But if dynamic at transaction time, then same as asking payment app to answer the question. 16:02:25 AdamR: -1 to browser to asking payment apps for data during transaction 16:02:36 AdrianHB: Agree with AdamR 16:03:09 IJ: Let's continue discussion 16:04:57 IJ: We need to determine whether static data provided by payment app satisfies the use case. 16:06:13 Rouslan: I have been thinking about config option where payment app provides info to the browser, at least for basic card 16:06:30 ...the info that the payment app provides is network and type 16:06:55 ACTION: AdamR to write up a proposal for payment app-provided config information for filtering by browser 16:07:04 ACTION: Rouslan to write up a proposal for payment app-provided config information for filtering by browser 16:07:14 Filters (at least the names of them) can also be defined in the payment method manifest 16:07:25 Topic: next meeting 16:07:28 7 Feb 16:07:34 I have made the request to generate http://www.w3.org/2017/01/31-apps-minutes.html Ian 16:07:38 RRSagent, set logs public 16:07:55 AdrianHB: As I say above, I’ll be commenting in issue #96 18:05:10 Zakim has left #apps