See also: IRC log
https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130
IJ: Have people had a chance to review this?
<Zakim> AdrianHB, you wanted to make a few comments re the proposal, didn't have a chance to respond
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.
Payment apps are not "just service workers"; we've spoken about them that way before and I think that has created confusion.
scribe: I prefer that we model
the world as "Payment apps are web apps with special features
are are defining for payments"
... 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
https://lists.w3.org/Archives/Public/public-payments-wg/2017Jan/0105.html
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.
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.
... 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).
... 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.
<Zakim> AdrianHB, you wanted to discuss why you need to identify a payment app and differentiate between giving the user choices in the UI
AdrianHB: I think what Rouslan is
talking about is "options presented to the user" which is
supported by the spec.
... options can be presented to the user (icons, labels)
... if we can talk about multiple options per origin we can
probably address use cases.
IJ: We have two use cases for identification: (1) recommended (2) payment method manifest
AdrianHB: For the second use case
I think origin suffices
... and start_url can be used to point to code
<adamR> For my upcoming comment: https://dl.dropboxusercontent.com/u/53717247/amex.png
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
... the prospect of mashing business and consumer as options
under one app would not have worked
... I think we have use cases for more than one thing per
origin.
<AdrianHB> I think that adamR's use case could be addressed by two payment apps at business.amex.com and personal.amex.com.
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
<adamR> 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
<Zakim> Ian, you wanted to speak to display of apps
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"
<Zakim> AdrianHB, you wanted to talk to subdomains
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.
... I am concerned that we are going down the wrong path by
delineating apps from the same origin
... I think it suffices that apps can register options
... but if you want to offer two things that are more separated,
you should do it at more origins (e.g., using subdomains)
adamR: I think what we need is
the concept of "two things" (whatever they are called, but a
level above options)
... so perhaps we don't call these different things "apps" but
I think it's a valid use case
<Zakim> AdrianHB, you wanted to clarify if this is just a UI req?
AdrianHB: Is this just a UI
requirement?
... if so, that sounds to me like a new proposal, but one that
would not be problematic
... on the other hand, I don't want to go too far down the road
into UI
... 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"
adamR: +1
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).
AdamR: This is not really just UI; it's semantics
AdrianHB: Agreed, change UI to
UX
... the ability is for payment app publishers to organize
options presented to the user
... I think we need to spell out the use cases more clearly
IJ: Has this come up, Rouslan, in native?
rouslan: This hasn't come up. We
do use the web for some identity verificaiton
... the security there comes from the fact that the identifying
URL is owned by the payment app distributed
... we care that the URL is secure (HTTPs)..the separation
among origins does not affect us
pascal_bazin: It seems that
registering a payment app means that the payment app needs to
be defined in the merchant's security domain.
... this would be a limitation..it would mean that merchants
need to implement more
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.
<AdrianHB> +1
<alyver> +1 to use cases
<alyver> I'd be willing to help with use cases
<alyver> but looking for other volunteers :-)
<scribe> ACTION: alyver to write up use cases for additional organizational capabilities for payment apps (within a model of one app per origin0 [recorded in http://www.w3.org/2017/01/31-apps-minutes.html#action01]
IJ: says "wallet" smirkingly
<AdrianHB> Off the top of my head, use cases are:
<AdrianHB> 1. White label payment apps
<AdrianHB> 2. Multiple profiles with a single provider (business vs personal)
<AdrianHB> 3. Multiple instruments held with a single provider
AdamR: Don't smirk; that might be useful
AdamR: We need to be clear on
what requires user consent and what can happen
automatically.
... I think the proposal says that registering for events
requires permission but registering payment method support does
not.
... do others agree (and can we write that down clearly)?
<AdrianHB> +1
<rouslan> +1
+1
<scribe> ACTION: Ian to update the proposal to reflect one app per origin and highlight need for user cases regarding granularity [recorded in http://www.w3.org/2017/01/31-apps-minutes.html#action02]
<scribe> ACTION: Ian to update the proposal to clarify what requires permission and what can happen automatically [recorded in http://www.w3.org/2017/01/31-apps-minutes.html#action03]
<adamR> The comment Ian refers to is here: https://github.com/w3c/webpayments-payment-apps-api/issues/99#issuecomment-276264871
IJ: we have establish where filtering happens, and if in the payment app, how to address concerns about functions
<Zakim> AdrianHB, you wanted to ask some clarifying q's re filtering
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
IJ: I don't think that's it. It
think browser is implementing filtering "as a payment
app'
... I understand:
- Mediator filters on payment methods
- Mediator queries payment apps to see which ones that support those payment methods can handle this payment request
- Mediator displays the resulting subset
- User picks one to continue
IJ: Browser acts as payment app
for basic card and in that capacity does filtering.
... 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.
... then the question is how to ensure privacy in the mediator
query phase.
adamR: Did anyone lay out an algorithm for generic filters?
Ian/AdrianHB: Yes.
<adamR> https://github.com/w3c/webpayments-payment-apps-api/issues/96#issuecomment-275445099
AdamR: I think we should revisit browser doing canHandle, limiting to strings
https://github.com/w3c/webpayments-method-identifiers/issues/5
https://github.com/w3c/webpayments-method-identifiers/issues/5#issuecomment-225665121
IJ: But down side of this
approach is we don't know what the generic filtering language
ACTUALLY requires.
... Suppose we do browser implementation of canHandle. When
does the browser get the data?
If static at registration, ok. But if dynamic at transaction time, then same as asking payment app to answer the question.
AdamR: -1 to browser to asking payment apps for data during transaction
AdrianHB: Agree with AdamR
IJ: Let's continue
discussion
... We need to determine whether static data provided by
payment app satisfies the use case.
Rouslan: I have been thinking
about config option where payment app provides info to the
browser, at least for basic card
... the info that the payment app provides is network and
type
<scribe> ACTION: AdamR to write up a proposal for payment app-provided config information for filtering by browser [recorded in http://www.w3.org/2017/01/31-apps-minutes.html#action04]
<scribe> ACTION: Rouslan to write up a proposal for payment app-provided config information for filtering by browser [recorded in http://www.w3.org/2017/01/31-apps-minutes.html#action05]
<AdrianHB> Filters (at least the names of them) can also be defined in the payment method manifest
7 Feb
