13:57:24 RRSAgent has joined #wpwg 13:57:24 logging to http://www.w3.org/2016/10/20-wpwg-irc 13:57:26 RRSAgent, make logs public 13:57:26 Zakim has joined #wpwg 13:57:28 Zakim, this will be 13:57:28 I don't understand 'this will be', trackbot 13:57:29 Meeting: Web Payments Working Group Teleconference 13:57:29 Date: 20 October 2016 13:58:05 agenda: https://github.com/w3c/webpayments/wiki/Agenda-20161020 13:58:16 Ian has changed the topic to: 20 Oct agenda -> https://github.com/w3c/webpayments/wiki/Agenda-20161020 13:59:04 present+ 13:59:15 present+ Pascal 13:59:18 present+ Andre 14:00:00 present+ AlexandreB 14:02:05 alyver has joined #wpwg 14:02:19 present+ Mahesh 14:02:25 present+ AdrianHB 14:02:26 present+ AdrianHB 14:02:44 present+ dlongley 14:03:31 Chair: AdrianHB 14:03:33 scribe: Ian 14:03:44 regrets+ NickTR 14:03:53 I have made the request to generate http://www.w3.org/2016/10/20-wpwg-minutes.html Ian 14:05:03 regrets+ zkoch 14:05:27 Roy has joined #wpwg 14:05:40 present+ Roy 14:05:52 agenda -> https://github.com/w3c/webpayments/wiki/Agenda-20161020 14:06:40 present+ adamR 14:06:42 Topic: Short strings as PMIs 14:06:55 q+ 14:07:44 AdrianHB: Matt Saxon had a concern that if you wanted to mint a short-string PMI, you had to go through W3C, otherwise you use a URL which involves real-world resource considerations. 14:08:11 ...this is especially true for organizations that might want to publish open payment methods (like "basic card") 14:08:38 ...use case is orgs that want to publish a payment method without a manifest 14:09:44 jnormore has joined #wpwg 14:10:17 ...we would need to define how a user agent behaves when it encounters a short-string PMI that it does not recognize. 14:10:31 ...a proposal is to treat it as an identifier and to match on it as you would with normal string matching 14:10:43 q? 14:10:59 present+ Jason 14:11:11 we probably already have to specify that if the URL is "http" or "https" there could be a manifest ... otherwise maybe not. 14:11:17 URL doesn't rule out non-http schemes 14:11:26 present +alyver 14:11:33 IJ: I have written down privately what I think needs to change, but relies on seeing updated PMI spec. 14:11:45 ...so I'd like to wait for Zach's updates 14:12:11 ...I think this mostly affects PMI and possibly a minor edit to PR API. 14:12:46 AdrianHB: I think it's a trivial for PR API. 14:12:48 IJ: I agree 14:12:57 topic: Detecting if a payment app is available 14:13:06 Start with proposal from Mahesh: 14:13:06 https://github.com/maheshkk/webpayments/wiki/Detecting-if-payment-app-is-available 14:13:22 also, just because *we* think people won't try and grab short strings ... doesn't mean they won't. (i agree with the approach if our assumption is correct, just not sure about that) ... moving on :) 14:13:55 [Mahesh reviews his proposal] 14:14:11 MaheshK: Recall that Samsung has both a browser and a payment app. 14:14:24 ...we've been talking with Merchants (especially with large numbers of transactions) 14:14:35 ...a very common concern is "they don't have a way to detect if a particular app is available" 14:14:49 q+ to ask what the specific requirements are 14:15:01 ...merchants are very cautious about changes to their checkout 14:15:07 ...they currently show multiple buttons 14:15:34 ..to change to the w3c specification, they would want to know that certain apps are available 14:15:47 ...they want to know whether the app is available before they show a particular button 14:16:21 ...the current proposal has browser filtering payment methods...the default behavior is card checkout 14:16:34 ....some merchants think their current checkout is superior to checkout via the browser 14:16:44 ...e.g., they have card on file 14:16:54 ...it would be a 1-step checkout from their perspective. 14:17:11 ...so the question is how to determine whether a particular payment app is available. 14:17:19 ..the proposal is to add an API 14:17:36 ...note that Apple has this API (canMakePayment()) 14:17:43 ...this is also good for user experience 14:18:04 ...hide buttons when apps are not available 14:18:29 ...I recognize that this has been discussed...the concern has been leaking of information 14:18:53 ..the proposal here is to delegate the decision to the payment app. 14:19:01 ...the merchant asks the browser to ask the payment app. 14:19:04 q+ 14:19:32 ...the payment app could, if it has a relationship with the merchant, could validate the merchant and if so, it could return a positive to response through the browser that it can be used. 14:20:04 ...if for some reason the app is not available, or the app does not trust the merchant, then (@@ scribe missed the nature of the response@@) 14:21:03 q+ 14:21:20 ...note that payment apps are also learning about merchants, which leaks a bit of information...so a refinement is that the merchant can only ask whether a payment app from its own domain is available. 14:21:55 ...note that another approach involves the use of an iframe as a way to determine trusted relationship 14:23:18 ...[Mahesh points out that this sort of thing is already possible; goal here is to make it easier.] 14:23:29 ack me 14:23:29 Ian, you wanted to ask what the specific requirements are 14:23:42 IJ: What is the requirement? 14:23:58 - Is there support for any payment method? 14:24:04 - Is there support for a particular payment method? 14:24:09 - Is there any payment app ready to pay? 14:24:13 - Is my payment app available? 14:24:19 - Is at least one payment app available? 14:24:24 - Is a particular payment app available? 14:26:08 IJ: It feels to me like a new requirement to hide things before the mediator is called. 14:26:42 Mahesh: "At least one of these payment methods" would be valuable to know. 14:27:13 q+ to give merchant perspective 14:27:17 ...that would allow merchants to hide some buttons outside of that list (since at least one of a preferred list would be known) 14:27:30 q? 14:28:27 ack adamR 14:28:31 So I’m hearing “a particular payment method” from what he just said, if I understand correctly. 14:29:33 AdamR: Due to the timing differences between two steps, returning an error in step 4 is a big signal "The app is here but doesn't want you to know." So for 1.1, the proposal does not protect privacy. 14:29:44 ...1.2 is very clever and may not need additional standardization 14:30:14 ....but merchants could work with app providers to be installed at a particular point. 14:30:31 ...I agree that 1.3 is not elegant, and that the flaws are larger than any benefit it might provide 14:30:31 q? 14:30:40 ack dlongley 14:30:53 q+, feedback on adamR concerns 14:31:14 dlongley: I think I would always want the option to pay with my open app, even with basic card. I would not want to be forced to go through the merchant checkout. 14:31:22 q+ 14:31:24 ...my app might be doing things i want it to do 14:32:30 ...another option is to put info in the page (user agent?) but not allow merchant access to it. 14:32:31 ack jnormore 14:32:31 jnormore, you wanted to give merchant perspective 14:33:12 jnormore: From a merchant perspective, it is important to show options before mediator 14:33:32 ...Shopify does this today...and the reason is that right now we cannot provide our own app for basic card. 14:33:53 ...one of the biggest reasons we want to detect whether a payment method/app is available is because of the user experience 14:33:58 ...whether within the mediator or before 14:34:15 ...we don't want to show, for example, Apple Pay as the primary method of payment if the device does not support or the card is not set up 14:34:26 ...the same would go within the mediator's display 14:34:37 ...we would not want the user click on a button only to get a message that says "not available" 14:34:59 ...we would especially not want unsupported apps/methods to show up high in the list 14:35:19 regrets+ manu 14:35:22 IJ: Which of the requirements that I named is important to you? 14:35:43 jnormore: "one of the following payment apps" still enables the possibility of showing buttons that the device does not support. 14:36:06 ...it's ok if the merchant doesn't get the information, but at least the mediator needs the information. 14:37:42 https://github.com/w3c/webpayments/wiki/PaymentApp_Notes#user-experience-descriptions 14:38:30 betehess has joined #wpwg 14:38:53 IJ: it feels to me that we are able to specify mediator behavior (in the dropdown list) but more out of scope to say what happens before the mediator runs. 14:39:39 jnormore: With Mahesh's proposal, even if the merchant doesn't show the buttons in the web page separately (and they are relying on the mediator), then at least they are able to eliminate unsupported things from the mediator's list. 14:39:45 q? 14:39:52 ack Mah 14:39:55 q+ 14:40:25 MaheshK: To AdamR's points - the timing is a legitimate issue for fingerprinting 14:40:56 ....I would still like to make the point that "this is already possible" 14:41:16 ...a payment app that could have something like a cookie or service worker that merchants can use to determine app availability. 14:41:39 q+ 14:42:06 ...for merchants, knowing "at least one payment app is available" is the MOST IMPORTANT information 14:42:17 q- 14:42:48 "the merchant knows its experience is better" is impossible knowledge, IMO. 14:43:05 ack AdamR 14:43:32 AdamR: You are correct that there's nothing that prevents parties from colluding. Those interactions are controlled through CORS and other mechanisms that requires both sides to opt in. 14:43:41 ..i'm concerned that the proposal leaks information that we don't want shared 14:44:02 +1 14:44:06 ...the fact that it "can be done" without us adding anything, in a way that leverages web platform privacy mechanisms, suggests we don't need to add anything 14:44:13 dlongley: whether it is better or not is irrelevant, if the merchant *thinks* theirs is better and they can't use it it will prevent adoption of the spec 14:44:14 q+ 14:44:17 ...I would not want to see the shape of 1.1 go forward 14:44:19 ack dlon 14:44:28 rouslan has joined #wpwg 14:44:55 dlongley: Trying to find out whether a payment app is available....if a merchant runs its own app it can always make available basic card, installed on demand, and used by PR API 14:45:12 zakim, close the queue 14:45:12 ok, Ian, the speaker queue is closed 14:45:15 q? 14:45:25 q+ 14:45:31 zakim, open the queue 14:45:31 ok, Ian, the speaker queue is open 14:45:34 q+ jnormore 14:45:38 zakim, close the queue 14:45:38 ok, Ian, the speaker queue is closed 14:45:46 ack jnormore 14:46:07 jnormore: It's not really about basic card. Merchants should be able to implement their own payment app....but we don't have the payment app spec yet. 14:46:14 ...my point is mostly about non-basic-card payment methods 14:46:28 ...we don't want to show the apple pay button if the user's device does not support apple pay 14:46:45 ...we may want to change the order based on whether the app is available 14:46:56 +1 jnormore 14:47:19 not just privacy, i want app functionality 14:47:27 but privacy is also important. 14:48:06 AdrianHB: I think it's not well-understood what's available in the merchant toolkit today 14:48:37 +1 exactly, merchants can write a payment app to offer a better experience (for that particular concern) 14:48:43 ...merchants can mint PMIs and implement payment apps 14:48:56 without infringing upon other app developers and user's desires to use certain apps. 14:49:48 Topic: Push payments 14:49:56 https://github.com/w3c/browser-payment-api/pull/292/commits/af2d188ee7df21e9a8f35e57a73f828dc96d7923 14:50:01 zakim, open the queue 14:50:01 ok, Ian, the speaker queue is open 14:50:17 Roy: We discussed on Tuesday push payments 14:50:18 https://www.w3.org/2016/10/18-wpwg-push-minutes.html 14:50:41 ...we settled on this scope for a problem statement: 14:50:59 "enable merchant to know authoritative info on transfer or pending transfer (in case of failure)" 14:51:08 ...we came to ground on two pieces: 14:51:23 - mediator generates a unique TX ID that is part of the payment request object 14:51:23 - merchants can specify callback URL for PSPs to send TX ID + payment method identifier + any payment method specific data. 14:51:33 ...so that is the heart of my pull request 14:52:01 ...callback URL from merchant is optional 14:52:26 ..but when provided, enables the authoritative source of information (through server or payment app) to deliver a response to the merchant outside the browser flow. 14:53:14 we may want to coordinate with Web Payment HTTP API on this. 14:53:33 IJ: Additional note: the shape of the status is payment method specific. So merchant gets back: transaction ID, payment method, status data 14:53:43 q+ 14:54:21 AdrianHB: One of the reasons we think that this approach is useful is that it is cross payment method - so that merchants can provide a single service to be called back, and it will work across payment methods 14:54:43 ...transaction ID is used for reconciliation 14:54:49 q+ 14:55:07 q+ to mention why we preferred merchant-provided URL rather 14:55:09 ack dlongley 14:55:29 +1 on HTTP API sync 14:55:32 dlongley: I want to agree largely with what AHB is saying; it may help to coordinate with the web payments HTTP API...we are looking at sending a payment response to an HTTP end point 14:55:51 great idea, I hadn't thought of that, I'll look into it 14:55:53 ... or maybe just HTTP API MEssages spec 14:56:08 ack me 14:56:08 Ian, you wanted to mention why we preferred merchant-provided URL rather 14:57:25 IJ: One bit of rationale for why we favored merchant URL over ability to ping the PSP - current practice where PSPs avoid too much traffic 14:57:47 IJ: please comment on Roy's PR 14:58:31 ...let the full set of editors know about your support (or not) of the proposal. 14:58:46 Topic: Next FTF meeting 14:59:24 AdrianHB: I originally proposed hosting us in Captetown in Feb...but I realize it's a long way to travel. Therefore, I am looking into other work-related events to make it a worthwhile visit. 14:59:40 ...Ian also suggested that we might want to coordinate a meting alongside IETF 98 in Chicago; proposal is 23-24 March 14:59:56 ..We will also meet in TPAC (Nov, near SFO) 15:00:05 ...so that raises one additional question - should we meet in July/Aug? 15:00:33 ACTION: Ian to start a thread on proposals for next meeting 15:00:33 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ijacobs, ijmad). 15:00:53 Topic: Upcoming calls 15:00:57 - We plan to meet weekly through the year except for 24 Nov, 22 Dec, 29 Dec. 15:01:02 - NOTE: 3 November call will be 1 hour earlier for many people (e.g., Europeans) due to end of DST. 15:01:46 Topic: Next meeting 15:01:52 27 Oct 15:01:57 AHB: Regrets 15:02:01 I have made the request to generate http://www.w3.org/2016/10/20-wpwg-minutes.html Ian 15:02:40 alyver has left #wpwg 15:05:03 shepazu has joined #wpwg 17:02:03 Zakim has left #wpwg 17:10:21 betehess has joined #wpwg 17:52:34 wonsuk has joined #wpwg 20:42:00 betehess has joined #wpwg 21:10:20 wonsuk has joined #wpwg 23:30:09 betehess has joined #wpwg 23:35:36 betehess_ has joined #wpwg