IRC log of apps on 2017-01-31

Timestamps are in UTC.

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