See also: IRC log
and for some reason WebEx UI is not working
<adamR> conorhwp: It looks like the web interface is working now
<conorhwp> adamR: great thanks
https://w3c.github.io/webpayments-payment-apps-api/
Upcoming meeting schedule:
* 2 Nov, 16 Nov, 23 Nov, 30 Nov, 7 Dec, 14 Dec, 4 Jan 2017
AdamR: Week of 13 Nov is IETF
(so regrets froM IETF participants on 16 Nov)
AdamR: At risk for 23 Nov
Conor: regrets for 2 nov and at risk for 7 Dec
AdamR: At risk for 7 Dec
DISCUSSION: Should filter matching happen in payment apps
Issue 63
https://github.com/w3c/webpayments-payment-apps-api/issues/63
<Zakim> rouslan, you wanted to say not so hot about letting apps be mediators
Rouslan: I went through this
thought process for native apps as well.
... 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.
... but in the end, I think that model is not clear to me. Then
the mediator doesn't do much filtering.
... this opens up the door to abuse.
... for native apps I have locked it down...
... I would like the mediator to do the filtering.
adamR: The mediator would still match on payment method. The proposal here is the filtering happens in the app
<rouslan> ok then
IJ: Yes, my understanding was just the filtering happened in the payment app
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
... I don't know how you would make it work with native
apps
... one idea is to have functions at registration that defines
what they accept.
... and when it runs, the payment app doesn't know
... the function returns a boolean. It can't access data. It
can't access the network, etc.
... it runs with whatever data it had at registration
jnormore: I have similar concerns
... the experience for the user...they might have to wait for
apps to talk to servers
... concerns are mostly performance
<Zakim> rouslan, you wanted to ask Adam about how this would work in Firefox
rouslan: How would this work in
FF?
... do you envision payment apps that are able to provide cards
to be a bootstrapping mechanism for FF?
... I had not imagined basic cards being implemented by third
party apps
AdamR: Some banks issue one-time
use PANs
... they have to change every time...communication with back
end server will be proprietary
... I want to ensure that banks can do basic card via their
third party apps
<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:
<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."
<AdrianHB> I have always thought of basic card as the browser acting s both mediator and payment app
IJ: I will update the issue with the notes on privacy, performance from this call
<Zakim> AdrianHB, you wanted to ask if there is any clarity on the motivations behind this proposal
IJ: Pro of this proposal -
flexibility for new payment methods
... con of this proposal - doesn't scale as well for new
payment apps
... and modeled after how things work today (Apple, Samsung,
Android)
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?
... if latter, I suggest we move away from concept of
"filtering" to "canYouPay()"?
IJ: I don't think it's canYouPay()...it's more "let's allow new payment method filters like networks for credit transfers"
adamR: We are not talking about exposing this to the merchant, right?
Ian: Right.
AdrianHB: That doesn't exist
today as cited by MattS
... apple pay's function is available to merchant
IJ: Anyone interested in pursuing this?
AdamR: If we can't figure out how to make this work from native apps, I consider it a hard blocker.
Rouslan: I think we have
something similar with native payment apps
... one of the important thing for payment apps is to always
know where the money is going.
... the payment app is in charge of the money.
... the payment app wants to be sure the money is going to the
right payee
... there are several ways to help ensure this:
* Browser can send origin to the payment app, which can log it
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.
scribe: so payment apps may only support certain browsers
* Another thing that a payment app might want to double check is that the merchant web site is registered with the payment app.
scribe: 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)
... 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
... android pay, and let android pay whether to say whether
they will accept that payment request or not.
... it's essentially "can this merchant request payment" or
"can android pay complete this payment"
<alyver> Is this the equivalent of Apple's merchantValidation method?
scribe: it's sort of like AdamR's
lambda function, but (1) it's not sandboxed and (2) it's
optional
... so I think that answers one direction of trust : from
payment app to browser and merchant.
... 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.
... 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)
... suppose the merchant requests Alipay and I try to launch
Alipay as a browser but some other app pops up to steal
credentials.
... the way to establish trust between the browser and the
payment app is really to do on the Web thanks to origin
model
... if a payment app were registered at bobpay.com, then I know
for sure that bobpay.com is responsible for it.
... but that doesn't work on android...however, you can use
signatures
... 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.
... 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
... manifests could also declare that the payment method is
"open" (anyone can support)
IJ: Have you encountered fine-grain matching ?
Rouslan: Chrome scans apps that
are on the phone and determines which are payment apps
... but before listing the app in the chrome UI, it asks
whether the app is "set up for payments"
IJ: What do you pass in?
Rouslan: Method name, origin,
method-specific data....that includes merchant id.
... so I think it's similar...I am trying to determine whether
to display the payment app as an option to the user.
... the payment app can say "I've never been launched so I'm
not ready"
IJ: What is your experience and is web based approach we are talking about in the right direction?
Rouslan: Yes, I think it's moving
in the right direction.
... I wanted some extension points in the manifest file where
platform specific payment apps can put data
... I removed payment options
(I wanted one line per payment app)
IJ: I believe AdamR suggested that option data be available and optional for browser vendors
AdamR: Also, I think that some may really want to display card art as separate options
Rouslan: I can see that argument.
It think the reason people want the card art is increased
conversion
... The other topic was location of manifest....
<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”.
IJ: Pascal, want to talk about your experience with payment apps?
Pascal: I played role of "small
merchant" to try to use the PR API. First observation is that
it was easy to use!
... so that was great
... 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.
... the user experience that I am used to integrates everything
into one page
... I might need something like 3D Secure
... 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
... same thing with 3D Secure
... so I think consistent UX is important.
IJ: I heard Zach also say that integration of ux for third party web-based payment apps is an important issue.
adamR: Imagine you have a window
or other UI that comes up that says "there are three payment
apps"
... do you imagine that the third party web app renders in the
same window?
Pascal: If it's web-based app, yes, it could be integrated into the same graphical environment where the mediator displayed the choices
AdamR: That is, to a limited
degree, what I was talking about in the spec about opening a
payment window
... 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"
... and that compared to "this is just a web page"
... today there is a strong distinction between browser chrome
(and its permission) and the content. ... we don't want to
muddle that message
... will require tweaking but come down to implementation
details
... so I agree that it will be complex but it's on our
radar
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
... there are things like 3D Secure where you will need payment
apps since I don't think browsers will support it.
IJ: Any other comments on your experience?
Pascal: Thanks for letting me know that the UX is on the radar.
2 nov