12:40:27 RRSAgent has joined #apps 12:40:27 logging to http://www.w3.org/2016/10/19-apps-irc 12:40:34 Meeting: Payment Apps Task Force 12:40:35 agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2016Oct/0025.html 12:40:36 Chair: Ian 12:52:49 agenda? 12:52:52 agenda+ upcoming meeitngs 12:53:18 agenda+ payment apps and filtering 12:53:25 agenda+ native app implementation experience 12:53:35 agenda+ Pascal's implementation experience 12:53:42 agenda+ registration 13:01:44 jnormore has joined #apps 13:02:19 conorhwp has joined #apps 13:02:21 hmm 13:02:27 we are at: 13:02:55 Thanks Ian, trying that one now. Previous link was locked. 13:03:05 ah, maybe I have outdated data ;( 13:03:16 I am getting " The host has restricted meeting access to those currently in attendance" 13:03:23 let me try something 13:03:27 Thanks 13:03:38 The one from the invite was https://mit.webex.com/mit/j.php?MTID=m711a92b5a262a7938cfab69d116c980b 13:04:02 Also locked 13:04:04 weird 13:04:23 somebody arrived.... 13:04:25 Mahesh 13:04:57 it seems people are dialing in 13:05:03 and for some reason WebEx UI is not working 13:05:34 I tried dialling in with the number on invite but was locked out also. 13:05:39 present+ Mahesh 13:05:40 What number are people using to get in? 13:05:42 present+ Ian 13:05:49 US Toll Number +1-617-324-0000 13:05:51 640 633 363 13:05:58 present+ Pascal 13:06:00 present+ Rouslan 13:06:07 present+ AdamR 13:06:11 rouslan has joined #apps 13:06:14 regrets+ Matt 13:06:17 present+ Rouslan 13:06:23 pascal_bazin has joined #apps 13:06:27 conorhwp: It looks like the web interface is working now 13:06:27 present+ Andre 13:06:34 present+ jnormore 13:06:53 adamR: great thanks 13:08:10 https://w3c.github.io/webpayments-payment-apps-api/ 13:09:26 present+ conor 13:09:33 agenda => https://lists.w3.org/Archives/Public/public-payments-wg/2016Oct/0025.html 13:09:37 agenda? 13:09:39 alyver has joined #apps 13:09:43 zakim, take up item 1 13:09:43 agendum 1. "upcoming meeitngs" taken up [from Ian] 13:09:51 Upcoming meeting schedule: 13:09:51 * 2 Nov, 16 Nov, 23 Nov, 30 Nov, 7 Dec, 14 Dec, 4 Jan 2017 13:10:42 AdamR: Week of 13 Nov is IETF 13:10:55 (so regrets froM IETF participants on 16 Nov) 13:11:09 AdamR: At risk for 23 Nov 13:11:19 zakim, close item 1 13:11:19 agendum 1, upcoming meeitngs, closed 13:11:20 I see 4 items remaining on the agenda; the next one is 13:11:20 2. payment apps and filtering [from Ian] 13:11:46 Conor: regrets for 2 nov and at risk for 7 Dec 13:11:51 AdamR: At risk for 7 Dec 13:12:12 regrets+ Matt 13:12:15 Issue 63 13:12:15 https://github.com/w3c/webpayments-payment-apps-api/issues/63 13:14:17 q+ to say not so hot about letting apps be mediators 13:14:49 DISCUSSION : Should filter matching happen in payment apps 13:14:51 ack rouslan 13:14:51 rouslan, you wanted to say not so hot about letting apps be mediators 13:14:55 q+ 13:15:05 Rouslan: I went through this thought process for native apps as well. 13:15:22 ...I was making the browser send the full list of payment methods to the payment apps, and the payment apps would return which ones they support. 13:15:36 ...but in the end, I think that model is not clear to me. Then the mediator doesn't do much filtering. 13:15:43 ...this opens up the door to abuse. 13:16:03 ...for native apps I have locked it down... 13:16:08 ...I would like the mediator to do the filtering. 13:16:12 ack ack 13:16:14 ack Ad 13:16:39 adamR: The mediator would still match on payment method. The proposal here is the filtering happens in the app 13:17:18 ok then 13:17:30 q+ 13:17:40 IJ: Yes, my understanding was just the filtering happened in the payment app 13:17:43 ack Adam 13:18:07 adamR: I actually have some of the same concerns that Rouslan has. Namely, that this proposal enables apps to see when a payment request happens, rather than JUST WHEN THE APP IS SELECTED 13:18:17 ...I don't know how you would make it work with native apps 13:18:44 ...one idea is to have functions at registration that defines what they accept. 13:19:19 present+ AdrianHB 13:19:20 ...and when it runs, the payment app doesn't know 13:19:45 ...the function returns a boolean. It can't access data. It can't access the network, etc. 13:19:50 ..it runs with whatever data it had at registration 13:19:52 q? 13:20:16 jnormore: I have similar concerns ... the experience for the user...they might have to wait for apps to talk to servers 13:20:29 ...concerns are mostly performance 13:20:45 q+ to ask Adam about how this would work in Firefox 13:20:57 ack rous 13:20:57 rouslan, you wanted to ask Adam about how this would work in Firefox 13:21:43 rouslan: How would this work in FF? 13:22:00 ...do you envision payment apps that are able to provide cards to be a bootstrapping mechanism for FF? 13:22:48 Rouslan: I had not imagined basic cards being implemented by third party apps 13:22:55 AdamR: Some banks issue one-time use PANs 13:23:09 ...they have to change every time...communication with back end server will be proprietary 13:23:22 ..I want to ensure that banks can do basic card via their third party apps 13:23:30 q? 13:24:01 Late to the discussion here but I am -1 to payment apps doing filtering, at least for v1, but I really like the following quote from Matt: 13:24:06 "For in-browser basic card support, this can also be modeled as the browser-as-payment-app implementing matching rather than the browser-as-mediator." 13:24:29 I have always thought of basic card as the browser acting s both mediator and payment app 13:25:13 IJ: I will update the issue with the notes on privacy, performance from this call 13:25:22 q+ to ask if there is any clarity on the motivations behind this proposal 13:25:26 ack Ad 13:25:26 AdrianHB, you wanted to ask if there is any clarity on the motivations behind this proposal 13:26:26 IJ: Pro of this proposal - flexibility for new payment methods 13:26:42 ...con of this proposal - doesn't scale as well for new payment apps 13:27:21 ...and modeled after how things work today (Apple, Samsung, Android) 13:28:03 AdrianHB: The reason I ask the motivation: is the goal to be able to have a standardized filtering mechanism, or a pass-through function for mediator to ask payment apps if they support a payment request? 13:28:11 MaheshK has joined #apps 13:28:25 ...if latter, I suggest we move away from concept of "filtering" to "canYouPay()"? 13:29:39 IJ: I don't think it's canYouPay()...it's more "let's allow new payment method filters like networks for credit transfers" 13:29:43 q+ 13:29:56 ack Adam 13:30:06 adamR: We are not talking about exposing this to the merchant, right? 13:30:08 Ian: Right. 13:31:07 AdrianHB: That doesn't exist today as cited by MattS 13:31:21 ..apple pay's function is available to merchant 13:32:21 IJ: Anyone interested in pursuing this? 13:32:32 AdamR: If we can't figure out how to make this work from native apps, I consider it a hard blocker. 13:32:48 Rouslan: I think we have something similar with native payment apps 13:33:01 ...one of the important thing for payment apps is to always know where the money is going. 13:33:07 ...the payment app is in charge of the money. 13:33:17 ...the payment app wants to be sure the money is going to the right payee 13:33:24 ...there are several ways to help ensure this: 13:33:31 * Browser can send origin to the payment app, which can log it 13:34:09 However, if the browser is not trusted, payment apps might not want to send money there, so the payment app might want to verify the signature of the browser. 13:34:34 ....so payment apps may only support certain browsers 13:34:50 * Another thing that a payment app might want to double check is that the merchant web site is registered with the payment app. 13:35:09 ...some payment apps might require a relationship with a merchant. (This is true for Apple Pay and Android Pay...merchant id is tied to origin) 13:35:29 ...in order to verify the origin, what I plan to do in Android is for the browser to take requests from the merchant send them to 13:35:45 ...android pay, and let android pay whether to say whether they will accept that payment request or not. 13:35:59 ...it's essentially "can this merchant request payment" or "can android pay complete this payment" 13:36:18 Is this the equivalent of Apple's merchantValidation method? 13:36:19 ..it's sort of like AdamR's lambda function, but (1) it's not sandboxed and (2) it's optional 13:36:39 ..so I think that answers one direction of trust : from payment app to browser and merchant. 13:37:03 ..but there's another direction of trust: when the merchant says "I accept bitcoin"...they may not care which app provides bitcoin, or similarly basic card. 13:37:38 ...so there are cases where the merchant doesn't care which payment app the user uses....but there are cases where the merchant cares (e.g., paypal) 13:38:07 ...suppose the merchant requests Alipay and I try to launch Alipay as a browser but some other app pops up to steal credentials. 13:38:30 ...the way to establish trust between the browser and the payment app is really to do on the Web thanks to origin model 13:38:48 ...if a payment app were registered at bobpay.com, then I know for sure that bobpay.com is responsible for it. 13:39:01 ..but that doesn't work on android...however, you can use signatures 13:39:16 ...we want any payment app to be able to claim support for a payment method, but we want to be able to verify that those payment apps are legit. 13:39:49 ...because we are pushing for payment methods to be URLs, we were thinking of putting a file at those URLs that have signatures of the android apps that the payment method owner expects to be launched 13:40:08 q+ 13:40:45 ...manifests could also declare that the payment method is "open" (anyone can support) 13:41:31 IJ: Have you encountered fine-grain matching ? 13:41:45 Rouslan: Chrome scans apps that are on the phone and determines which are payment apps 13:42:03 ...but before listing the app in the chrome UI, it asks whether the app is "set up for payments" 13:42:54 IJ: What do you pass in? 13:43:04 Rouslan: Method name, origin, method-specific data....that includes merchant id. 13:43:49 ...so I think it's similar...I am trying to determine whether to display the payment app as an option to the user. 13:43:56 q? 13:43:57 ack me 13:44:07 ..the payment app can say "I've never been launched so I'm not ready" 13:45:18 IJ: What is your experience and is web based approach we are talking about in the right direction? 13:45:28 Rouslan: Yes, I think it's moving in the right direction. 13:45:46 ...I wanted some extension points in the manifest file where platform specific payment apps can put data 13:45:51 ...I removed payment options 13:46:09 (I wanted one line per payment app) 13:46:55 IJ: I believe AdamR suggested that option data be available and optional for browser vendors 13:47:18 AdamR: Also, I think that some may really want to display card art as separate options 13:47:30 Rouslan: I can see that argument. It think the reason people want the card art is increased conversion 13:47:54 rouslan: The other topic was location of manifest.... 13:49:04 As a final note on the lambda functions we were discussing before, the restriction I’m asserting we need is that such functions should be “pure functions”. 13:49:05 IJ: Pascal, want to talk about your experience with payment apps? 13:49:39 Pascal: I played role of "small merchant" to try to use the PR API. First observation is that it was easy to use! 13:49:45 ...so that was great 13:50:02 ...as a merchant, I also feel that a few things are missing, and that I would have to send lots of information to a PSP to manage it. 13:50:13 ..the user experience that I am used to integrates everything into one page 13:50:30 ...I might need something like 3D Secure 13:51:21 ...I am wondering whether, for example, it would be possible to write a web-based payment app and have it integrated into the mediator UX 13:51:28 ...same thing with 3D Secure 13:51:31 q+ 13:51:55 q+ 13:52:02 q+ 13:52:07 ...so I think consistent UX is important. 13:52:55 IJ: I heard Zach also say that integration of ux for third party web-based payment apps is an important issue. 13:52:59 ack me 13:53:01 ack adam 13:53:15 adamR: Imagine you have a window or other UI that comes up that says "there are three payment apps" 13:53:25 ...do you imagine that the third party web app renders in the same window? 13:53:47 Pascal: If it's web-based app, yes, it could be integrated into the same graphical environment where the mediator displayed the choices 13:54:11 AdamR: That is, to a limited degree, what I was talking about in the spec about opening a payment window 13:54:32 ...there will probably have to be some iteration on the user experience to make clear that "this stuff here is being rendered by the browser with special permissions" 13:54:40 ...and that compared to "this is just a web page" 13:54:56 ...today there is a strong distinction between browser chrome (and its permission) and the content. ... we don't want to muddle that message 13:55:11 ...will require tweaking but come down to implementation details 13:55:19 ...so I agree that it will be complex but it's on our radar 13:55:22 ack jnormore 13:55:53 jnormore: The piece about 3D secure...the way I envision that, and why I think it's important to recognize that basic card will be implemented by third party payment apps 13:56:12 ...there are things like 3D Secure where you will need payment apps since I don't think browsers will support it. 13:57:20 IJ: Any other comments on your experience? 13:57:31 Pascal: Thanks for letting me know that the UX is on the radar. 13:57:42 agenda? 13:58:01 Topic: Next meeting 13:58:27 2 nov 13:58:31 rrsagent, make minutes 13:58:31 I have made the request to generate http://www.w3.org/2016/10/19-apps-minutes.html Ian 13:58:34 rrsagent, set logs public 13:59:11 alyver has left #apps 15:07:11 jnormore has joined #apps