IRC log of apps on 2016-10-19

Timestamps are in UTC.

12:40:27 [RRSAgent]
RRSAgent has joined #apps
12:40:27 [RRSAgent]
logging to
12:40:34 [Ian]
Meeting: Payment Apps Task Force
12:40:35 [Ian]
12:40:36 [Ian]
Chair: Ian
12:52:49 [Ian]
12:52:52 [Ian]
agenda+ upcoming meeitngs
12:53:18 [Ian]
agenda+ payment apps and filtering
12:53:25 [Ian]
agenda+ native app implementation experience
12:53:35 [Ian]
agenda+ Pascal's implementation experience
12:53:42 [Ian]
agenda+ registration
13:01:44 [jnormore]
jnormore has joined #apps
13:02:19 [conorhwp]
conorhwp has joined #apps
13:02:21 [Ian]
13:02:27 [Ian]
we are at:
13:02:55 [conorhwp]
Thanks Ian, trying that one now. Previous link was locked.
13:03:05 [Ian]
ah, maybe I have outdated data ;(
13:03:16 [conorhwp]
I am getting " The host has restricted meeting access to those currently in attendance"
13:03:23 [Ian]
let me try something
13:03:27 [conorhwp]
13:03:38 [adamR]
The one from the invite was
13:04:02 [conorhwp]
Also locked
13:04:04 [Ian]
13:04:23 [Ian]
somebody arrived....
13:04:25 [Ian]
13:04:57 [Ian]
it seems people are dialing in
13:05:03 [Ian]
and for some reason WebEx UI is not working
13:05:34 [conorhwp]
I tried dialling in with the number on invite but was locked out also.
13:05:39 [Ian]
present+ Mahesh
13:05:40 [conorhwp]
What number are people using to get in?
13:05:42 [Ian]
present+ Ian
13:05:49 [Ian]
US Toll Number +1-617-324-0000
13:05:51 [Ian]
640 633 363
13:05:58 [Ian]
present+ Pascal
13:06:00 [Ian]
present+ Rouslan
13:06:07 [Ian]
present+ AdamR
13:06:11 [rouslan]
rouslan has joined #apps
13:06:14 [Ian]
regrets+ Matt
13:06:17 [rouslan]
present+ Rouslan
13:06:23 [pascal_bazin]
pascal_bazin has joined #apps
13:06:27 [adamR]
conorhwp: It looks like the web interface is working now
13:06:27 [Ian]
present+ Andre
13:06:34 [jnormore]
present+ jnormore
13:06:53 [conorhwp]
adamR: great thanks
13:08:10 [Ian]
13:09:26 [Ian]
present+ conor
13:09:33 [Ian]
agenda =>
13:09:37 [Ian]
13:09:39 [alyver]
alyver has joined #apps
13:09:43 [Ian]
zakim, take up item 1
13:09:43 [Zakim]
agendum 1. "upcoming meeitngs" taken up [from Ian]
13:09:51 [Ian]
Upcoming meeting schedule:
13:09:51 [Ian]
* 2 Nov, 16 Nov, 23 Nov, 30 Nov, 7 Dec, 14 Dec, 4 Jan 2017
13:10:42 [Ian]
AdamR: Week of 13 Nov is IETF
13:10:55 [Ian]
(so regrets froM IETF participants on 16 Nov)
13:11:09 [Ian]
AdamR: At risk for 23 Nov
13:11:19 [Ian]
zakim, close item 1
13:11:19 [Zakim]
agendum 1, upcoming meeitngs, closed
13:11:20 [Zakim]
I see 4 items remaining on the agenda; the next one is
13:11:20 [Zakim]
2. payment apps and filtering [from Ian]
13:11:46 [Ian]
Conor: regrets for 2 nov and at risk for 7 Dec
13:11:51 [Ian]
AdamR: At risk for 7 Dec
13:12:12 [Ian]
regrets+ Matt
13:12:15 [Ian]
Issue 63
13:12:15 [Ian]
13:14:17 [rouslan]
q+ to say not so hot about letting apps be mediators
13:14:49 [Ian]
DISCUSSION : Should filter matching happen in payment apps
13:14:51 [Ian]
ack rouslan
13:14:51 [Zakim]
rouslan, you wanted to say not so hot about letting apps be mediators
13:14:55 [adamR]
13:15:05 [Ian]
Rouslan: I went through this thought process for native apps as well.
13:15:22 [Ian]
...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 [Ian]
...but in the end, I think that model is not clear to me. Then the mediator doesn't do much filtering.
13:15:43 [Ian]
...this opens up the door to abuse.
13:16:03 [Ian]
...for native apps I have locked it down...
13:16:08 [Ian]
...I would like the mediator to do the filtering.
13:16:12 [Ian]
ack ack
13:16:14 [Ian]
ack Ad
13:16:39 [Ian]
adamR: The mediator would still match on payment method. The proposal here is the filtering happens in the app
13:17:18 [rouslan]
ok then
13:17:30 [adamR]
13:17:40 [Ian]
IJ: Yes, my understanding was just the filtering happened in the payment app
13:17:43 [Ian]
ack Adam
13:18:07 [Ian]
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 [Ian]
...I don't know how you would make it work with native apps
13:18:44 [Ian] idea is to have functions at registration that defines what they accept.
13:19:19 [AdrianHB]
present+ AdrianHB
13:19:20 [Ian]
...and when it runs, the payment app doesn't know
13:19:45 [Ian]
...the function returns a boolean. It can't access data. It can't access the network, etc.
13:19:50 [Ian] runs with whatever data it had at registration
13:19:52 [Ian]
13:20:16 [Ian]
jnormore: I have similar concerns ... the experience for the user...they might have to wait for apps to talk to servers
13:20:29 [Ian]
...concerns are mostly performance
13:20:45 [rouslan]
q+ to ask Adam about how this would work in Firefox
13:20:57 [Ian]
ack rous
13:20:57 [Zakim]
rouslan, you wanted to ask Adam about how this would work in Firefox
13:21:43 [Ian]
rouslan: How would this work in FF?
13:22:00 [Ian] you envision payment apps that are able to provide cards to be a bootstrapping mechanism for FF?
13:22:48 [Ian]
Rouslan: I had not imagined basic cards being implemented by third party apps
13:22:55 [Ian]
AdamR: Some banks issue one-time use PANs
13:23:09 [Ian]
...they have to change every time...communication with back end server will be proprietary
13:23:22 [Ian]
..I want to ensure that banks can do basic card via their third party apps
13:23:30 [Ian]
13:24:01 [AdrianHB]
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 [AdrianHB]
"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 [AdrianHB]
I have always thought of basic card as the browser acting s both mediator and payment app
13:25:13 [Ian]
IJ: I will update the issue with the notes on privacy, performance from this call
13:25:22 [AdrianHB]
q+ to ask if there is any clarity on the motivations behind this proposal
13:25:26 [Ian]
ack Ad
13:25:26 [Zakim]
AdrianHB, you wanted to ask if there is any clarity on the motivations behind this proposal
13:26:26 [Ian]
IJ: Pro of this proposal - flexibility for new payment methods
13:26:42 [Ian]
...con of this proposal - doesn't scale as well for new payment apps
13:27:21 [Ian]
...and modeled after how things work today (Apple, Samsung, Android)
13:28:03 [Ian]
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]
MaheshK has joined #apps
13:28:25 [Ian]
...if latter, I suggest we move away from concept of "filtering" to "canYouPay()"?
13:29:39 [Ian]
IJ: I don't think it's canYouPay()'s more "let's allow new payment method filters like networks for credit transfers"
13:29:43 [adamR]
13:29:56 [Ian]
ack Adam
13:30:06 [Ian]
adamR: We are not talking about exposing this to the merchant, right?
13:30:08 [Ian]
Ian: Right.
13:31:07 [Ian]
AdrianHB: That doesn't exist today as cited by MattS
13:31:21 [Ian] pay's function is available to merchant
13:32:21 [Ian]
IJ: Anyone interested in pursuing this?
13:32:32 [Ian]
AdamR: If we can't figure out how to make this work from native apps, I consider it a hard blocker.
13:32:48 [Ian]
Rouslan: I think we have something similar with native payment apps
13:33:01 [Ian] of the important thing for payment apps is to always know where the money is going.
13:33:07 [Ian]
...the payment app is in charge of the money.
13:33:17 [Ian]
...the payment app wants to be sure the money is going to the right payee
13:33:24 [Ian]
...there are several ways to help ensure this:
13:33:31 [Ian]
* Browser can send origin to the payment app, which can log it
13:34:09 [Ian]
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 [Ian] payment apps may only support certain browsers
13:34:50 [Ian]
* 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 [Ian]
...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 [Ian] 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 [Ian] pay, and let android pay whether to say whether they will accept that payment request or not.
13:35:59 [Ian]'s essentially "can this merchant request payment" or "can android pay complete this payment"
13:36:18 [alyver]
Is this the equivalent of Apple's merchantValidation method?
13:36:19 [Ian]'s sort of like AdamR's lambda function, but (1) it's not sandboxed and (2) it's optional
13:36:39 [Ian] I think that answers one direction of trust : from payment app to browser and merchant.
13:37:03 [Ian]
..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 [Ian] 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 [Ian]
...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 [Ian]
...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 [Ian]
...if a payment app were registered at, then I know for sure that is responsible for it.
13:39:01 [Ian]
..but that doesn't work on android...however, you can use signatures
13:39:16 [Ian]
...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 [Ian]
...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 [Ian]
13:40:45 [Ian]
...manifests could also declare that the payment method is "open" (anyone can support)
13:41:31 [Ian]
IJ: Have you encountered fine-grain matching ?
13:41:45 [Ian]
Rouslan: Chrome scans apps that are on the phone and determines which are payment apps
13:42:03 [Ian]
...but before listing the app in the chrome UI, it asks whether the app is "set up for payments"
13:42:54 [Ian]
IJ: What do you pass in?
13:43:04 [Ian]
Rouslan: Method name, origin, method-specific data....that includes merchant id.
13:43:49 [Ian] 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 [Ian]
13:43:57 [Ian]
ack me
13:44:07 [Ian]
..the payment app can say "I've never been launched so I'm not ready"
13:45:18 [Ian]
IJ: What is your experience and is web based approach we are talking about in the right direction?
13:45:28 [Ian]
Rouslan: Yes, I think it's moving in the right direction.
13:45:46 [Ian]
...I wanted some extension points in the manifest file where platform specific payment apps can put data
13:45:51 [Ian]
...I removed payment options
13:46:09 [Ian]
(I wanted one line per payment app)
13:46:55 [Ian]
IJ: I believe AdamR suggested that option data be available and optional for browser vendors
13:47:18 [Ian]
AdamR: Also, I think that some may really want to display card art as separate options
13:47:30 [Ian]
Rouslan: I can see that argument. It think the reason people want the card art is increased conversion
13:47:54 [Ian]
rouslan: The other topic was location of manifest....
13:49:04 [adamR]
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 [Ian]
IJ: Pascal, want to talk about your experience with payment apps?
13:49:39 [Ian]
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 [Ian] that was great
13:50:02 [Ian] 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 [Ian]
..the user experience that I am used to integrates everything into one page
13:50:30 [Ian]
...I might need something like 3D Secure
13:51:21 [Ian]
...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 [Ian]
...same thing with 3D Secure
13:51:31 [Ian]
13:51:55 [adamR]
13:52:02 [jnormore]
13:52:07 [Ian] I think consistent UX is important.
13:52:55 [Ian]
IJ: I heard Zach also say that integration of ux for third party web-based payment apps is an important issue.
13:52:59 [Ian]
ack me
13:53:01 [Ian]
ack adam
13:53:15 [Ian]
adamR: Imagine you have a window or other UI that comes up that says "there are three payment apps"
13:53:25 [Ian] you imagine that the third party web app renders in the same window?
13:53:47 [Ian]
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 [Ian]
AdamR: That is, to a limited degree, what I was talking about in the spec about opening a payment window
13:54:32 [Ian]
...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 [Ian]
...and that compared to "this is just a web page"
13:54:56 [Ian] 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 [Ian]
...will require tweaking but come down to implementation details
13:55:19 [Ian] I agree that it will be complex but it's on our radar
13:55:22 [Ian]
ack jnormore
13:55:53 [Ian]
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 [Ian]
...there are things like 3D Secure where you will need payment apps since I don't think browsers will support it.
13:57:20 [Ian]
IJ: Any other comments on your experience?
13:57:31 [Ian]
Pascal: Thanks for letting me know that the UX is on the radar.
13:57:42 [Ian]
13:58:01 [Ian]
Topic: Next meeting
13:58:27 [Ian]
2 nov
13:58:31 [Ian]
rrsagent, make minutes
13:58:31 [RRSAgent]
I have made the request to generate Ian
13:58:34 [Ian]
rrsagent, set logs public
13:59:11 [alyver]
alyver has left #apps
15:07:11 [jnormore]
jnormore has joined #apps