07:32:06 RRSAgent has joined #wpwg 07:32:06 logging to http://www.w3.org/2016/07/07-wpwg-irc 07:32:10 Zakim has joined #wpwg 07:32:40 rrsagent, meeting goes beyond midnight 07:32:40 I'm logging. I don't understand 'meeting goes beyond midnight', manu. Try /msg RRSAgent help 07:32:59 rrsagent, make minutes 07:32:59 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html manu 07:33:25 rrsagent, make logs member 07:33:33 CyrilV has joined #wpwg 07:33:58 Meeting: July 2016 Web Payments Working Group Face-to-Face Meeting 07:34:02 rrsagent, make minutes 07:34:02 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html manu 07:34:36 Present+ Cyril Vignet 07:34:42 Present+ ShaneM 07:34:48 s/Cyril Vignet/Cyril_Vignet/ 07:34:51 rrsagent, make minutes 07:34:51 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html manu 07:41:23 rrsagent, pointer? 07:41:23 See http://www.w3.org/2016/07/07-wpwg-irc#T07-41-23 07:42:09 rrsagent, this meeting spans midnight 07:45:49 nicktr has joined #wpwg 07:45:54 present+ nicktr 07:46:45 brian_s has joined #WPWG 07:47:02 manu-backup has joined #wpwg 07:47:16 MattS has joined #wpwg 07:47:38 Agenda: https://github.com/w3c/webpayments/wiki/Web-Payments-Working-Group-FTF-Meeting-%28July-2016%29 07:47:57 Agenda: https://github.com/w3c/webpayments/wiki/Web-Payments-Working-Group-FTF-Meeting-%28July-2016%29 07:48:19 zkoch has joined #wpwg 07:48:49 lbolstad has joined #WPWG 07:49:19 sebsg has joined #wpwg 07:49:20 present+ zkoch 07:49:31 rouslan has joined #wpwg 07:49:57 pirouz has joined #WPWG 07:50:42 present+ AdrianHB 07:51:23 rouslan has joined #wpwg 07:51:43 present+ AdrianHB, brianSullivan, Ian, LarsErikBolstad, MattSaxon, Rouslan 07:52:10 Nicolas_A_ has joined #wpwg 07:52:38 present+ Nicolas_A_ 07:52:59 present+ lbolstad 07:53:15 jyr has joined #wpwg 07:53:59 present+ joshua 07:54:03 nick has joined #wpwg 07:55:28 Topic: Introducitons 07:55:32 pirouz has joined #WPWG 07:55:36 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 07:55:45 Nick: Welcome! 07:55:56 present+ 07:56:12 scribe: manu 07:56:22 present+ MattS 07:56:29 Topic: Introductions and Meeting Administrivia 07:56:31 Roy has joined #wpwg 07:56:40 alyver has joined #wpwg 07:56:42 conorhackett_wp_ has joined #wpwg 07:56:52 nicktr: Welcome to all, we have some administrative stuff to go over first. 07:57:09 fdold has joined #wpwg 07:57:16 nicktr: IRC channel is #wpwg, WiFi is on the board at the front of the room. 07:57:19 kriske has joined #wpwg 07:57:25 present+ kriske 07:57:37 agenda: https://github.com/w3c/webpayments/wiki/Web-Payments-Working-Group-FTF-Meeting-(July-2016) 07:57:55 ben has joined #wpwg 07:58:03 nicktr goes over other administrative items - talking, queue, github 07:58:19 Andymills80 has joined #wpwg 07:58:51 VincentK has joined #wpwg 07:58:55 Ian: Thanks to all for coming to the meeting, thanks to Brian Sullivan and Visa for providing the meeting space. 07:59:05 Lauren_Jones has joined #wpwg 07:59:16 Ian: We take minutes in real time, they are public. Let's do roll call and we want to figure out dinner items. 07:59:24 present+ 07:59:49 maheshkk has joined #wpwg 07:59:53 charlie_craven has joined #wpwg 08:00:03 BrianS: Since some of our competitors are here - competition lawyers have asked me to read a statement. We need to make sure we don't share competitive information today. I'll type this out into IRC. Please don't share things that are commercially sensitive to your organization. 08:00:29 BrianS: Please object if you hear anything that sounds like sharing of competitive or commercially sensitive information. 08:00:50 Here is the statement:“Some of the attendees today are competitors of each other so we all need to ensure that we do not share competitively sensitive information today as exchange of competitively sensitive information between competitors is a major competition law concern. I would therefore be grateful if you could bear this in mind and ensure that you do not disclose at this meeting anything of a commercially sensitive nature regarding your company. [CUT] 08:00:58 Ian: If you wish to keep something off of the public record, please say "don't minute this" 08:01:14 present+ Brian_Sullivan 08:01:30 Huw_bailey 08:01:40 present+ Charlie-Craven 08:01:44 present+ BenSmith 08:01:49 the rest of the statement...This includes, for example pricing, investment strategy, product strategy, marketing plans and forecasts. If you have any concerns that we may be discussing competitively sensitive information, please object to the discussion so that your objection can be recorded in the minutes of the meeting.” 08:01:50 present+ Andrea 08:01:53 Present+ Dapeng 08:01:59 present+ jiajia 08:02:04 present+ SimonScorer 08:02:13 present+ KrisKetels 08:02:17 present+ VincentKuntz 08:02:22 present+ Shane 08:02:25 present+ Manu 08:02:29 present+ MattS 08:02:34 present+ Faraz 08:02:39 present+ CyrilVignet 08:02:44 present+ NichlasAncot 08:02:48 present+ Jean-Yves 08:02:54 present+ zach 08:02:56 CyV has joined #wpwg 08:02:57 present+ Sebastien 08:03:01 present+ LarsErik 08:03:03 present+ Dongwoo 08:03:09 present+ Rouslan 08:03:09 present+ LaurentCastillo 08:03:12 present+ LaurentJones 08:03:15 present+ Florian 08:03:17 present+ Andre 08:03:23 present+ NickS 08:03:25 present+ Roy 08:03:28 present+ Ade 08:03:37 present+ Connor 08:03:42 present+ NickTR 08:03:45 present+ AdamR 08:03:51 present+ Farad 08:03:53 present+ AHB 08:04:04 AjayRambocus has joined #wpwg 08:04:05 present+ Ajay 08:04:06 nicktr: On screen is the agenda, we're starting by talking about payment apps spec. 08:04:20 q+ 08:04:34 nicktr: We set priorities today/tomorrow to discuss payment request api and payment method identifiers, payment apps, payment method specs, some about strategy, http api 08:05:04 nicktr: To set expectations, there will be a lot of discussion - it's inevitable that many questions won't be answered. I will be looking for volunteers to take questions forward. 08:05:24 nicktr: This can't just rest on the shoulders of 2-3 people or just the editors. 08:06:24 Ian: We are planning a meal tonight - by noon we'd like preliminary menu - at break, we'll have you look at Smiths Bar and Grill menu - dinner at 7pm 08:06:52 Ian: There have been some requests for significant others, we may have some space. 08:07:15 brian_s: We have security outside to guide you to restrooms, etc. 08:07:22 topic: Payment APps 08:07:34 Topic: Payment Apps 08:07:34 Payment Request API 08:07:34 https://www.w3.org/TR/payment-request/ 08:08:12 q? 08:08:24 ack Ian 08:08:25 q- 08:08:26 AdrianHB: A quick overview of the Payment Apps spec - it's a proposal, not an adopted spec, we want to come to consensus on what's in this spec. Pick some editors w/ a view to publish it as an editors draft and send it to CR. 08:09:16 AdrianHB: This proposal is a partner spec to payment request API - scoped very specifically for browsers - broader scope of the group is beyond that - payment request is user agent API - proposed to be a partner API for that. What Payment Request does, it accepts a payment request from a website and sends a payment response. 08:10:00 AdrianHB: We are doing message brokering here, not payment processing. How do you pass a message from a website to a payment processor - anyone that's new to the work, we're trying to specify a way to move payment request from website to payment processor and get payment response back. 08:10:48 Laurent has joined #wpwg 08:10:50 q+ 08:10:52 AdrianHB: PaymentRequest takes a payment request - who handles the payment request - just an idea that the request is formed, algorithms in the browser to implement. What the PaymentApp does is it provides a way to get payment apps that are not the browser into the ecosystem. 08:11:19 AdrianHB: Payment Apps are what, from a card industry perspective, call a digital wallet. We threw that out early on as there were too many options. 08:11:41 AdrianHB: We don't make any other determinations about what it can do - remote services, biometric security, we don't specify that - it's just an interface. 08:12:14 AdrianHB: How do browsers become aware of payment apps, how do they update their capabilities... and so on. we need to figure these things out over the next few days. 08:12:25 conorh has joined #wpwg 08:12:34 AdrianHB: How does a payment app make browser aware that it's been uninstalled? 08:13:30 AdrianHB: The browser says it accepts certain ways of paying, app becomes an option - provides user with some kind of selection - we provide tools for payment app publishers to do that. 08:13:55 AdrianHB explains how payment flow works for what this WG is proposing. 08:13:55 Payment App spec -> https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html 08:15:04 nicktr: There is a diagram in an architecture summary proposal that's helpful, we may be taking up that work tomorrow. 08:15:15 q? 08:15:18 AdrianHB: This is a simple Javascript API that we're defining. 08:15:58 AdrianHB: HTTP interface provides how information is passed from browser to payment app - payment options is a new concept, exposing payment instrument selection up front. 08:16:48 q? 08:16:55 AdrianHB: Early on, we thought of payment apps as just an app with multiple cards loaded into it. It's difficult then to give user option up front. How does payment app expose which cards are there. PaymentApp has a registration feature, is option usable for a payment request. 08:17:51 * the link to the diagram ? 08:18:09 Depeng: With respect to registration, 3rd party service provider - user doesn't need to register payment service/apps - customer can just click purchase and merchant redirects to merchant. From user experience perspective, I suggest the WG should focus on what the gain/benefit is for this sort of user experience. 08:18:16 https://w3c.github.io/webpayments/proposals/wparch/ (Section 4) 08:18:29 q+ 08:18:32 ack Max 08:19:01 q+ 08:19:08 AdrianHB: There is a benefit - when website requests payments, there is no UI there yet - what a website can do is say "I'd like you to pay, but using payment apps that I recommend." 08:19:19 AdrianHB: That's roughly the same user experience 08:19:30 q? 08:19:35 ack Ian 08:20:02 Ian: I'd like to step back a bit - just a reminder, the high level goal of the payment app work is to create an open ecosystem for payment apps. 08:20:53 Ian: Browser can store credentials and make it easier for user to save typing - a lot more is possible in the 3rd party payment app case - strong authentication, integrate payment with mobile banking, etc. Payment App spec overlays the underlying payment request API to add payment apps to the ecosystem. 08:21:16 Ian: yesterday, in discussion with Alibaba, they asked why this new approach is going to benefit the customer. 08:22:19 Ian: The benefits will differ based on payment method or payment app. For example, with credit cards it reduces typing and that's good. But for Alipay, you don't have to type information in anyway. Our messaging around payment apps may need to be more nuanced. 08:22:57 Ian: Second observation, I think we agreed that a world in which user can configure how payment apps can be used is a better experience than hunting around on merchant sites for how to pay. 08:23:35 Ian: Third, users can specify via the underlying API where they can use certain payment apps - user choice. 08:24:17 Ian: For many payment methods, there may only be one payment app - like PayPal or Alipay - when there is only one app, there may not be an intermediate payment selection page. 08:24:39 Ian: For these cases, we may want to have a quick/automatic selection mechanism. 08:24:44 q? 08:25:00 Ian: This is independent from other topics wrt. how payment apps are quickly selected. 08:25:26 Depeng: I suggest the Working Group focuses on how to improve that (the Alipay) case. 08:25:31 Max: We can help add "how this improves the user experience" info to the spec 08:25:39 https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html#paymentapp.register 08:25:49 Depeng: Payment registration requires a URL, but that isn't useful for native apps. 08:26:57 AdrianHB: I don't think we are g oing to specify anything that is too explicit to how native apps work - that's going to be platform specific - android vs iOS vs desktop - there is an open question on how much should we say. Platform vendors should say something. 08:27:17 +1 to best practices documentation on how to create apps on different platforms 08:27:21 Depeng: For native apps, maybe the Working Group can produce a provisional document for platform specific implementations. 08:28:02 AdrianHB: Adam produced a document that he shared several days ago - not quite normative, but this is how we think this should work. We shouldn't use the WG time on this - we're not going to produce something normative on that. 08:28:20 Max: We'd like to contribute to such good practice 08:28:24 Depeng: Alipay would like to collaborate on this. 08:29:01 q- 08:29:27 nicktr: We can have this discussion via spec text and provide informative text like you describe via specs. 08:29:28 NickTR: +1 to create resources around good practices 08:29:47 AdrianHB: How do you describe ordering of apps? 08:29:54 AdrianHB: How do you bootstrap the ecosystem? 08:30:03 AdrianHB: Do we need to say anything about defaults? 08:30:11 q+ 08:31:06 Mahesh: We (Samsung Pay) could collaborate on those practice as well. 08:31:23 Ian: Let's walk through the spec and discuss specific issues after that. 08:32:34 Ian: A quick overview around the structure of the specification - much of the structure has been explained, written wrt. lifecycle of payment apps. How they get registered, how browser knows about them, how they are unregistered, etc. 08:32:56 Ian: In section 4, we set out the model on how this works. 08:33:03 q+ 08:33:03 present+ DanAppelquist 08:33:12 Faraz has joined #wpwg 08:33:14 Mahesh， OK, thanks 08:34:24 Ian: The specification attempts to state declaratively on given state of interaction with user - we may prune out definitions in time that we don't need. This was inspired by observation that when I get a payment app, but haven't provided credentials to it, should that app match - when I go to pay, I have not yet given it my credit card information. Should it prompt me to enter my information? 08:34:36 Ian: A matching application should have /these/ properties. 08:34:39 ack Ian 08:35:00 q? 08:35:15 adamR has joined #wpwg 08:36:02 Ian: I think definitions section, we can refine those, don't want to spend much time on those - first section that's meaty of the specification is section 6 - registration of payment apps - what is the mechanism by which we can tell a browser that I am a payment app - world of web-based payment apps, world of native payment apps - can we do that interoperably between platforms. What information do you provide before user goes away. How do you, in the web platform, 08:36:02 register something w/ the browser? 08:36:17 q+ to note on layering issues. 08:36:23 ack adrianba 08:36:53 jiajia has joined #wpwg 08:37:18 dka has joined #wpwg 08:37:57 adrianba: General question about approach here - the way that we've structured the payment request API enables this idea of extensibility via payment apps but doesn't say anything specific about payment apps. As we start to consider enabling payment apps, there are a bunch of decisions we have to make around model for payment apps. Some of those might be more specifics around payment app matching, bunch of different ways around what an app can do, what can an app 08:37:57 support, etc. 08:38:46 AB: Saying (but not proposing) "maybe can only use payment apps that support payment methods that come from the same origin of the payment app" 08:38:52 adrianba: One way we could do this (not suggesting it's what we should do), only support payment apps from same origin - that would allow Alipay to have Alipay app on their origin, but wouldn't allow anyone else to provide an Alipay app - there are a bunch of decisions that we have to make on this stuff. 08:38:52 q+ to respond to adrianba 08:38:53 q+ to say that we should not restrict methods to app origin 08:39:51 adamR I agree that it was a proposal 08:39:58 q? 08:40:12 rouslan_ has joined #wpwg 08:40:22 adrianba: This document has some description of this space in the model section and then goes into specifics, it's hard for me to connect general idea on abstract model, and specific decisions. I'm not sure how we review this in detail, we are jumping into some of the deeper parts. I'd like to understand the implicit decisions taken in how the web-based model is presented. What are some of those decisions? 08:41:01 Yeah, I don’t think Adrian is proposing that we limit apps to a singular origin 08:41:10 Ian: You are correct in your observation - there were some concrete decisions made on emerging model, not sure if you're asking if we're all in agreement on current model. 08:41:18 ack manu 08:41:18 manu, you wanted to note on layering issues. 08:41:18 adrianba: I'm not sure what the best way is to address. 08:41:20 I think he’s just saying it’s unclear what assumptions were made to reach the current app spec 08:41:27 manu: I looked at the spec from the viewpoint of the HTTP API 08:41:46 ...it felt like the HTTP API could use pieces of this...except that this spec layered is on top of the browser API spec 08:42:01 rouslan__ has joined #wpwg 08:42:05 ...so it feels like the layering is off 08:42:15 q? 08:42:30 ...E.g., would be easier to create a separate registration spec 08:42:46 rouslan_ has left #wpwg 08:42:47 ...I think that HTTP spec should reuse the registration section but today it can't easily do so 08:42:59 ..is the plan that it be reusable ? 08:43:07 ack AdrianHB 08:43:07 AdrianHB, you wanted to respond to adrianba 08:43:22 rouslan_ has joined #wpwg 08:44:23 q? 08:45:18 AdrianHB: The proposal as it stands, it started out very specific. This started out as web-based interface - explicitly not payment apps - inspired by first architecture proposal - request API, dependent on payment method api spec - different payment app specs - web-based payment app specs. This is a very narrowly scoped proposal, potentially one of many. This is the way the WG thinks about payment apps. Payment apps to be written that are accessible via URLs - th 08:45:19 at was the design decision behind it. Reuse via HTTP API was not a goal. 08:45:48 AdrianHB: I think it would be a failure if HTTP API has a normative requirement on this spec - this is very much a browser API spec. 08:46:16 q+ to note that a good chunk of the text in the HTTP API payment app would copy the text in this spec. 08:46:18 ack S 08:46:18 ShaneM, you wanted to say that we should not restrict methods to app origin 08:46:23 ack ShaneM 08:46:28 q+ 08:46:54 nicktr: So we're going to get two families of specifications - one in browser-mediated specifications, one in non-browser-mediated specifications. 08:47:41 AdrianHB: I think it would be nice if we have common specs, but today we're doing specific specs - this is a browser API specification. 08:48:18 ShaneM: You mentioned as a potential concept, we could scope app to a single domain - I think that's overly restrictive and it disenfranchises people not in this room. 08:48:34 adrianba: I wasn't proposing that, I suggested that to be deliberately provocative. 08:48:50 Manu: Having read through a lot of the spec text, a large part would be duplicated in the HTTP API 08:48:53 q? 08:48:55 ack manu 08:48:55 manu, you wanted to note that a good chunk of the text in the HTTP API payment app would copy the text in this spec. 08:49:22 manu: My concern is that that we are getting a set of browser specs, and a different set for non-interactive payments 08:49:30 ...I am starting to see that we are duplicating 08:50:31 q+ 08:50:41 AdrianHB: Yes, aware that that is happening - in programming terms, write what works now, then abstract later. We are building HTTP and Browser to specific requirements, they may overlap - in future - we may want to pull out duplicate bits into something like Core Messages, but I think it'll be difficult if we try to push a unified stack. 08:50:42 jiajia has joined #wpwg 08:50:43 ack zkoch 08:51:34 zkoch: Looking at payment app spec, I'm confused about fundamental assumption - it would be nice to have a rationale document to explain the frame of reference for spec. 08:52:14 zkoch: There are assumptions around payment apps and payment methods - any payment app can register with any payment method - a payment method could be as general as a visa card, but another payment method are these closed loop payment methods - like paypal. 08:52:35 zkoch: No one except for paypal can return back a paypal token - a random payment app can associate itself w/ a different payment method 08:52:45 q+ to note that Coinbase just added PayPal support to their wallet. 08:53:06 zkoch: We want players like LastPass to be able to play in the ecosystem. 08:53:35 q+ to ask how these closed loops system would change what we discuss in the spec 08:53:42 zkoch: We should standardize the open ecosystems and have specs for those. Don't think we should do that for closed ecosystems. 08:53:50 q? 08:54:00 q+ 08:54:09 q+ 08:54:15 zkoch: I think we should consider that - notion of recommended payment apps - who provides that list. 08:54:58 Ian: When you say - we say "nngh" (x mark with arms) - browser would complain, is that what the browser should do? origins don't align - registrations might be the right place to do that. 08:55:11 +1 to Adrian 08:55:19 q- 08:56:17 zkoch: If person says they support PayPal payment method, don't want to set a user up for failure - when merchant only supports paypal - but people go through experience and find out that PayPal is not a viable payment option. We may have a world where proprietary apps are allowed that have partners. 08:56:24 zkoch: I can see partnerships as use cases (e.g., some company licenses another company to implement the proprietary system) 08:56:29 zkoch: For right now, we could say closed loop systems have to match origin. 08:56:42 q? 08:57:11 I can certainly imagine a developer *accidentally* claiming to support a payment app they don’t 08:57:21 q- 08:57:38 q- 08:57:54 AdrianHB: I think it would be useful for payment app to say why it would expose payment methods that it doesn't. We don't want to overstep here, if we start differentiating between closed loop and open loop payment systems - we'd have to have a registry, there are dragons there. 08:58:13 q+ 08:58:40 zkoch: We have people here from the payments industry - here is a standard payment system, standard enough that people use them - SEPA, ACH, is that feasible/not feasible. 08:59:45 q+ 08:59:57 q+ 09:00:03 nicktr: We are heading into deep/uncomfortable water - what is open loop vs. closed loop - even that's not clear - regulator in Europe, Visa is treated differently than Amex - equally, there are aggregators that fit into payment application architecture - especially if you extend the architecture to include payment apps. Who can / can't do that is problematic. 09:00:36 q- 09:00:38 nicktr: I also note that this is very browser specific - I think it would be useful to get a sense from the group to grow it to include all iteraction modes or if we want to have two specific work streams. 09:00:40 ack nicktr 09:00:58 ack Laurent 09:01:02 amex has a poin 09:01:08 point 09:01:33 I agree. Restrictions that potentially restricts players from the ecosystem are a bad idea. 09:01:35 q+ to ask Amex for their input 09:01:35 Laurent: Since it's easier to implement this between payer/payee directly rather than imposing at tech layer. For example, PayPal can restrict at their side, no need to do it at the browser side. 09:02:07 I also think recommended methods also suffers from similar issues. Anything that restricts or props any player is usually a bad idea 09:02:15 zkoch: That doesn't solve the core problem - if Alipay provided a payment app, but Tencent says they support it where they don't. 09:02:34 AdrianHB: How do you stop payment apps from saying they'll support payment of something when they don't. 09:02:37 ack Ian 09:03:10 Ian: Let's take the approach for the moment that the standard doesn't support anything. 09:04:29 Ian: Recommended payment apps - Zach and I have discussed this - there are moments when I might find myself in a bad user experience - I don't have an app, retailer wants me to use their app, browser is aware of payment app for particular payment method - configure it, install it - based on previous face-to-face - recommended payment app - you might want to install /this/. That could figure into user experience. 09:05:01 Ian: When I have something installed, it's not our point to say how that is displayed. 09:05:24 Ian: User experience to deal with them - Zach, do you have suggestions on how this should be done? 09:05:34 ack nick 09:06:28 nickS: I have a few questions - same origin being dangerous? Seems odd to me that iframes in HTML have same origin but we're saying payments might not. I agree with Zach, naieve to say payment extensions will all be good, some will suck. 09:07:07 nickS: When there wasn't a curated way to install plugins, people did horrible things. Some of this might be accidental - help people make the right decisions. 09:07:35 q? 09:07:44 AdrianHB: Yes, we need to figure out a way to not send users down ratholes. With respect to same origin - we are not suggesting to throw that out the window. Payment Apps are not origin bound. 09:08:20 AdrianHB: Amex payment method is not at Amex. 09:08:25 nickS: Yes, but Walmart is. 09:08:50 Ian: I'm hearing that people want a proper user experience - what does the standard need to support so that the experience can be optimized for the user. 09:09:01 nickS: Yes, but same origin is also a security issue. 09:09:09 q+ 09:09:17 Ian: Yes, but the 'same origin' that was mentioned was not the 'same origin security' issue. 09:10:02 nicks: It's a security issue as well - if an airline says they have miles, another airline could say they support it to find out if a user has another airline's miles. 09:11:02 Charlie: We can't talk about anything wrt. restricting competition. 09:11:15 q? 09:11:23 ack nicktr 09:11:23 nicktr, you wanted to ask Amex for their input 09:11:33 [IJ thinks that that's precisely why the standard needs to not pick a particular regulatory regime] 09:12:03 nicks: There are some places where these restrictions are mandated - things that prefer companies over users - we need to make sure we have something that helps us meet regulatory obligations around the world. 09:12:19 Charlie: Yes, but we should be very careful here - we can't have discussions that restrict competition. 09:12:35 q+ to recharaterize 09:12:54 AdrianHB: I'm hearing that we need to protect against malicious payment apps. 09:13:32 q+ to point out that per-spec prose doesn’t scale 09:13:51 AdrianHB: At a technical level, do we want there to be a way that let's payment method providers restrict apps? Not known supporters of a particular payment method. That's what I'm hearing as a requirement. 09:13:56 q? 09:14:01 q+ to note "display" language in spec. 09:14:05 ack Max 09:14:33 Depeng: With respect to fake payment methods, we don't want users to be misled. 09:14:48 AdrianHB: There are certainly concerns wrt. phishing, etc. 09:15:02 ack Ian 09:15:02 Ian, you wanted to recharaterize 09:15:10 AdrianHB: We may have another session on this. 09:15:34 Ian: There are two framings - one from payment method provider perspective, another from user perspective. 09:15:51 q? 09:16:03 AdrianHB: I think this will be dealt with in payment method specs. 09:16:13 Ian: Yes, but let's not make that decision now. 09:16:53 IJ: I think that we may need to augment the payment API re: registration data 09:17:00 q? 09:17:09 nicktr: In framing discussion around restriction - it makes it difficult for schemes to participate in the discussion - regulators in europe in various geographies - discussion around restriction itself is problematic. Anything that talks about ability to restrict based on commercial respects is problematic. 09:17:28 adamR: Something that puts restrictions on a per-payment method spec is not going to scale. 09:17:38 ack adamR 09:17:38 adamR, you wanted to point out that per-spec prose doesn’t scale 09:17:44 ack manu 09:17:44 manu, you wanted to note "display" language in spec. 09:17:53 manu: There's a lot of language in the algorithms about display requirements 09:18:02 ...I don't have a strong opinion on that other than it feels strange 09:18:06 q+ 09:18:28 ack Ian 09:19:44 Ian: One of the things I agree with, we don't and can't give display guidance - there are parameters that we can speak to - we do have precendent in Web Accessibility Guidelines - however you do this, you need to make sure that you do X. Some of the requirements that are in here are intended to be non-exclusionary - if it's matching, a browser can't discriminate - it's not a visual/oral display - it's a non-discriminatory requirement. 09:19:52 friendly comment - we should say "present", not "display" 09:20:10 ian: These things may be obvious/unnecessary to say - we are trying to provide intent on what should be displayed. 09:20:22 q+ 09:20:25 manu: +1 on "present" 09:20:49 ack adrianba 09:20:49 Ian: We try to frame things in ways that show intent. 09:21:45 adrianba: The spec currently has a statement where it says "The user agent must display all matching payment options" - Manu mentioned the poor track record of W3C specs having this in the past, often because they didn't include the why. 09:22:11 adrianba: There are other ways to ensure how we do that - we lose the why, and because of that, they lose the reasoning and don't do it. 09:22:26 Ian: When we've only provided "why" only, we haven't gotten interoperability either. 09:22:30 q? 09:23:01 Ian: The closer we can get to what people should do w/o going over that line of being overly prescriptive - that's what we're trying to do. 09:23:34 q+ 09:23:36 q+ 09:24:02 q+ 09:24:23 AdrianHB: We need to decide if we're going to be specific about this and what level of detail that will have. This is about constituency requirements. 09:24:37 q+ 09:24:56 ack nick 09:25:02 zakim, close queue 09:25:02 ok, manu, the speaker queue is closed 09:25:05 queue=adamR,Faraz,Ian 09:25:09 q+ 09:25:18 q- 09:25:40 nicks: I agree with both Adrians - I can see recommended apps being of great value to both parties, in less ideal world, I think we could disadvantage. We need to find the right balance. 09:26:50 q? 09:26:51 AdrianHB: We're adding a fairly green feature set to the Web - the more features that we add, the more likely we are to add things that have side effects that we didn't think about. Would like to focus on simple over complex solutions. Let's not try to introduce too many new features to counteract features that may happen... 09:27:03 rouslan_ has joined #wpwg 09:27:06 Nick: Present entire ecosystem, e.g., may lose placement but also will get more conversions 09:27:08 nicks: We need to look at the entire ecosystem in order to convince merchants. 09:27:43 Faraz: The word "ordering" is also problematic - objection to talk about that. 09:28:11 Ian: I have written some of these items down - would be nice to think about whether spec lends itself to that world easily or less easily. 09:28:25 Ian: Recommended apps - flesh it out w/ "the why" - how can it be used and misused. 09:29:02 Ian: We talked about open vs. closed systems - more rationale for why we are doing certain things - ordering is something that we may or may not want. 09:29:12 Ian: Refactorization may be the right thing to do in time. 09:29:24 Ian: Connor sent a few things to the list as well. 09:29:36 nicktr: Break for coffee, we'll be back in a bit. 09:29:42 rrsagent, draft minutes 09:29:42 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html manu 09:30:47 s/Payment APps/Payment Apps/ 09:30:51 rrsagent, draft minutes 09:30:51 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html manu 09:31:25 s/Topic: Introducitons// 09:31:28 rrsagent, draft minutes 09:31:28 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html manu 09:58:54 nick has joined #wpwg 10:00:15 nick has joined #wpwg 10:07:14 MaheshK has joined #wpwg 10:17:22 Max has joined #wpwg 10:17:24 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 10:18:13 dka has joined #wpwg 10:18:26 alyver has joined #wpwg 10:18:30 nick has joined #wpwg 10:20:13 rouslan_ has joined #wpwg 10:20:13 adamR has joined #wpwg 10:20:19 Lauren_Jones has joined #wpwg 10:20:36 zkoch has joined #wpwg 10:20:42 scribe: Ian 10:20:57 Topic: Implementation Experience 10:21:07 lbolstad has joined #wpwg 10:21:13 present+ 10:21:34 adrianhb: We'd like in this session to hear back from implementers about their experiences and implications for the spec 10:21:44 fdold has joined #wpwg 10:21:52 Laurent has joined #wpwg 10:22:31 adrianhb: I think we are getting close to pushing payment request API to CR; I would like to get feedback from browser vendors in particular, but Worldpay also have a demo 10:22:33 Faraz_Babar has joined #wpwg 10:22:40 pirouz has joined #WPWG 10:22:54 Nicolas_A_ has joined #wpwg 10:23:20 Roy has joined #wpwg 10:23:49 adrianhb: Also want to know priority of issues to make progress 10:23:57 jyrossi has joined #wpwg 10:24:22 adrianba: API is in development at MS 10:24:32 ...the number one thing that is important to us to stabilize the API 10:24:50 ...our current implementation is experimental both in terms of UX experience and integration, 10:25:00 ..but also the way that we have prototyped it means that it's not production ready 10:25:14 ..for us to transition to shipping version, we want greater confidence that changes are diminishing 10:25:16 If anyone is interested or it is useful, we built a crude PaymentApp implementation at FB for a hackathon, I have some demo videos and am open to questions about our experience. 10:25:35 ...to the point where changes come from implementation experience rather than feature desires 10:26:08 zkoch has joined #wpwg 10:26:17 VincentK has joined #wpwg 10:26:19 ...one issue: there is currently no good way to indicate to the user that a merchant can't deliver to a particular address 10:26:28 present+ VincentK 10:26:49 ...so one option is sending back an empty list to the user to say "I can't ship" for some reason (e.g., not to a given country, or can't ship to a PO box, or address is invalid 10:27:24 ...what a user should do next based on the reason the merchant cannot shop 10:27:26 s/shop/ship 10:27:49 ...for example, if the address is invalid, the user can fix it. But if the rationale is "can't ship to a country" then no tweaking the address will suffice 10:28:10 ...so we need to figure how (the API can) do this interaction with the user 10:28:22 ...e.g., should there be an enumeration of popular reasons 10:28:33 ...but we may not want to support a generic message from the Web site 10:28:55 AdrianB: When I think about the time we've spent discussing the API, we've spent more time about merchant integration (in our team at MS) than anything else 10:29:24 ..the thing we fear the most is that we have not here spent enough time figuring out how to bootstrap the ecosystem 10:29:36 present+ DavidBirch 10:30:10 ...at the beginning when few browsers have the API and when few users will have populated with data, the process for merchants will be different than it will be in the future. 10:30:17 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 10:30:29 ...initially, adopting the API might risk merchant conversion rates 10:30:49 ...if you drive users through the API, but there isn't support for the payment methods, then there might be lower conversion 10:30:51 q? 10:30:54 q- 10:30:56 q- 10:31:02 q- Faraz 10:31:15 adrianba: We need feedback from merchants about how integration might work. 10:32:00 ...e.g., we may need to figure out how merchants can learn what is supported 10:32:16 ...we want to avoid adding yet another button to busy sites 10:32:25 q? 10:32:25 ...so we may need some other API feature in order to bootstrap the ecosystem 10:32:26 q? 10:32:30 q+ 10:32:34 zakim, open the queue 10:32:34 ok, nicktr, the speaker queue is open 10:32:37 q+ 10:32:40 ...so I'd like to hear from merchants (or those with relationships) to hear how integration will work 10:32:50 adrianhb: I suggest that we have a session specifically on bootstrapping 10:33:05 q+ to ask about privacy thoughts/implications of sharing shipping address, email, and any other information shared via selection events. 10:33:36 agenda+ Bootstrapping the ecosystem 10:33:48 ack nicktr 10:34:21 NickTR: I agree that bootstrapping is an issue; the Worldpay demo is helping us talking to our own customers 10:34:30 ack manu 10:34:30 manu, you wanted to ask about privacy thoughts/implications of sharing shipping address, email, and any other information shared via selection events. 10:35:12 Manu: I'd like to hear what the discussion has been around privacy implications of the API. When somebody selects a shipping address, there's a notification sent back to the merchant...customer can cancel out of the payment but merchant still has information. 10:35:17 q? 10:35:34 Manu: Have implementers had feedback on privacy? 10:35:42 ben has joined #wpwg 10:36:04 NickS: Today the way that Apple does this in Safari is that we don't release the email/phone until after you've paid...we take that as consent. 10:36:27 ...in terms of address, I"m not sure the problem has been solved...we redact our addresses 10:36:39 ...we return 5-digit zip in the US, we redact other information in Europe 10:36:49 ...some merchants have very unique use cases (e.g., 1 hour delivery) 10:36:59 ...sometimes the same zip code in the us can be subject to different taxes 10:37:15 ...if we ever were to release a full address, it would be with user consent 10:37:58 NickS: I work on Apple Pay (not Webkit)...so I can discuss some implementation but I would like my webkit colleagues to give the bulk of the feedback on the API 10:38:15 ...Apple offers customization in some fields...that's not supported in payment request API 10:38:37 ...e.g., changing some of the terminology used...for example, if you are a ride share service you don't "ship" 10:38:47 ...so one topic is whether the payment request API should support customization this way 10:39:11 ...second topic...we also have an option in our spec for things like "customer name"...useful for something like a ride share service where you want to know the person's name 10:39:40 ...Another topic - billing address...we heard from merchants that a lot of their systems require it. 10:40:01 ...we also have a "Discovery API"....this comes back to merchants and how they want to implement the API 10:40:27 ...we hope that payment request API will improve conversion...some merchants may want push users to use it 10:40:47 ...in some cases merchants may want to know "Can the user make a payment right now with the payment methods I support?" 10:40:55 ...so that's a more generic question than "specific payment methods" 10:41:47 ...we have the discovery API...that API is validated (merchant identity)...not sure that validation is necessary here. 10:42:06 ...the biggest difference for us is Merchant Validation..that's something we'd like to consider for this API and we think payment methods (beyond Apple Pay) will want 10:42:38 ...we make assumptions today that payment service providers will be able to accept a payment, but perhaps a merchant account has been closed. 10:42:50 ...I think we should consider merchant validation 10:43:11 ...we have a step after you start the payment request....the merchant has to provide some additional information as a security feature 10:43:26 ...helpful, eg., if a merchant's domain has been compromised. 10:43:36 ...I can see various ways that could work in the API...my webkit colleagues can provide details 10:44:04 ...generically, the question is whether we can go to the payment method provider and get acknowledgment before a bad user experience 10:44:25 ...I think we should consider the case where a payment method provider does not want to accept a payment request 10:44:37 q? 10:44:49 ...there may be other reasons to not support a payment (e.g., security infrastructure issues) 10:45:00 ...I hope to have concrete issues in github over the next couple of weeks 10:45:13 ...Apple implementation of our API is available in developer release 10:45:21 q? 10:46:01 zkoch: First a status update: Blink implementation is in line with the current spec 10:46:16 ..you can call the API with support for per-payment-method pricing, the UI does not yet support it 10:46:32 ...check out android developer channel (chrome dev) 10:46:40 ..we continue to iterate ... we made public our intent to ship 10:47:11 zkoch: In terms of issues, I have a few topics 10:47:26 ...like AdrianB I support goal of getting to CR rapidly 10:47:33 ...I think merchant feedback is really important 10:47:39 ..so spec does not have to be perfect 10:47:54 ..we've heard back that "knowing whether a payment method is available" is something merchants have asked for 10:48:22 ...trying to balance merchant and privacy requirements is tricky; we don't have a good proposal yet 10:48:54 ...another issue is that we need a way to bootstrap the ecosystem for card payment methods and sub-brands 10:49:00 ...we'd like to resolve that dependency ASAP 10:49:25 ...autofill has a security/privacy model 10:49:54 ...regarding sharing shipping address, we do share it in the DOM 10:50:04 q? 10:50:10 ...we are happy with this from a user consent perspective 10:50:44 ..but there are some issues...we can't use information as seamlessly as we might, due to consent requirement around privacy 10:50:51 ...we use "pay" as a user consent model 10:51:12 pirouz has joined #WPWG 10:51:23 ...as we get more merchant feedback I will share 10:51:26 ...e.g., iframe has come up 10:51:40 ...one question is whether to support payment request in a secure iframe even when not in a secure context 10:52:23 q+ 10:52:34 ...also, we might benefit in providing some higher-level information for merchants 10:53:07 ...we hope to ship the API before the end of 2016...we probably will be publishing a shim during a transition period. 10:53:45 ...we plan to have the implementation keep up with the spec, the shim would protect the merchant for a couple of versions of the browser 10:54:21 ...we want this to be in place by Q4 (before holiday freeze) 10:54:38 q+ 10:54:55 q- 10:55:14 holiday season varies by geography but see November and December typically as no-go areas for change for merchants 10:55:21 ack adamR 10:55:28 adamr: Is blink implementation basic card? 10:55:33 zkoch: Yes. 10:55:45 ...potentially also support for android pay 10:56:15 ...we have thoughts about third party payment apps on Android...we'd like to support this as soon as possible (notably for global payments) 10:56:33 q? 10:57:27 AjayR has joined #wpwg 10:57:33 q? 10:57:43 +q 10:58:07 reminder that the agenda is here -> https://github.com/w3c/webpayments/wiki/Web-Payments-Working-Group-FTF-Meeting-%28July-2016%29 10:58:46 Lauren_Jones has joined #wpwg 10:58:58 q? 10:59:53 zkoch has joined #wpwg 10:59:55 conor: Worldpay happy to participate in the task force 10:59:58 q? 11:00:06 https://github.com/w3c/webpayments/wiki/PaymentApp_Notes 11:00:07 ack conorh 11:00:57 q? 11:01:30 DanAppelquist: We are working on this at Samsung. 11:01:49 ...a lot of the current focus and thinking is how to connect samsung pay to the web through the samsung browser...we are at the prototype stage 11:01:53 q+ 11:02:14 q+ 11:02:16 ...so please include is in the list of implementers 11:03:09 Roy: At Facebook we did a hackathon and I implemented (draft) payment app proposal and interface with payment request API 11:03:35 ...we did this on the web and on mobile..the web was the most straightforward since the payment app proposal covers that well 11:03:51 ...on native we had to wing it and see how the payment app proposal would translate...we used intents on Android 11:04:04 ...but it did make us wonder how the web proposal would translate to native and if that's something we would want to specify 11:04:12 brian_s has joined #WPWG 11:04:49 ....I think that is most useful to be able to make it easy to pay from any device...would be interesting to try to get consistent cross-device experience for user 11:04:50 q? 11:05:13 Lauren_Jones_ has joined #wpwg 11:05:19 adrianhb: Clarification - do you mean that when I register an app that registration information is shared across devices? 11:05:22 Roy: That, too. 11:05:54 ...from Facebook's perspective, the most interesting for us would be that if you registered facebook.com as your payment app .. what would it look like if you also had a native app on your device? 11:06:12 ...we ended up implementing this through our FB SDK 11:06:24 ...that seemed to be the most natural UX 11:06:53 q+ 11:06:57 adrianhb: Seems like a good question for platform implementers who are thinking about the native app story - is there reusability in what we are doing? Will our model translate to native? Can I expose a platform API to native apps that looks similar 11:07:15 ack me 11:07:41 Ian: Following up on what Dan said - I've been reaching out to more payment method providers to roadtest the API 11:08:18 Ian: We have more card folks at the table now too - reached out to Samsung Pay - they're thinking of doing a payment method spec. I'd like to reach out to others here to reach out to other people working on Payment Method specs. 11:08:37 Ian: Please keep this in mind as we continue the discussion. 11:08:46 q+ 11:08:48 nicktr: Do you anticipate (NickS) that there would be an Apple Pay payment method spec? 11:09:14 nickS: I don't know. Apple Pay is a payment method and the output can depend on a number of factors including region 11:09:30 ...so "potentially"...might depend on things I mentioned earlier such as merchant validation 11:09:39 q- 11:10:02 zkoch: I expect we will have "documentation" (though probably not a w3c spec) 11:10:43 [IJ agrees that all these things should not necessarily be w3c specs...but whatever form they take, they are useful. Our goal is to allow scalability so we expect these to exist all over the place] 11:14:09 q? 11:14:14 ack max 11:14:24 ack Max 11:14:39 Max: On issue 2 - should payment request API only be available in top-level context (or iframe) 11:14:55 ...we support the idea of providing a security mechanism 11:15:11 adrianhb: Current proposal is top level PLUS other contexts authorized by the top-level context 11:15:27 ...e.g., top level can provide an attribute to the iframe provided by a payment service provider 11:15:53 NickS: Here's what we do today for Apple Pay - you have to have actual javascript in the top level, but you can trigger it from an iframe through post messages 11:16:08 ...we do that to support Stripe, for example, which drop in a checkout form in an iframe 11:16:20 jyrossi has joined #wpwg 11:16:34 ...also the proposal on github regarding delegation seems like it would do the job 11:16:46 ben has joined #wpwg 11:17:28 Max: In the definition of Show() method (section 4.2)...when the user selects a payment method, what happens if there's no response message. 11:17:56 adrianhb: The intention here is that we are not being specific about what the browser does.... 11:18:01 q? 11:18:27 ...in the case where ther is no content in the response.... 11:18:36 ..there is a response even if there is no data in the response 11:18:47 ..the promise resolution returns control to the browser 11:19:27 AdrianBA: The API takes into account the use case where the response data is empty 11:19:54 Max: What happens when there is a delay before the response? 11:20:47 AdrianBA: I am hearing we need to do a better job in the spec of saying when the algorithm executes; we will do that. 11:21:11 AdrianBA: Regarding support in native apps, 11:22:35 ack adrianba 11:22:35 ...UX considerations are important (e.g., to avoid spoofing UI) 11:22:35 q? 11:26:07 [Worldpay demo] 11:27:48 Conor: I have created a web service that accepts payment information from the web site. Worldpay determines which payment methods are supported and returns that list to the merchant so the merchant can build a payment request 11:28:52 [Conor shows polyfill usage from Ade on top of the service] 11:29:19 conor: When I click "authorize" credentials are sent to the site where they are tokenized; the token is then sent to the merchant's back end 11:30:11 ...tokenization happens on world pay's server 11:30:50 Conor: Browser gets data, sends to worldpay which tokenizes and sends back to the merchant 11:34:36 q+ 11:35:07 [More discussion of tokenization] 11:35:11 [One-time v. reuse] 11:35:42 MattS: This implementation is a one-time token 11:35:47 ...to avoid passing the PAN 11:36:09 q- 11:36:09 q? 11:37:32 Lauren_Jones has joined #wpwg 11:41:46 q+ 11:41:52 q? 11:43:32 Roy: When we built the Facebook version of this we did things similarly. 11:44:00 ...we encrypted the token in a cryptogram with a Facebook App API key, and expect the merchant to know how to decrypt the block 11:44:00 q? 11:44:09 ack R 11:44:20 q+ to suggest we define an enhancement to card for encrypted pan 11:44:34 conorh has joined #wpwg 11:44:35 ....so we encrypted in our back end and forwarded the token to the merchant's JS where they could maintain PCI compliance 11:44:46 IJ: I mentioned three ways to do things (which may be useful in a transition period) 11:45:00 1) Split context in the browser where there's a merchant app and also PSP code that is separate 11:45:12 2) Third party payment app does work 11:45:21 3) Payment method spec itself means token circulates 11:45:29 Topic: Expanded card payment spec 11:45:41 Nick: I have recruited a volunteer to help me write a tokenized spec 11:45:49 AdrianHB: Yes, let's call for volunteers 11:46:03 AdrianHB: I'd like to close two issues on our issue list in next 15 mins 11:46:15 - non-standard currencies 11:46:19 - which data goes to payment apps 11:46:33 q+ to ask about "new payment methods" 11:47:10 q- 11:47:16 My point is that this sounds like it's out of charter 11:47:39 People who want to work on advanced card spec: NickTR, Faraz, Laurent, Kevin(?) from Facebook? 11:47:55 topic: Proposal related to non-standard currencies 11:47:58 Max has joined #wpwg 11:48:11 -------- 11:48:11 Starters: 11:48:11 Carpaccio 1 11:48:11 Salmon 7 11:48:12 Aubergine 3 11:48:13 Scallops 8 11:48:14 -------- 11:48:16 Mains: 11:48:18 gnocchi 2 11:48:20 duck breast 4 11:48:22 Rib Eye steak 7 11:48:24 sea bass 7 11:48:26 -------- 11:48:28 Desserts: 11:48:30 Ice cream/sorbet 2 11:48:32 Tiramisu 7 11:48:34 Panna Cotta 3 11:48:38 https://github.com/w3c/browser-payment-api/issues/185#issuecomment-228117620 11:48:40 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 11:48:51 rouslan_ has joined #wpwg 11:49:59 Lauren_Jones has joined #wpwg 11:50:03 [AHB summarizes the proposal] 11:50:12 - you specify registry and entry in registry 11:50:25 - default registry is ISO 4217 registry 11:50:27 q? 11:50:33 ack AdrianHB 11:50:33 AdrianHB, you wanted to suggest we define an enhancement to card for encrypted pan 11:50:52 Kris: ISO is looking at a way to extend their current mechanism to meet this sort of requirement 11:51:40 q? 11:51:56 Kris: ISO also looking at using URLs 11:52:53 q? 11:53:31 PROPOSED: Adopt AdamR's proposal for handling currency codes and addressing 185 11:53:36 +1 11:53:39 +1 11:53:43 +1 11:53:45 +1 11:53:59 +1 11:54:00 +1 11:54:00 +1 11:54:08 +1 11:54:19 +1 11:54:23 +1 11:54:24 [No objections] 11:54:26 +1 11:54:28 SO RESOLVED 11:54:40 +1 11:54:42 +1 11:54:55 ACTION: AdamR to work on concrete spec language around currency codes 11:54:56 Created ACTION-20 - Work on concrete spec language around currency codes [on Adam Roach - due 2016-07-14]. 11:55:08 [Issue 157] 11:55:26 AHB: Question is how much data to pass to the payment app of the original payment request 11:55:28 q? 11:55:35 fnisar has joined #wpwg 11:55:44 q? 11:55:56 q? 11:56:13 q+ to note security implications of this decision. 11:56:14 q+ 11:56:31 q+ 11:57:16 [Pros and cons of sending all the original data v. sending only a subset] 11:57:25 Subset: Don't send unnecessary data; preserve merchant privacy 11:57:29 zakim, close the queue 11:57:29 ok, nicktr, the speaker queue is closed 11:57:30 Full data: Signing 11:57:33 ack manu 11:57:33 manu, you wanted to note security implications of this decision. 11:57:50 Manu: I think it's too early to decide what to do because we don't know how to prevent man in the middle attacks 11:58:05 ...general concern is inability to sign messages...since some data is at the top level 11:58:32 ...I think until we have a good strategy for how to sign pieces of message, then I have concerns about subsetting parts of the original message 11:58:51 q? 11:58:53 ...potential security issue where you can recompose messages to do things that the merchant never wanted to do 11:58:57 ack rouslan 11:58:58 Fawad has joined #wpwg 11:59:09 +1 to Manu on impact on signatures 11:59:28 rouslan: Speaking as a Google engineer, I think that Android pay would not want to have any kind of information about unsupported payment methods. So I support subsetting the data. 12:00:07 ...to address Manu's concerns, I think we should address the signature question (and rapidly). One way to avoid remixing of the payment request data is to specify exactly what we can sign...e.g., sign the details and each individual piece of API data. 12:00:15 q? 12:00:21 Q= to close 12:00:33 ...the only remixing that would be allowed in this case would be for the mediator to be able to filter the requested payment methods, which I think is it's job 12:00:41 q? 12:00:43 q? 12:00:44 ack ad 12:01:27 adrianba: My point on this was a scoping point. I think there are a variety of questions that have come up about what data gets passed to apps. I think it's an important question but is not blocking of the payment request API. I think it's tied to the broader question about communication between browser and apps 12:01:51 AdrianHB: I am ok to close this in the payment request API repo and opening in the payment app issues list 12:02:08 Possibly of relevance to this discussion: https://www.w3.org/2001/tag/doc/APIMinimization.html 12:02:30 PROPOSAL: Close issue 185 on payment request api and move to the general issue list. 12:02:38 +1 12:02:55 +1 12:02:59 [No objections] 12:03:01 SO RESOLVED 12:03:04 LUNCH 12:03:07 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 12:19:44 Adam_ has joined #wpwg 12:26:42 Roy has joined #wpwg 12:29:48 sam has joined #wpwg 12:38:38 nick has joined #wpwg 12:44:31 rouslan has joined #wpwg 12:49:16 lbolstad has joined #wpwg 12:51:03 Max has joined #wpwg 12:56:00 alyver has joined #wpwg 12:58:55 Faraz has joined #wpwg 13:01:03 fdold has joined #wpwg 13:01:16 alyver has joined #wpwg 13:04:09 conorh has joined #wpwg 13:06:26 nick has joined #wpwg 13:11:07 adamR has joined #wpwg 13:11:51 dka has joined #wpwg 13:12:59 nicktr has joined #wpwg 13:13:29 adamR has joined #wpwg 13:13:35 topic: Payment Methods 13:13:53 zkoch has joined #wpwg 13:15:09 brian_s has joined #WPWG 13:15:12 [SEPA / Direct Credit ] 13:15:40 VincentK has joined #wpwg 13:15:55 [Basic Card] 13:15:55 https://w3c.github.io/webpayments-methods-card/ 13:16:04 present+ 13:16:32 Nick, can you zoom in on screen? 13:16:34 MattS: First topic there to resolve is payment method identifiers 13:16:43 q+ 13:16:46 ...there's a long list of identifiers in the spec 13:16:49 Nicolas_A_ has joined #wpwg 13:16:49 zakim, open the queue 13:16:49 ok, Ian, the speaker queue is open 13:16:58 q+ 13:17:06 ...one thing that I think is an issue is "how we match" 13:17:39 ...the list in the basic card spec is in complete....some may be unhappy to not be listed here; those who are in there may feel we have not modeled their space correctly 13:17:48 q+ 13:17:59 q? 13:18:08 adrianhb: We have a lot of time dedicated to payment method identifiers 13:18:19 jyrossi has joined #wpwg 13:18:32 Lauren_Jones has joined #wpwg 13:18:38 pirouz has joined #WPWG 13:19:17 agenda+ PMIs (grouping and bootstrapping) 13:19:49 MattS: The basic card spec currently has no data for payment request input 13:20:04 ...one pull request from me involves the ability for a merchant to specify information as required 13:20:10 https://w3c.github.io/webpayments-methods-card/ 13:20:46 https://github.com/w3c/webpayments-methods-card/pull/4 13:21:11 MattS: the pull request enables the merchant to indicate which ones it wants the app to try really hard to get 13:21:22 Lauren_Jones_ has joined #wpwg 13:21:29 ...some merchants do not collect CVV, for example, and that's a business decision 13:21:29 q? 13:21:34 q? 13:21:35 q+ 13:21:47 ack adrianba 13:22:43 adrianba: I think this spec is not a good example of payment method specs; since cards work differently than many other payment methods 13:23:26 AjayR has joined #wpwg 13:23:28 ..for this spec you mentioned the point about differentiating debit and credit 13:23:36 ...and why it's a useful feature for some scenarios 13:23:40 ..and complexities around other matching 13:23:51 kriske has joined #wpwg 13:23:58 present+ kriske 13:24:13 ...given "cards" are special, I am leaning toward the approach where there is just one identifier for card payments 13:24:28 ..and within the payment method specific data we can provide other data such as which networks are supported 13:25:18 ...keep the URL matching simple and move extensibility elsewhere 13:25:32 ...if we did that it would change some of the conversations we're having more broadly and maybe make the card spec a better model 13:25:50 q? 13:25:59 q+ to mention "tags" vs. "hierarchy" of what the merchant wants. 13:26:19 q? 13:26:20 q- 13:26:49 MattS: SEPA also has some "required" fields requirements 13:27:14 ack CyrilV 13:27:38 Cyril: Please note that EMV has some identifier schemes 13:27:41 ..for card payments 13:28:02 q+ 13:28:03 ...we might want to refer to that work 13:28:23 q+ 13:28:27 brian_s: I think there are AIDs and extensions in EMV...it's in the same space but not quite the solution 13:28:28 ack bri 13:28:53 Nick: You can't necessarily rely on AIDs belonging to the networks that manage them 13:29:26 Ian: Matt's pull request is about the merchant saying "I need this data" - seems to me that you may want to say the opposite - "The following is 'optional' to me." 13:29:45 Ian: I can't tell whether you feel like it should be "I don't need this, don't bother." 13:30:39 Ian: I hear you saying - "this may be a requirement, maybe we should pull it out into the Payment Request API"? 13:30:49 Ian: Maybe, but not yet - that's my personal sense. 13:31:02 MattS: We called it out in SEPA spec. 13:31:25 MattS: The basic card spec does not support PCI compliance well yet 13:31:29 q- 13:31:32 ..I think we also need to address that 13:31:40 NickTR: We have agreed we will do a tokenized spec 13:32:16 MattS: Who has an implementation of basic card? 13:32:19 Zach: We have 13:32:37 Andre: We are considering it 13:32:53 AdrianHB: This is our "bootstrap" spec 13:33:17 AdrianHB: It should be possible for a merchant to support basic card as an interim step before their existing payment page 13:33:21 q? 13:33:23 q+ 13:33:50 AdrianHB: I think this is an important transition step...but I think it won't take long before there are implementations of other payment methods 13:34:13 ack me 13:34:17 Ian: I heard a proposal from Matt to accept pull request - can we try to close that loop? 13:34:44 q+ 13:34:50 q- later 13:34:52 ben has joined #wpwg 13:34:54 PROPOSED: The basic card spec should support "required fields" specification from the merchant 13:35:00 +1 to AdrianHB 13:38:03 pull request -> https://github.com/w3c/webpayments-methods-card/pull/4/commits/ba6c5c5d679596246db446ef3137f8adbffb5ecd 13:38:11 +1 13:38:15 +1 13:38:24 Zkoch: May want editorial work to make clear that this is input data. 13:38:28 MattS has joined #wpwg 13:38:33 Roy has joined #wpwg 13:38:34 rouslan has joined #wpwg 13:38:47 AdrianBa: I don't think we should do this. We should return the data we have and if the merchant doesn't want the data, they don't have to use it. 13:38:56 ...this seems like an unnecessary refinement 13:39:01 +1 to the proposal 13:40:18 AdrianBa: One of the reasons we changed the fields so that card number was the only required field, was that there are some cards where all fields don't make sense 13:40:33 ...depending on the card type, there are some fields and you have them you should return them. 13:40:51 ...one thing that MattS is suggesting is that the security code that merchants may not request 13:40:52 q+ 13:41:07 q+ 13:41:09 q+ 13:41:11 AndreaF has joined #wpwg 13:41:33 ...if a merchant chooses not to use data in its processing it can do so...it doesn't seem onerous to return data if present, and if you don't have it you don't have to give it back 13:41:35 conorhackett_wp has joined #wpwg 13:41:47 yaso_ has joined #wpwg 13:41:47 yaso__ has joined #wpwg 13:41:55 ...each new requirement increases implementation and testing cost 13:42:11 ...my position is that we can still be successful without this feature...we can add later 13:42:15 ack zkoch 13:42:24 zkoch: In the case you return back more data than the merchant has requested you don't lose anything 13:42:42 MattS: You can't store CVC..you always have to capture it...but some merchants don't want it due to checkout friction 13:44:06 zkoch: The case of "not getting data you need" is worse than "getting too much data beyond what you want" 13:44:26 adrianba: the only case we would return without a cardholder name is where there is a card that does not have a name, so I wouldn't return it 13:44:33 q? 13:44:40 ack adrianba 13:45:04 zkoch: The downside of having too much data is "thrown away" with potential of lost sale...but you don't have insight into reasons for lost field. 13:45:12 ...this is therefore a "nice to have" feature. 13:45:28 AdrianBA: You could add to the spec and we ignore it. 13:45:51 ack nick 13:46:09 nick: One question I have - what happens if you accept union pay (for example) and visa and the required fields are different 13:47:05 ...the current proposal doesn't address some use cases 13:47:20 q? 13:47:26 MattS: That's why we are focused on the use case today - whether "required fields" use case is worth being a feature in v1 13:47:47 MattS: I think this is "do-able" if this is advisory and the payment app does its best to fulfill the merchant's expectations 13:48:12 Nick: I think it's unlikely that user agents will know what to do for each payment method 13:48:35 laurent: getting too much data may have compliance implications 13:48:39 Laurent: There's also a question about receiving sensitive data (e.g., PCI compliance) that you don't want 13:48:42 ... eg for PCI DSS 13:49:04 ack Laurent 13:49:21 Laurent: So if you get more data than you want, it may harm your compliance 13:49:24 ack Faraz 13:50:13 Faraz: One alternative is to not query the customer if you recently gathered data from the user 13:50:22 ...so there may be other ways to minimize friction 13:51:07 NickTR: I am not hearing consensus yet. 13:51:17 ..therefore we will not resolve the issue in this session 13:51:19 q? 13:51:41 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 13:53:39 q? 13:53:45 huwb has joined #wpwg 13:53:55 {IJ wonders whether we should think about "optional" approach and see if that's easier to manage) 13:54:00 [Direct Credit] 13:54:35 http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/ 13:55:08 shepazu has joined #wpwg 13:55:19 MattS: As it is written, it is the SEPA Credit Transfer spec 13:55:53 ...we stripped out non-SEPA stuff and also direct debit stuff 13:55:57 ...we have narrowed the scope 13:56:24 ...the others are important...we just felt it was good to do a smaller set of things well and then do the others once we have the experience 13:57:02 ...in the SEPA CT case, the payment app initiates the payment 13:57:12 (the push version) 13:57:33 q+ 13:57:43 ..there is a variation with SEPA that is a pull version, but there are some security issues that are being dealt with separately 13:58:22 ...this is a case where the payment method absolutely needs input fields 13:58:27 q+ 13:59:13 MattS: Do people feel that collaboration diagrams are a better way of diagramming than a sequence diagram? 13:59:13 +1 to collaboration diagram 13:59:20 Adam__ has joined #wpwg 13:59:21 +0 I have no idea what those mean 13:59:23 :) 13:59:23 0 because I like both 13:59:26 +1 13:59:35 +1 13:59:37 +0 (-1 maybe because I like sequence diagrams) 13:59:42 I don't think the diagrams help all that much (the ones in the spec right now) 13:59:43 +0 I also like both 13:59:44 +1 Collaboration diagram 13:59:45 I don't know what collaboration diagram v. sequence 14:00:03 0 14:00:06 +0 14:00:14 -1 — sequence diagrams make information flow much clearer, IMHO (although I appear to be in the minority here) 14:00:22 NickTR: SEPA Pull anticipates something we've not seen in the wild yet.... 14:00:41 MattS: I think this points at PSD2 14:00:58 DavidBirch: In the UK payments version of this this is called "request to pay" 14:01:16 ...maybe avoid the phrase "pull" since that might create some confusion 14:01:44 q? 14:01:46 MattS: I am ok to refactor to common vocabulary; our focus was more on SEPA and using that terminology 14:01:48 ack nicktr 14:02:28 DavidBirch: In the general case, the transfer will be instructed through the bank API...the payment will still be user initiated (either triggered by merchant or by user account directly 14:02:37 ...I think credit transfer may become a bigger part of the landscape 14:02:53 ...so I think it's worth investing the effort 14:02:54 ack zkoch 14:03:18 zkoch: My mental model for the payment app is that anyone can write a payment app that can return credit card info. Is the same true with SEPA? 14:03:46 emschwartz has joined #wpwg 14:03:47 Cyril: for cards, all merchants are connected to acquirers, so it works 14:04:08 ...for credit transfer .... if someone wants to develop a SEPA app, it may be a bank for its own customers 14:04:24 ...the API needs to be secure (with auth, etc.) 14:04:58 ..the idea of PSD2 is to generalize the mechanism so that any type of regulated entity can have access 14:05:27 zkoch: So it's more regulated 14:05:48 q? 14:05:53 MattS: Part of PSD2 is the open banking API.... 14:06:24 DavidBirch: there is strong support for the open api framework 14:06:53 nickTR: You can build third party apps to log into an online banking Api that lets you do credit transfers 14:06:58 q+ 14:07:24 zkoch: I am hearing that banks do this today, but in the future more will be able to do this (NickTR: PISPs) 14:07:27 DavidBirch: This is being mandated in Europe 14:07:42 q+ to make a few comments on spec - flows are too detailed, align vocabulary. 14:07:57 zkoch: The input and responses to these are well-defined by regulatory bodies 14:08:35 q? 14:08:50 zkoch: What is added value of our own specs if these are specified elsewhere? 14:09:00 fdold has joined #wpwg 14:09:34 MattS: The spec (5.1) does reference the SEPA rule book. 14:09:42 ...not every thing from the SEPA rule book is required 14:09:53 ...we've also turned terms into what we think will be more developer-friendly 14:10:04 q+ 14:10:30 DavidBirch: IN the UK and in EU environment, the likely implementation of this.... 14:10:34 ...will be done through directories 14:10:45 ...I want to illustrate that in the final version will be more user-friendly 14:10:56 ...you won't type things in 14:11:12 ..just to illustrate why we should be thinking about this use cases 14:11:37 MattS: What we are envisaging is that the user clicks on "pay", logs into the bank payment app, and information is known by the bank 14:11:57 q? 14:12:09 ack jy 14:12:19 jyrossi: The ecosystem has been created through regulation...it's a work in progress 14:12:41 q+ DavidBirch 14:13:21 ack manu 14:13:21 manu, you wanted to make a few comments on spec - flows are too detailed, align vocabulary. 14:14:07 Manu: Regarding diagram in the SEPA spec...I appreciate that amount of detail, but I think it's "too much" 14:14:18 ...for the spec...I think it would be ok to link to it...or a simpler diagram 14:14:26 ...also, the vocabulary that's used in the messages 14:14:58 ...it would be good to get consistency across specs (e.g., how we express input and output across the specs) 14:15:22 q? 14:15:26 ...we reuse fields like "address' and "postal code" except that the field name in sepa doesn't align with payment request API 14:15:42 q+ to discuss code conventions and commonality across payment method specs 14:17:38 ack Ian 14:18:16 Max has joined #wpwg 14:18:45 q+ 14:20:30 q+ 14:20:54 q+ 14:21:01 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 14:21:03 +1, I would also like to discuss the AliPay spec 14:21:24 ack DavidBirch 14:21:40 DavidBirch: The EBA is not creating technical specs 14:22:24 IJ: When are EBA requirements coming out? 14:22:32 NickTR/DavidBirch: This month 14:22:44 ack AdrianHB 14:22:44 AdrianHB, you wanted to discuss code conventions and commonality across payment method specs 14:23:02 AdrianHB: I think to answer your question slightly - any payment method that we want to support through the API we need a "spec" for 14:23:23 [IJ notes that some of these things may be "specs" and some may be "documentation"; let's not focus on the word "spec"] 14:23:36 q+ 14:23:49 AdrianHB: Our payment method specs say what data is necessary to initiate or send back a payment request/response 14:24:00 nick has joined #wpwg 14:24:07 ...we need these specs because even if the payment methods are defined elsewhere, they do not specify concretely what is needed for a payment request 14:24:42 adrianhb: Another general point - I think we must be wary of prematurely trying to find common data and pushing it to the payment request level 14:24:53 +1 to AHB - we need to write some of things to find the generalisations 14:25:00 ...even if three different payment methods require addresses, there may be specifics per payment method 14:25:09 q? 14:25:21 +! to not trying to harmonize up front (but keeping it in mind for later) 14:25:23 ack kriske 14:25:26 ack kriske 14:25:52 kriske: On SEPA, the credit transfer is defined...the thing is "how to get it from this environment into a proper credit transfer"..that's the purpose of these specs 14:26:26 kriske: I don't think that we will arrive at a stage where ISO20022 terminology will be shown on the user screen .... it is key that we use the same types that are defined in ISO20022.... 14:26:38 ...if they are not the same types, some magic will have to happen somewhere (mapping) 14:26:45 akc nicktr 14:26:46 ...we need to have these types interoperable 14:26:50 zakim, close the queue 14:26:50 ok, Ian, the speaker queue is closed 14:26:50 ack nicktr 14:27:02 nicktr: I am a very strong +1 that we define these payment methods 14:27:12 ...the reason that they are instructive are they let us examine other specifications closely 14:27:23 ..and ensure the underlying specs are not card-specific 14:27:47 ack jyrossi 14:27:54 ...we want the Web spec to be usable all over the world 14:28:15 jiajia has joined #wpwg 14:28:27 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 14:28:47 jiajia has left #wpwg 14:28:56 jyrossi: +1 to making sure we look at these flows 14:29:09 jiajia has joined #wpwg 14:29:19 ...I think we should continue to study SEPA Direct Debit (which was pulled out of the SEPA CT spec yesterday) 14:29:37 q? 14:29:54 DavidBirch: I think we should not pay attention to direct debit 14:30:07 ...to susceptible to fraud 14:30:22 ack Ni 14:30:45 q+ 14:30:49 Nicolas_A_: Credit transfers are not just the future; e.g., in NL 90% use credit transfer today 14:31:14 SDD is still in use in EUROPE. Thanks for us. 14:31:23 [Alipay] 14:31:35 q+ once Alipay and Ian have done the intros / explainer 14:31:44 rouslan has joined #wpwg 14:32:15 zakim, open the queue 14:32:15 ok, Ian, the speaker queue is open 14:32:19 q+ 14:32:22 Alipay spec (without diagram) -> https://w3c.github.io/webpayments/proposals/Alipay-payment-method.html 14:32:22 http://www.plantuml.com/plantuml/proxy?fmt=svg&src=https://raw.githubusercontent.com/w3c/webpayments-flows/gh-pages/PaymentFlows/AliPay/AliPay-Current.pml 14:32:29 fdold has joined #wpwg 14:32:44 fdold_ has joined #wpwg 14:32:48 zakim, open the queue 14:32:48 ok, nicktr, the speaker queue is open 14:33:13 q? 14:33:23 Max: I think Alipay is similar to other third party payment methods 14:33:30 [Max reviews the flow] 14:33:43 ....user can select Alipay as a payment method 14:34:37 ..alipay server sends synchronized message to the browser 14:34:42 ...and async message to the merchant server 14:34:49 ...merchant can confirm payment using either one 14:36:41 ...another comment that I think is valid for other similar payment methods 14:37:11 ...when the user agent displays matching payment apps, maybe we can add a parameter to allow the user to redirect to the third party payment website 14:37:24 ...sometimes the third party payment provider may have customized UI 14:37:41 q+ to note redirect URL could be part of the registration 14:37:54 q+ 14:38:11 q- 14:38:16 Ian: I think that's part of the payment app specification today - one way to launch a Web-based payment app is to give payment request data to a URL 14:38:24 ack nick 14:38:27 q+ to talk about other user experience topics 14:38:54 nickS: Why are there fields that overlap with payment request API 14:38:54 https://w3c.github.io/webpayments/proposals/Alipay-payment-method.html 14:39:19 q+ to ask how signatures are created over this information? Is it in the spec? 14:39:26 Max: This was our first try, so if there are params in payment request API, then we should not duplicate them 14:39:35 ack rou 14:39:49 rouslan: Thanks for producing the draft! You put "charset" in there 14:39:54 ...javascript is almost always Unicode 16 14:40:04 ...do you use input charset for other purposes than communicating with the browser? 14:40:40 Max: We support multiple encodings...UTF8 is popular for some customers 14:40:49 Rouslan: Some of these fields might need some examples 14:41:10 ...do you have links to original documentation? ...suggest links to official documentation 14:41:12 Ian: +1 14:41:18 q? 14:41:24 q- 14:41:26 ack Ian 14:41:26 Ian, you wanted to talk about other user experience topics 14:41:36 q+ to ask about how signatures are used. 14:42:17 q+ to propose that we take up the alipay specification as a working group work item 14:42:26 Ian: The starting point for the conversation was "How does this improve the user experience beyond what we have today?" - Alipay showed me two ways to initiate a payment. For some payment methods, there may not be user experience benefit wrt. typing. 14:42:26 q? 14:43:17 q? 14:43:18 Ian: There are also further benefits - one of them had to do with the edge case where the user has one payment app when they go to pay. My brute force thought on how this works - I click on Alipay button, I have to click again even though I only have one choice - browser may decide to shortcut choice. 14:43:51 q? 14:43:52 zkoch: We've been talking about this - direct passthrough, there are circumstances under which it might make sense. 14:44:07 Ian: I mention that to bring up - we would probably not specify, but we could call that out. 14:44:36 nicks: Another use case - today, many merchants have paid placement agreements. 14:45:05 nicks: Maybe one could have "checkout w/ PayPal", which still uses this mechanism, but you could have another button for everything else. 14:45:39 Ian: You might say "I accept payment app registrations", facilitating registration so that the user has to do even less. 14:46:07 Ian: Payment Apps storing authentication information - interesting question, don't know regulatory implications - the goal is as fast as possible to pay for stuff. 14:46:30 q+ 14:46:35 Ian: I've authenticated to Alipay, do I have to authenticate again or is it cached? What can we tell payment app developers about caching authentication information - yet another faster checkout idea. 14:46:42 ack zkoch 14:47:09 q+ 14:47:31 zkoch: It's worth mentioning that there are other web platform APIs that are interesting - like Credential Management API. A trusted model - something to look at. How APIs interplay, work here from WebAppSec that we should look into. 14:47:49 q+ 14:47:56 dbirch: If I'm logging in from home, Visa doesn't require 3D Secure - but if I'm logging in from somewhere else, they require login. 14:48:48 Ian: If you're browsing, click on the Buy button - do merchants still need users to know which payment apps you have - question is whether payment request API should have an option to say "You may also like... " 14:49:01 Ian: So, what merchants what might like. 14:49:05 q? 14:49:07 q? 14:49:17 q- later 14:49:37 dbirch: If I'm a merchant and I want customers to play with American Express, I may want to steer customers and make AmEx displayed first. 14:50:07 q+ 14:50:35 Ian: If saving typing is not a benefit, there are other reasons - consistent user experience across payment methods. The long term vision is the same in app, in store, and on the Web. It's the same across payment methods. 14:51:02 Ian: Slightly longer-term benefit, once we have payment apps easily integrated into checkout experience, payment apps doing loyalty is helpful for retailers. 14:51:11 q+ to note merchant feedback on coupons and loyalty 14:51:42 Ian: Third one - matching and user preferences make the checkout experience easier, checking for relevant app - it shows up again and again for you. Bottom line, we still think this is better. 14:51:43 ack manu 14:51:43 manu, you wanted to ask about how signatures are used. 14:51:51 Manu: Alipay spec uses signatures 14:52:04 ...both merchant-initiated and Alipay response signatures 14:52:07 ...can you say why? 14:52:26 Max: We want to ensure that message is actually coming from Alipay (or from merchant) 14:52:50 Manu: the assumption is that you don't care if HTTPS is wrapping the exchange...you want to make sure that the message itself is secure 14:53:27 Max: HTTPS can only secure the channel, not the content of the message, so we sign the data as well 14:53:42 zkoch: Is it similar to the way that Apple Pay does merchant validation? 14:54:48 zakim, close the queu 14:54:48 I don't understand 'close the queu', nicktr 14:54:49 Max: Yes 14:54:51 zakim, close the queue 14:54:51 ok, nicktr, the speaker queue is closed 14:55:06 q? 14:55:26 ack dka 14:55:46 danielA: Ian, I wanted to respond to something you said earlier about making it easier for payment apps to be registered 14:56:09 q- later 14:56:29 Ian: I meant to imply that there are settings that make some things easier to accept globally - can we make it easier to accept payment apps? 14:56:35 dka: I'm very concerned about that. 14:56:52 dka: A payment app by itself is powerful, it can reach into your device - it's active, not inert. 14:57:04 Ian: All that's being given to the browser is just information about the app. 14:57:23 q? 14:57:37 ian: When you see your user interface, you see it as an option to allow it. We're not enabling a powerful feature, just checking to see if it exists. 14:57:37 daniel: I am concerned about registration security...e.g., a fingerprinting issue 14:57:38 dka: it could still be a fingerprinting issue. 14:57:47 ack Cyr 14:58:08 CyrilV: Ian, I want to comment about what you said about authentication....this is a key security component for payment 14:58:30 ...so far authentication for card schemes is accepted by the card schemes (including ways like Apple Pay) 14:58:38 ...that's because responsibilities are clear 14:58:53 ...and there are regulatory obligations as well (e.g., 2factor with exceptions) 14:59:03 cf TAG finding on unsanctioned tracking https://www.w3.org/2001/tag/doc/unsanctioned-tracking/ 14:59:11 ...we should leave authentication issues to the payment mechanism 14:59:20 q? 14:59:37 ack Max 15:00:11 Max: Regarding HTTPS, we don't use it to authenticate the merchant...rather the merchant authenticates directly to our server 15:00:46 Max: Another point ... from our experience we think that for payment request API, it should allow when the user selects Alipay, browser should allow redirect to Alipay site 15:01:01 {IJ thinks this will be supported] 15:01:01 ack nicktr 15:01:01 nicktr, you wanted to propose that we take up the alipay specification as a working group work item and to note merchant feedback on coupons and loyalty 15:01:33 NickTR: When I talk to merchants, they are really enthusiastic about coupons in payment apps 15:01:57 NickTR: Second point I want to make is that we take up Alipay spec as a payment method spec 15:02:22 PROPOSED: The WG should take up the Alipay payment method spec to published as a W3C Note 15:02:33 AdrianBA: I object to that. 15:03:05 AdrianBa: I think that, especially at this stage, it's valuable for us to investigate different payment methods that work in different ways to ensure that the API supports them. 15:03:14 ...as a way of taking forward the original flows work in a more concrete way 15:03:32 ...but I don't think that it's valuable to the ecosystem to have vendor-specific payment methods published as W3C documents 15:03:40 q+ 15:03:46 ...that in fact we should be encouraging a practice where vendors publish them 15:03:51 zakim, open the queue 15:03:51 ok, Ian, the speaker queue is open 15:03:53 q+ Roy 15:04:13 q+ 15:04:20 +1, I think it could rapidly become unmanageable 15:04:22 ...if we are successful, there will be dozens of these things and I don't think we should set a precedent that these should become W3C documents, and we should not favor some vendors with W3C document status and not others 15:04:39 ack Roy 15:04:50 Roy: I have the same concern expressed by AdrianBA 15:05:01 q+ 15:05:02 ...I question whether this is the best medium for exploring payment methods 15:05:18 q+ to say there is value to get people into the group and guide them through the process. We can always prioritize or spin off a Task Force. 15:05:22 ...should we use a lighter weight approach to producing the spec than a WG? 15:05:24 ack Max 15:05:44 q+ or send them to a Payment Method Community Group. 15:05:45 Max: As a response to AdrianBA's concern...the WG has a basic card spec that has payment method identifiers in it 15:05:52 q+ to say or send them to a Payment Method Community Group. 15:05:56 ...what's the difference between that and other payment methods? 15:06:10 AdrianBA: I plan to propose that we remove PMIs from the basic card spec 15:06:17 ...but I haven't had time 15:06:40 ...we'll also have discussion about changing this specification so that it is not as proprietary, and network information is a parameter 15:06:56 ...I agree it's problematic to have only some brands in the basic card spec or not 15:06:59 ack adrianhb 15:07:15 Max: Maybe we should attempt a generic approach 15:07:24 q+ 15:07:28 AdrianHB: It could be valuable to see whether there is commonality among different types of payment methods 15:07:33 q+ 15:07:39 ...we may find that there are commonalities and it's worth creating a standard 15:07:52 q+ 15:07:56 adrianhb: I appreciate the concern about publishing vendor-specific specs 15:08:06 ...I think we could even call it a "push payment" spec 15:08:24 ...e.g., where there's a merchant id and a call back URL and a transaction id 15:08:31 ...this might help us avoid massive fragmentation 15:08:50 q- 15:09:26 ack Manu 15:09:26 manu, you wanted to say there is value to get people into the group and guide them through the process. We can always prioritize or spin off a Task Force. and to say or send them 15:09:29 ... to a Payment Method Community Group. 15:09:36 q+ 15:10:07 Manu: If there is objection to doing this in the WG as a WG Note, perhaps we should create a CG to work on these, with guidance to companies on how to do this 15:10:09 q+ 15:10:31 ...I still think that there is value to keeping discussion going in the WG while there still may be impact on the API 15:10:35 +1 to Manu 15:10:39 +1 for working on the illustrative specs in this group 15:10:42 +1 to manu 15:10:47 +1 to manu 15:10:47 q- 15:10:48 ack M 15:10:54 ack adrianba 15:10:54 +1 to manu 15:10:54 queue=Roy,Max,rouslan 15:11:21 adrianba: I want to be clear that my objection is to a TR document...but I want to emphasize that it's super valuable that we are discussing it in this WG and we should continue to discuss it 15:12:04 IJ: we can just work on it in our github repo 15:12:16 zakim, close the queue 15:12:16 ok, nicktr, the speaker queue is closed 15:12:31 AdrianBa: I am fine with that. At this stage of the process, it's valuable that the WG is discussing these. At some point these docs should be done by their owners 15:12:58 Ian: In the past, we've talked about two best practices - how to do payment apps, and another that says how to do payment method specs. 15:13:40 Ian: Should we do payment method spec guidance? Anyone want to volunteer for that? 15:13:41 ACTION: Max to work with Ian on starting some payment method good practice documentation. 15:13:41 Error finding 'Max'. You can review and register nicknames at . 15:13:46 q? 15:13:49 ack roy 15:14:02 I would be happy to assist with the guidance document Ian and Max 15:14:05 Ian - happy to help with the Payment Method specs 15:14:07 Roy: One thing that stands out with this payment method is the push part 15:14:09 q- 15:14:45 Roy: It would be interesting to look for commonalities among push payments 15:15:02 fawad has joined #wpwg 15:15:05 q? 15:15:53 adamR_ has joined #wpwg 15:16:47 rrsagent, make minutes 15:16:47 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 15:35:47 nick has joined #wpwg 15:37:22 rouslan has joined #wpwg 15:40:58 dka has joined #wpwg 15:42:47 rouslan has joined #wpwg 15:42:48 lbolstad has joined #wpwg 15:42:52 present+ 15:44:00 Roy has joined #wpwg 15:44:33 zakim, code? 15:44:33 no conference has been identified yet, wseltzer 15:44:59 Max has joined #wpwg 15:46:36 rouslan has joined #wpwg 15:46:38 alyver has joined #wpwg 15:47:19 topic: Security Review 15:47:29 https://lists.w3.org/Archives/Public/public-payments-wg/2016Jul/att-0013/WebpaymentsAPISecurityandPrivacyChecklist.pdf 15:47:38 security review -> https://docs.google.com/document/d/1w7ginyzNg-xZUmITK4vzcGUKB4gbMOAvlkWWaRtX14k/edit?pli=1# 15:47:48 AdamR: We used the TAG checklist (still in development) to do a security review 15:47:58 or pdf -> https://lists.w3.org/Archives/Public/public-payments-wg/2016Jul/att-0013/WebpaymentsAPISecurityandPrivacyChecklist.pdf 15:47:59 ...Evgeny, Ian, and I developed answers to the questions 15:48:08 zkoch has joined #wpwg 15:48:10 ...we wanted today to go over the recommendations that resulted from the analysis 15:48:14 zakim, code? 15:48:14 no conference has been identified yet, wseltzer 15:48:18 fdold has joined #wpwg 15:48:42 nick has left #wpwg 15:48:49 nick has joined #wpwg 15:48:53 Call in numbers are here, Wendy 15:48:53 3.1 Does this specification deal with personally-identifiable information? 15:48:55 https://www-emea.intercallonline.com/listNumbersByCode.action?confCode=875114&area=viewNumber 15:49:05 and conference code is 875114 15:49:14 q? 15:49:15 AdamR: We recommend for this one enhancing privacy considerations of Payment Request API spec 15:49:21 ack Max 15:49:25 zakim, open the queue 15:49:25 ok, nicktr, the speaker queue is open 15:49:27 q- 15:50:12 present+ wseltzer 15:50:58 MattS has joined #wpwg 15:51:12 3.2 Does this specification deal with high-value data? 15:52:14 q+ 15:52:30 ben has joined #wpwg 15:53:12 q+ 15:53:44 zkoch: I am not sure that it's our place to tell businesses where to store or not store credentials. 15:53:52 akc zkoch 15:53:56 ...I want to push back on PCI specifically 15:53:56 ack zkoch 15:54:02 ...this is governed outside of us 15:54:20 ..I don't think we need to say anything...merchants need to be independently aware of this or use services that make them not aware intentionally 15:54:42 AdamR: The card spec strongly encourages storing credit card information...a casual read might suggest that is best practice 15:54:54 ...I think that we need to highlight that that is NO LONGER a best practice given the payment request API 15:55:07 ...and we should not have flows or language that Encourage storage 15:55:22 zkoch: +1 to opening an issue with this. I think we could make the language more neutral in the spec regarding storage 15:55:34 q? 15:55:55 adamr: I think it's at least useful to have some discussion about the advantages of not storing, and that the historic advantages to storing are largely removed through these specs 15:56:08 zkoch: I am ok with that...expressing goals and implying that storage is no longer 15:56:16 adamr: That sounds good 15:56:59 AdamR: I think we don't want to remain silent on PCI since anyone who reads the spec will say "What about this?" We should therefore say explicitly something if only to redirect people . 15:57:04 +1 to saying something 15:57:18 to alert people to the security consideration 15:57:19 zkoch: I think it's also reasonable to say "PCI is out of scope for this spec" with a link....I want to minimize our touching on this too much 15:58:21 adrianhb: I support the approach were we are explicit that we are not making PCI go away 15:58:25 q? 15:58:30 ack ad 15:58:55 3 15:58:55 . 15:58:55 4 15:58:55 D 15:58:56 o 15:58:57 e 15:58:58 s 15:59:00 t 15:59:02 h 15:59:04 i 15:59:06 s 15:59:08 s 15:59:10 p 15:59:14 e 15:59:16 c 15:59:18 i 15:59:20 f 15:59:22 i 15:59:24 c 15:59:26 a 15:59:28 t 15:59:30 i 15:59:32 o 15:59:34 n 15:59:36 e 15:59:38 x 15:59:40 p 15:59:44 o 15:59:46 s 15:59:48 e 15:59:50 p 15:59:52 e 15:59:54 r 15:59:56 s 15:59:58 i 16:00:00 s 16:00:02 t 16:00:04 e 16:00:06 n 16:00:08 t 16:00:10 , 16:00:14 c 16:00:16 r 16:00:18 o 16:00:20 s 16:00:22 s 16:00:24 - 16:00:26 o 16:00:28 r 16:00:30 i 16:00:32 g 16:00:34 i 16:00:36 n 16:00:38 s 16:00:40 t 16:00:42 💩 16:00:44 a 16:00:46 t 16:00:48 e 16:00:50 t 16:00:52 o 16:00:54 t 16:00:56 h 16:00:58 e 16:01:00 w 16:01:02 e 16:01:04 b 16:01:06 ? 16:01:08 3.4 Does this specification expose persistent, cross-origin state to the web? 16:01:14 AdamR: We recommended adopting the "required fields" PR for privacy reasons 16:01:14 q? 16:01:16 AdamR: We also think that there should be some consideration to exposing some sort of tracking potential to the user 16:01:19 ...from a UX perspective 16:02:42 IJ: Any other examples of alerting the user that "by doing this there may be privacy implications"? 16:03:00 q? 16:03:24 Wseltzer: Check out TAG guidance on unsanctioned tracking 16:03:25 q+ 16:03:32 https://www.w3.org/2001/tag/doc/unsanctioned-tracking/ 16:03:49 adrianhb: For me, I am trying to reconcile how using the payment api to send card merchant than how it works today 16:03:59 ...is the difference that there is less friction? 16:04:05 AdamR: Furthermore it's potentially automated. 16:04:38 rouslan has joined #wpwg 16:05:03 q+ 16:05:09 ack AdrianHB 16:05:29 q+ to ask if the tracking comes from exposing addtional information apart from credit card 16:06:05 IJ: question is whether to give users a slights head-up given ease of transaction 16:06:18 AdamR: Also notice that other payment methods will reduce traceability 16:06:23 q- 16:06:25 For those that haven't seen this - it's really interesting/scary: https://panopticlick.eff.org/ 16:06:38 Nick: Note that in EMV tokens are persistent 16:06:51 ..the token PAN is the same (e.g., from Apple Pay) every time 16:07:02 NickS: The token is the same; what changes is the bit that embeds the amount 16:07:07 rouslan has joined #wpwg 16:07:14 ..[with apple pay] the token is different across devices, however 16:07:21 -> https://www.w3.org/TR/2015/NOTE-fingerprinting-guidance-20151124/ PING note on Fingerprinting Guidance 16:07:34 adrianhb: So is this different enough to mention the tracking risk? If it is, then where we say this we need to say where it's different 16:08:08 nickS: I think this is a reasonable concern. I think the answer is to let the user know they can disable 16:08:37 adamr: I don't think payment request API is the right place 16:09:27 q+ to focus on more important security issues (that review didn't catch, imho) 16:10:12 IJ: Should this be in payment app spec? 16:10:15 Laurent has joined #wpwg 16:10:30 adrianhb: May not suffice...also makes sense for card payments in payment request 16:11:02 RESOLVED: Add an issue on the privacy considerations 16:11:28 ACTION: Ian to work with AdamR and Jonny on raising an issue about privacy notifications about sharing identifiable information 16:11:29 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ijacobs, ijmad). 16:11:40 q? 16:11:43 ack manu 16:11:43 manu, you wanted to focus on more important security issues (that review didn't catch, imho) 16:11:45 q+ 16:12:27 rouslan has joined #wpwg 16:12:34 manu: we need to talk about man in the middle attacks 16:12:50 nick: isn't that a payment method specific concern 16:12:52 rouslan has joined #wpwg 16:13:28 manu: not only. There are aspects of the request which can still be subject to attack 16:13:39 nick: how would you secure a basic card payment? 16:13:58 manu: a signature on the whole message? 16:14:01 q? 16:14:01 q+ 16:14:06 ack Ian 16:14:47 ian: talking to webappsec and doing the review is what we are chartered to do. Are there suggestions for other stuff we need to do? 16:14:55 manu: we need to talk to experts? 16:15:24 ian: this is happening inside member companies. no opposition to soliciting other reviews 16:15:52 rouslan has joined #wpwg 16:16:01 danielappelquist: Speaking as a member of the TAG, I think it is valuable to go through this checklist (even if it's not "sufficient" it's "useful") 16:16:10 ...I like the report that I'm seeing; it's a good validation of the process 16:16:27 q+ 16:16:44 ack nick 16:17:14 NickTR: Building on what Ian said...we have a roomful of people here..I imagine we all have security counterparts...I would ask the whole group...can you each take away as a challenge some engagement from your security organizations 16:17:20 ...I'm happy to sponsor a task force within this WG 16:17:30 q? 16:17:37 q+ to start tracking attacks in "Security" document. 16:18:01 q? 16:18:08 q- 16:18:20 ACTION: NickTR to try to get a security review organized within Worldpay 16:18:20 Created ACTION-21 - Try to get a security review organized within worldpay [on Nick Telford-Reed - due 2016-07-14]. 16:18:29 ACTION: Huw to try to get a security review within Amex 16:18:29 Error finding 'Huw'. You can review and register nicknames at . 16:18:44 ACTION: Cyril to try to get a security review within BPCE 16:18:44 Created ACTION-22 - Try to get a security review within bpce [on Cyril VIGNET - due 2016-07-14]. 16:18:59 NickTR: I think that security reviews are largely going to be payment method specific. 16:19:03 s/NickTR/NickS 16:19:17 ...it will be beneficial for those with payment methods to consider how they might mitigate security concerns 16:19:25 rouslan has joined #wpwg 16:19:27 AdrianHB: I think our priority will be generic payment methods 16:19:31 q? 16:19:36 ack Manu 16:19:36 manu, you wanted to start tracking attacks in "Security" document. 16:19:51 Manu: I would feel much better if the group were to track potential attacks against the API and document those 16:20:12 q+ 16:20:16 q+ to propose a wiki page 16:20:18 ...for a man-in-the-middle attack in a card payment, here's what we do or don't do 16:20:20 q? 16:20:21 q- later 16:20:44 q? 16:20:51 Manu: We need to record the knowledge 16:20:54 Ack Ad 16:20:54 AdrianHB, you wanted to propose a wiki page 16:21:11 adrianhb: I am prepared to create a page to track this stuff, and to organize the information by payment method 16:21:19 assemble the knowledge in a wiki! Maybe at some point publish a Note 16:21:25 ACTION: AdrianHB to create a resource that speaks to security topics 16:21:26 Error finding 'AdrianHB'. You can review and register nicknames at . 16:21:52 q? 16:21:56 ...the idea is that people will be able to suggest information like "here's the attack surface, here's what we've discussed, here's what we recommend, etc." 16:21:58 ack wseltzer 16:21:59 ack wseltzer 16:22:15 wseltzer: I like the thought that I'm hearing going ... thanks to the group for taking on that work 16:22:26 We did a threat review on http signatures (audit) a while ago - we should at least list these sorts of attacks: https://web-payments.org/specs/source/http-signatures-audit/ 16:22:39 ...as a spec that's dealing with a lot of high-value and privacy sensitive information, it will be important to be able to show that we've taken these issues into account 16:23:08 https://tools.ietf.org/html/rfc3552 16:23:12 brian_s has joined #WPWG 16:23:12 wseltzer: With respect to protocol design, see IETF guidance on security considerations 16:23:24 q? 16:23:41 IETF Guidelines for Security Considerations: https://www.ietf.org/rfc/rfc3552.txt 16:23:50 3.14 How should this specification work in the context of a user agent’s "incognito" mode? 16:24:38 AdamR: We think the api should work in incognito mode 16:24:54 rouslan has joined #wpwg 16:24:54 ...but since we've talked about the ability to grant permission to get a 1-click experience 16:25:08 ...obviously that has some privacy implications especially in incognito mode 16:25:39 ...the recommendation is that the stored information be available but to suggest user confirmation (e.g., that you will be unmasked from incognito mode) 16:25:45 [Review of existing incognito mode] 16:26:36 NickS: Apple Pay - We don't disclose information to the site that payment methods are available when in incognito mode 16:27:07 rouslan has joined #wpwg 16:27:07 zkoch: I think the best model we have here is autofill...you still have the information you had, but we don't save NEW information 16:27:30 ...I think what NickS says is about third party apps...and I agree we need to think hard about incognito mode 16:27:31 q? 16:27:46 q+ to ask if it makes sense to even talk about this in a spec that does not talk about UI? 16:28:15 q+ to ask about probing in general 16:28:22 q- in that case 16:28:23 adamR: Sites should not be able to easily know that a user is operating in incognito mode 16:28:27 q- 16:28:46 ...there may also be ways to figure out what's going on (e.g., time required for a promise to return) 16:28:51 q? 16:29:09 Adam__ has joined #wpwg 16:29:13 ..we also recommend that the web payment app operates in incognito mode as well 16:29:27 ...we recommend that text be brought into the payment request API spec 16:29:39 ..in some form 16:29:46 is there a generic term for "incognito mode" that is used in the W3C specs 16:29:55 (I don't know) 16:30:12 danielappelquist: There is no standard definition of a private browsing mode 16:30:23 ...we wonder whether there should be such a definition 16:30:32 hey wendy - have your group(sP define that for us, would you? 16:30:47 s/\(sP/(s)/ 16:30:57 3.16 Does this specification have a "Security Considerations" and "Privacy Considerations" section? 16:31:01 rrsagent, make minutes 16:31:01 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html ShaneM 16:31:15 AdamR: We think all the docs should have privacy/security considerations sections 16:31:29 ...we do call out that the PMI spec should point to the security section of the URI spec 16:31:39 ...so we need to augment privacy/security sections of the docs larger 16:31:46 TAG open issue on private modes: https://github.com/w3ctag/spec-reviews/issues/101 (just FYI) 16:31:46 3.17 Does this specification allow downgrading default security characteristics? 16:32:17 AdamR: We recommend that there be a bit more prose for web app developers that speak to doing things on an HTTPS URL 16:32:47 NickTR: Can I ask that the task force will work on concrete proposals (issues or PRs) 16:33:01 q? 16:33:42 IJ: I would like to set the expectation we'll have suggestions by 4 August 16:33:48 ack Adr 16:33:48 AdrianHB, you wanted to ask about probing in general 16:34:03 adrianhb: I want to raise the point about probing. 16:34:10 ...it comes up now and again as a kind of sideline topic 16:34:18 ...we often thing of the API as something the site might call once 16:34:29 ...but a site might use the API to farm user information 16:34:45 ...we might want to note in the page we are starting privacy attacks that might be made through the API 16:35:10 ...e.g., submitting payment requests 1 by 1, and the merchant trying things after silent failures to enforce ordering 16:35:14 q 16:35:17 Q? 16:35:19 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 16:35:41 NickTR: We will return to the meeting 8:30am tomorrow 16:36:48 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 17:07:03 Max has joined #wpwg 17:13:50 Max has joined #wpwg 17:20:36 Max has joined #wpwg 17:30:48 Max has joined #wpwg 17:34:27 Max has joined #wpwg 17:40:57 dka has joined #wpwg 17:43:55 yaso_ has joined #wpwg 17:43:55 yaso__ has joined #wpwg 18:04:03 alyver has joined #wpwg 18:21:41 alyver has joined #wpwg 18:37:12 nick has joined #wpwg 19:37:29 fdold has joined #wpwg 19:39:33 dka has joined #wpwg 21:25:25 Max has joined #wpwg 22:14:20 alyver has joined #wpwg 22:19:00 adamR has joined #wpwg 23:32:51 alyver has joined #wpwg 06:47:46 nicktr has joined #wpwg 07:21:19 conorhackett_wp has joined #wpwg 07:33:45 Max has joined #wpwg 07:36:32 nicktr has joined #wpwg 07:38:06 conorhackett_wp has joined #wpwg 07:38:21 zkoch has joined #wpwg 07:38:23 faraz has joined #wpwg 07:38:25 rouslan has joined #wpwg 07:40:43 nick has joined #wpwg 07:42:58 MattS has joined #wpwg 07:43:19 alyver has joined #wpwg 07:44:13 Nicolas_A_ has joined #wpwg 07:45:06 fdold has joined #wpwg 07:46:21 alyver has joined #wpwg 07:47:26 AndreaF has joined #wpwg 07:48:06 pirouz has joined #WPWG 07:48:16 trackbot, start meeting 07:48:18 RRSAgent, make logs public 07:48:20 Zakim, this will be 07:48:20 I don't understand 'this will be', trackbot 07:48:21 Meeting: Web Payments Working Group Teleconference 07:48:21 Date: 08 July 2016 07:48:28 zakim, this meeting spans midnight 07:48:28 I don't understand 'this meeting spans midnight', Ian 07:48:34 zakim, this call spans midnight 07:48:34 I don't understand 'this call spans midnight', Ian 07:48:35 adamR has joined #wpwg 07:48:41 zakim, logs span midnight 07:48:41 I don't understand 'logs span midnight', Ian 07:48:47 zakim, span midnight 07:48:47 I don't understand 'span midnight', Ian 07:49:26 zakim, this meeting spans midnight 07:49:26 I don't understand 'this meeting spans midnight', ShaneM 07:49:41 rrsagent, this meeting spans midnight 07:49:58 rrsagent, make minutes 07:49:58 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html manu 07:50:14 zakim, this meeting spans midnigh 07:50:14 I don't understand 'this meeting spans midnigh', Ian 07:50:15 zakim, this meeting spans midnight 07:50:15 I don't understand 'this meeting spans midnight', Ian 07:50:17 zakim, this meeting spans midnight. 07:50:17 I don't understand 'this meeting spans midnight', Ian 07:50:29 zakim, meeting spans midnight. 07:50:29 I don't understand 'meeting spans midnight', Ian 07:50:30 zakim, meeting spans midnight 07:50:30 I don't understand 'meeting spans midnight', Ian 07:50:42 present+ zkoch 07:51:17 AjayR has joined #wpwg 07:53:04 Laurent_ has joined #wpwg 07:56:38 Max has joined #wpwg 07:58:34 Topic: Introductions and Agenda Bash 07:58:48 https://github.com/w3c/webpayments/wiki/Web-Payments-Working-Group-FTF-Meeting-%28July-2016%29 07:59:08 scribe: Ian 07:59:15 [We review updated agenda] 07:59:22 VincentK has joined #wpwg 07:59:27 present+ MattS 07:59:34 present+ Ian 08:00:36 present+ alyver 08:00:49 present+ VincentKuntz 08:00:50 present+ nick 08:01:17 present+ 08:01:42 jyrossi has joined #wpwg 08:02:19 q? 08:02:56 present+ Manu 08:02:58 present+ ShaneM 08:02:59 present+ nicktr 08:03:02 Roy has joined #wpwg 08:03:05 r+ 08:03:06 present+ AdrianHB 08:03:06 lbolstad has joined #wpwg 08:03:06 present+ conorh_wp 08:03:11 present+ 08:03:12 present+ Rouslan 08:03:15 present+ 08:03:15 present+ Roy 08:03:16 sebsg has joined #wpwg 08:03:19 faraz has joined #wpwg 08:03:20 present+ AndreaF 08:03:29 present+ sebsg 08:03:38 present+ lbolstad 08:03:39 Fawad has joined #wpwg 08:03:57 ben has joined #wpwg 08:04:37 brian_s has joined #WPWG 08:05:04 present+ adamR 08:05:11 +1 08:05:21 present+ Dongwoo 08:05:41 CyrilV has joined #wpwg 08:05:53 present+ Cyril Vignet 08:06:13 Topic: Explainer doc 08:06:14 https://w3c.github.io/webpayments/proposals/wparch/ 08:07:42 note for those that didn't know what a collaboration diagram was from my question in my session yesterday, this is one 08:08:00 MattS: thanks! 08:08:49 q? 08:09:08 q? 08:09:17 note that plantuml DOES have some support for this: http://plantuml.com/component.html 08:09:28 nickTR: I think there is some language alignment that needs to be done. 08:09:38 ...by taking it up as a work item we agree we'll work on it 08:09:48 ..I'd be interested in getting the perspectives from those relatively new to the group 08:09:50 ...was it useful? 08:09:51 q+ 08:10:05 ...for those of us who would be talking to clients, would this be a useful artifact? 08:10:10 ack m 08:10:18 q? 08:10:27 MaheshK has joined #wpwg 08:10:37 Max: Clarification question - payment options/details/methods are shown as "layers" ... is layering intentional? 08:10:46 Manu: No, it was intended as a container 08:10:56 q+ 08:11:01 ...happy to clarify that if desired 08:11:09 ack fdold 08:11:24 Florian: I'm missing here the relationship between the payment request API and the HTTP API 08:11:38 Manu: I don't go into that detail in the diagram 08:11:48 (In figure 3) 08:12:17 ...HTTP API or payment request API can be used to send messages. 08:12:19 q+ to affirm that an intro like this would be helpful for me when promoting our work 08:12:24 ...are you saying you'd rather see it mentioned or not? 08:13:10 ack sh 08:13:10 ShaneM, you wanted to affirm that an intro like this would be helpful for me when promoting our work 08:13:30 ShaneM: I talk about our work a lot; I find this useful. 08:13:31 q? 08:13:47 q? 08:13:48 ...I would like to use it ... but only if blessed by the group 08:13:50 q+ 08:14:06 +1 to ShaneM 08:14:40 q+ to suggest strongly as a NOTE in W3C space 08:15:00 Q? 08:15:05 REQUEST: can we update this https://w3c.github.io/webpayments/ 08:15:23 huwby has joined #wpwg 08:16:01 q? 08:16:08 ack AdrianHB 08:16:19 IJ: I could see this as a Note, or web page, or slide deck 08:16:35 ...also, needs to be summary of what we have done, and not claim to be an architecture. Should reflect what we've done. 08:16:42 AdrianHB: Agree with Ian on that point 08:16:52 ...my concrete proposal is that the WG adopts this as an ED of a Note 08:17:03 PROPOSED: Take up the explainer as an ED of a NOTE 08:17:10 q- 08:17:42 AdrianHB: It's important to change the title to something like "Web Payments Overview" 08:17:55 +1 08:17:56 +1 08:17:56 +1 08:17:57 +1 08:17:58 +1 08:17:58 +1 08:17:59 +1 08:18:01 +1 08:18:01 +1 and I am open to a title 08:18:01 +1 08:18:01 +1 08:18:02 +1 08:18:03 +1 08:18:05 +1 08:18:05 +1 08:18:25 +0 08:18:39 Editors: Nick, Roy, AHB, Manu, Dapeng 08:18:58 [IJ appreciates the content; not 100% sure yet should be a Note hence +0] 08:19:15 topic: Payment Method Identifiers 08:19:49 PMI spec -> https://www.w3.org/TR/payment-method-id/ 08:20:27 AdrianHB: We want effective matching of PMIs so that the user experience is good and people don't find in practice that there is not a match 08:20:47 present+ Nicolas_A 08:20:47 ...so we are looking at augmenting matching to satisfy these use cases: 08:20:59 === 08:21:00 The merchant accepts both Visa Credit and Visa Debit. Merchant wishes to charge a differential price for specific types, most commonly credit vs debit. 08:21:00 BigShop accepts many forms of Visa payment except one sub-brand (due to terms and conditions). Merchant wishes to decline a setoff card sub-types, commonly Corporate and high-value purchasing cards. 08:21:01 === 08:21:02 present+ pirouz 08:21:21 AdrianHB: MattS and Ian and I have been looking at this closely; have contemplated a variety of proposals 08:21:40 ...various proposals involving more computation by the browser, and other options forcing payment apps to do the work 08:22:00 q? 08:22:03 faraz has joined #wpwg 08:22:32 q+ 08:22:45 q+ 08:23:16 q+ to make a further observation 08:23:20 brian_s has joined #WPWG 08:23:38 q+ to comment about “addressing differential pricing” 08:23:42 -1 to needing to support second use case right now 08:23:44 q+ to assert that the current approach supports these use cases and what we're really saying is we want to make this easier for developers. 08:24:01 q? 08:24:27 Issue is that until the card number is entered, you won't know if credit, debit, consumer, commercial... requires a BIN table look-up 08:24:28 q+ 08:25:08 ack Nicolas_A_ 08:25:09 q+ to propose a potential solution 08:25:36 Nicolas_A_: On the use cases, the lines of separation between those cards is not debit/credit...could be consumer/commercial, origin of the card, 08:25:44 q+ 08:25:56 ack Nick 08:26:19 nick: These two use cases aren't quite the same ... the first use case (credit/debit) are two distinct payment instruments 08:26:28 ...they are processed differently... 08:26:41 ...the second use case (accepting cards from a particular country, or a corporate) 08:26:49 ...they are not being processed differently...it's more a property of the card 08:27:08 ...I think Manu is right that today these are supported (via payment method identifiers) 08:27:19 ...we may not know whether a card is corporate / personal 08:27:25 ...I think one is achievable, one is much harder 08:27:32 Q+ Huw 08:27:35 ack AdrianHB 08:27:35 AdrianHB, you wanted to make a further observation 08:28:05 AdrianHB: I wanted to observe that a lot of complexity that we are seeing is specific to cards...none of the other payment methods seem to require the same sort of filtering 08:28:43 ..for that reason, we may not need to come up with a generic solution today; just solve for cards today and then if other payment methods show similar complexity we deal with it as it arises 08:29:03 ...so we may be able to address just cards today and learn for future use cases 08:29:12 AdamR: +1 to supporting differential pricing use case 08:29:47 q? 08:29:50 IJ: Support here means "augmented mediator matching algorithm" 08:29:52 ack AdamR 08:29:52 adamR, you wanted to comment about “addressing differential pricing” 08:30:31 Manu: I think we support this now but it's difficult. The sticking point is how to do this. I like what AHB said about focusing on cards for now. 08:30:42 ...I am wondering whether all that's missing now is a way to say "not" 08:31:04 q+ 08:31:36 q? 08:31:39 ack manu 08:31:39 manu, you wanted to assert that the current approach supports these use cases and what we're really saying is we want to make this easier for developers. and to propose a potential 08:31:42 ... solution 08:31:50 Ian: to have not, you need groups 08:32:19 q? 08:32:29 Manu: You can define the groups in the card specs 08:32:47 ...maybe you can get by with "not" and grouping semantics defined in the spec 08:33:07 IJ: You would need the spec to be able to expand over time to catch all the groups 08:34:09 Zkoch: I agree with Nick that there are two use cases here (1) credit/debit (2) various branding / subclassing 08:34:21 ...I think we should support (1); I am less concerned about (2) 08:34:53 ...payment request may not be able to support all the use cases at the tart 08:34:57 s/tart/start 08:34:58 kriske has joined #wpwg 08:35:02 q? 08:35:04 present+ kriske 08:35:05 ack brian_s 08:35:06 +1 to Zach (and Nick) 08:35:07 ack zkoch 08:35:10 ack Huw 08:35:19 ack nick 08:35:38 Nick: Manu asked if we could do this in the basic card spec...I don't think it works for the spec..it doesn't allow for these fields to be identified. 08:36:09 ...not sure how we would list different charges 08:36:23 ...this comes into play in cases of other payment methods where more information is known up front 08:36:34 ...I think this is going to be needed for tokenized schemes 08:36:43 NickTR: The payment app could be doing that 08:37:11 s/origin of the card,/origin of the card, because regulation in the EU gives right to the merchant to decide to surcharge or to refuse such cards. Therefore it is a must have, not a wish have/ 08:37:29 NickTR: BIN lookups are hard 08:38:03 IJ: how are implementers doing this? 08:38:13 Nick: For apple pay we get additional information from the network 08:38:25 ...we don't get all the information that we've talked about today 08:38:45 q? 08:38:47 ..so we'd have to show the differential prices in brute form, and that list might be lengthy 08:38:53 https://en.wikipedia.org/wiki/Payment_card_number 08:38:59 NickTR: We will have a breakout on this at noon 08:39:31 adrianhb: It sounds like for basic card, as much as we'd like to be able to differentiate on a bunch of dimensions it's not practical due to complexity of analysis. 08:39:44 ...so we might only be able to do rudimentary lookup (e.g., of network) 08:40:10 ...and we can fall back to the existing behavior which is the payment is rejected after some processing 08:40:12 I believe this is the domain of the PSPs/ Processors, not the browser's responsibility... BIN tables have to be constantly kept up to date, and be 100% reliable 08:40:16 …even rudimentary lookup might be wrong. I expect a fair few sites to break when MasterCard moves to the “2” BIN in the fall 08:40:46 NickTR: Some sophisticated pages are doing dynamic lookup 08:40:55 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 08:41:03 Topic: HTTP API/Core messages 08:41:23 https://docs.google.com/presentation/d/1a3oiG8H4DMTwhC37BnkA-1OJ90NB2WcZQb12VphqVOo/edit#slide=id.p 08:41:26 Core messages -> https://w3c.github.io/webpayments-core-messages/ 08:41:34 HTTP API -> https://w3c.github.io/webpayments-http-api/ 08:42:47 Manu: Goal is to get to FPWD, or understand concerns 08:43:16 manu: Purpose of core messages spec is to understand what messages flow through the system 08:43:24 q? 08:43:31 ...payment request API is for interactive payments, HTTP API is for non-interactive payments 08:44:03 ...core messages spec is split in two: general data model; then some different serialization options 08:46:25 q+ 08:48:58 q+ 08:49:18 q? 08:49:25 q+ 08:49:26 q+ to discuss 402 08:49:56 Demo -> * [7 July](https://www.w3.org/2016/07/07-wpwg-minutes) 08:50:14 / 08:50:36 demo -> http://http-mediator-demo.web-payments.io/ 08:50:42 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 08:51:10 Manu: Do we want to publish these documents as FPWDs? 08:51:15 q? 08:51:24 ...one critique of these specs is that they've not had as much attention on them 08:51:37 ...an FPWD does not imply agreement to the content by the WG 08:51:45 ack ni 08:51:50 q+ 08:52:11 nickTR: Who was aware of this spec? 08:52:21 (just about everyone) 08:52:25 NickTR: Who has read it 08:52:27 (fewer people) 08:52:39 NickTR: Who thinks that there are valuable use cases? 08:52:58 (@@ was typing and did not see show of hands for that one@@) 08:53:05 ack kriske 08:53:16 q+ 08:53:34 q+ Faraz 08:53:40 q? 08:54:05 Kriske: How close is message to ISO20022? 08:54:16 Manu: That is a "native payment message" so it would be whatever is called for 08:54:54 Kriske: How will the resource be defined? As an ISO20022 structure? Or something proprietary? 08:55:11 Manu: This diagram is just one example; you can have other flows 08:55:20 ...the question is for steps 9 and 10, who is defining and executing that? 08:55:26 q? 08:55:27 I think 9 and 10 are out of scope for this group 08:55:29 q+ 08:55:40 Manu: I would expect it would be native to whatever payment network it's submitted to 08:55:59 Kriske: The reason I ask is that there are constraints imposed by the payment network 08:56:11 ...if these pieces of information are not properly structured, the payment will fail 08:56:24 ..it would be interesting for this proposal to take into account those requirements 08:56:33 ...ISO20022 has taken that into account 08:56:53 q? 08:57:00 Manu: The assumption here is that the payment method that is used will ensure that it collects the right pieces of information so that when it hits the payment network it is ready to go 08:57:11 ack Laurent 08:57:28 Laurent_: Do you take into account payment method extensibility? 08:57:36 ...also do you have a push model for message 3 and 4? 08:57:52 q- nicktr 08:58:22 Manu: We don't have a push use case and have not focused on it...but we could put it in there. 08:58:40 q? 08:58:45 ...regarding extensibility, we handle it the same way the browser API spec does; there is a catch-all bucket for extra params 08:59:11 Laurent: Do payment methods have to define something beyond what they do today to work with this API? 08:59:16 Manu: By design it should just work 08:59:24 q+ 09:00:03 ack AdrianHB 09:00:03 AdrianHB, you wanted to discuss 402 09:00:04 q- 09:00:12 AdrianHB: I made the comment yesterday that we should pursue payment request API and HTTP API independently and as we see opportunities to align we do that. Is it your expectation that Core messages will be the vehicle for keeping up to date? 09:00:13 Manu: Yes 09:00:21 AdrianHB: The HTTP 402 use case is interesting. 09:00:58 q? 09:01:23 ...we should decide whether we want to use this spec as a way to respond to 402 09:01:37 ...other activity in this space e.g., cryptocurrency folks 09:02:35 Manu: Had some discussion with Mark Nottingham about this...some pushback 09:02:50 q? 09:02:58 ...there would be need for more discussion with IETF 09:03:04 q+ 09:03:08 Max: What is the security mechanism? 09:03:19 Manu: I assume it would be the same as used by the browser; right now seems to be HTTPS 09:03:33 ..the HTTP API is following browser API (currently no signatures) 09:03:42 Max: What payment methods can you use? 09:03:53 Manu: Whatever payment method you want, as defined by the payment method specs 09:04:05 Max: Step #5....select payment app...is that interaction? 09:04:38 Manu: It's meant to be non-interactive...you could imagine some interaction (e.g., from the command line) but in general the HTTP Api is intended for non-interactive use cases...so #5 takes place automatically based on previous configurations 09:04:54 Max: In step #11, what happens if message does not reach the mediator? 09:04:58 Manu: Right now that's out of scope 09:05:13 q? 09:05:17 ...up to mediator...different approaches might be taken 09:05:19 ack max 09:05:26 ...I think that group has this question for the work we are doing 09:05:29 ack faraz 09:05:35 Is it a fair summary that the HTTP API is the same as the PaymentRequest api spec, but where we have truly generalized payment mediator to just anything that can speak HTTP? 09:05:52 yes 09:06:06 faraz: You are saying the HTTP API spec should support payment methods ... how would something like paypal work non-interactively? 09:06:23 Manu: Good point; if the payment method itself does not support automatic payments, then you could not achieve fully automatic payments 09:06:39 faraz: The same applies to entry of PAN 09:06:51 q+ 09:06:52 ....I am hearing you say that unless PAN has been previously entered, this would not work 09:06:54 Manu: Correct 09:07:17 q? 09:07:22 q+ 09:07:24 NickTR: PISPs in europe are leading us toward APIs for initiation of payment...you will be able to store credentials to allow transactions to be initiated 09:07:34 q? 09:07:50 q+ to point out that there is an opportunity to use this even in a paypal model via "subscriptions" 09:07:52 ian: what is the current state of implementor interest? 09:08:13 q+ 09:08:24 manu: I can't talk abotu some implementors (we are under NDA) but I hope that if we put this out to FPWD I hope they will come forward 09:08:38 nicktr: WorldPay are working on this in our IoT architecture 09:08:40 q? 09:08:43 ack Ian 09:08:44 ack Max 09:08:51 Support for Tokenisation plus trid in core messages 09:09:05 Max: For the paypal use case, in this diagram I think the payee and the payment network are together 09:09:18 ...so the message #3 and #4 will be very payment method specific 09:10:14 ...3 and 4 may not be able to be simple HTTP POST...might require some additional parameters (e.g., credentials) 09:10:17 q- 09:10:42 NickTR: Note that 3 and 4 is simply the creation of the payment request...the problem with the diagram in the spec is that it just represents pull payments 09:11:55 [AHB shows a push payment variation via the screen] 09:11:59 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 09:11:59 nick has joined #wpwg 09:12:06 q? 09:12:10 ack shane 09:12:10 ShaneM, you wanted to point out that there is an opportunity to use this even in a paypal model via "subscriptions" 09:12:13 zakim, close the queue 09:12:13 ok, Ian, the speaker queue is closed 09:12:20 ack faraz 09:13:01 faraz: The diagram shows a tokenized response...I wanted to raise a point that the diagram as shown today does not support tokenization... 09:13:07 Manu: That's an aspiration; not enforced by the spec 09:13:08 q? 09:13:11 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 09:14:50 [Review of process] 09:14:56 ian: to go to FPWD we trigger a formal patent policy process. Because it will become listed in a more formal register of docs it will have more links to it. There are some procedural issues the WG must follow to publish. 09:14:59 q+ 09:15:21 zakim, open the queue 09:15:21 ok, AdrianHB, the speaker queue is open 09:16:53 ian: I want to talk about relative priority of this vs other work. We have agreed that the priority of this sits below Payment Request and Payment App. Given the implementation state I want to make sure, even though this is in scope we need to make sure we do still assign our time appropriately 09:17:12 zakim, open the queue 09:17:12 ok, Ian, the speaker queue is open 09:17:25 NickTR: Show of hands whether you would likely be supportive of a call for consensus 09:17:36 +1 09:17:36 (Which will happen formally with a 1-week window) 09:17:39 +1 09:17:42 +0 09:17:42 +1 09:17:43 +1 and agree that the chairs need to manage priorities 09:17:45 +1 09:17:45 +1 09:17:46 +1 09:17:46 +0 09:17:49 +1 to issue call for consensus on HTTP API and Core Messages 09:17:50 0, still working to understand how it fits in 09:17:57 +0 09:17:58 +0 does not seem to affect browsers 09:17:58 +1 09:18:03 +0 09:18:07 +1 09:18:07 (No +1's or -1's by hand in the room) 09:18:17 +0 09:18:34 +1 09:18:36 +0 09:18:39 Yes, useful to clarify push payments too 09:18:41 AdrianHB: I am hearing there is a desire for more clarity around push payments, and also a fix to the tokenization ambiguity 09:18:45 +0 09:18:47 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 09:18:52 +1 09:19:05 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 09:21:11 Nicolas_A_ has joined #wpwg 09:24:26 Could we please clarify the breakouts? Seems you have combined a few? 09:26:13 alyver has joined #wpwg 09:32:25 adamR has joined #wpwg 09:34:37 sebsg has joined #wpwg 09:39:40 MaheshK has joined #wpwg 09:46:33 nick has joined #wpwg 09:46:41 faraz has joined #wpwg 09:56:53 alyver has joined #wpwg 10:02:42 AdrianHB: does this address your push concern? https://w3c.github.io/webpayments-http-api/#h-issue10 10:04:41 shanem - I think we should show a push flow. The current use case flow is being interpreted as the overall flow 10:05:13 AdrianHB: I agree - I just wanted to capture the issue for now. 10:05:28 works for me 10:05:57 Max has joined #wpwg 10:07:51 (I will go off and try to draw a pretty picture - or invite Max to help!) 10:08:42 Glad to help. 10:09:04 Could you please add the link to the photo here? Thanks :) 10:09:51 +1 for photo 10:10:18 MattS has joined #wpwg 10:12:54 scribenick: nicktr 10:12:57 zkoch has joined #wpwg 10:13:03 ben has joined #wpwg 10:13:14 CyrilV has joined #wpwg 10:13:24 subject: Testing strategy 10:13:30 present+ Cyril_Vignet 10:13:43 shaneM: we're writing tests that should run 'forever' 10:14:13 ...CR means we have to show our specification can run in at least two implementations 10:14:33 ...payment request API is important as it has the momentum 10:15:06 ...core messages and vocabulary 10:15:12 ...HTTP API 10:15:21 ...app registration 10:15:43 ShaneM: introducing web platform tests framework 10:16:01 ...one of the nice bits is automated reporting 10:16:35 ...but I need help to develop a stubbed payment applicatoin 10:16:40 ...so that we can test flows 10:17:26 ...the way to do this is -manual.html files which are automatable via webdriver 10:18:01 ...for the .js api 10:18:10 q? 10:18:20 q+ 10:18:27 ...HTTP API is easily automatable 10:18:29 scribenick: adrianhb 10:18:47 shanem: The WPT framework is very customizable 10:19:15 ... allows backend comms to check message integrity 10:19:32 [talking through helpful diagram] 10:19:58 ... automateable through Selenium or Webdriver 10:20:11 ack Max 10:20:25 ... we should right enough to get good coverage but not too many so that its onerous to maintain 10:21:06 max: we are working on testing. In the CG we are trying to add the concept of API versioning. Is that a feature we are interested in? 10:21:18 https://www.w3.org/community/awpat/ 10:21:24 Advancing Web Platform Application Testing Community Group 10:21:31 shanem: yes, would great 10:21:44 [What is WPT] 10:21:57 ... really is simple 10:22:10 ... built in support for taking in WebIDL and test interfaces 10:22:40 q? 10:22:41 q+ 10:22:42 ADVANCING WEB PLATFORM APPLICATION TESTING COMMUNITY GROUP 10:22:44 ... WPT has recently been extended to support testing JSON messaging which we need 10:22:51 https://www.w3.org/community/awpat/ 10:22:53 [The Plan] 10:23:13 -> http://github.adrianba.net/paymentrequest-demo/tests/payment-tests.html Example of testharness.js tests 10:23:19 shanem: ceating the buckets that the tests will go into (a framework) 10:23:35 ... need help developing a skeleton payment app 10:24:06 q- 10:24:12 ... longer term we will work app and API devs to ensure the tests are ready when we get tp CR 10:24:30 [What does test look like?] 10:25:13 ... tests should have clear explanations 10:25:23 [What does a test look like (2)] 10:25:33 ... shows javascript behind test 10:25:41 ... this example shows an async test 10:26:02 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 10:26:08 ... test calls done() when it's finished 10:26:25 ... lots of primitives for us to use 10:27:00 [What does running a test look like?] 10:27:20 [Shane demos a test] 10:27:43 agenda? 10:27:50 zakim, clear agenda 10:27:50 agenda cleared 10:29:23 shanem: there is a PR to add more output meta-data 10:29:35 [What does a report look like?] 10:29:39 [link to report] 10:30:30 ... for each test there are sub tests which show sub test results from each tested implementation 10:30:48 ... this is pushed up by the implementors (presumeably from their CI) 10:30:51 Roy has joined #wpwg 10:30:55 q? 10:31:04 ... we need 2 passing implementations to get to CR 10:31:38 [What do I need from you?] 10:31:53 ... stable spec means less changes to tests 10:32:03 ... need peer reviews of tests 10:32:20 nicktr: analogous to a spec editor? 10:32:21 q+ 10:32:41 shanem: no, it's enough to understand the test (i.e. not just being an editor) 10:33:08 ... my job is manage the infrastructure. I hope we get volunteers to write tests 10:33:12 q? 10:33:37 q+ to ask how we tie in different merchant and payment app servers? 10:33:41 max: I volunteer to review tests! 10:33:47 [loud applause] 10:33:58 rouslan has joined #wpwg 10:34:13 nicktr: I suspect that testing needs some people on the ground to do work, are there any other volunteers? 10:34:32 manu: DigitalBazaar will provide some resources 10:34:54 zkoch: we already have some tests in Chromium. We'll port them over 10:35:03 roy: We will also help review 10:35:30 shanem: after we have finalised payment apps we'll have a better idea of what to test 10:35:49 ... if there isn't wide support for payment apps then this architecture obviously won't work 10:36:09 ... if that's not true I'd appreciate help on correcting my assumptions 10:36:15 q? 10:36:18 nicktr: thanks Shanem 10:36:22 ack max 10:36:24 ack max 10:37:19 manu: general question. It looks like we have a number of conforming systems to test (app, mediator, etc) Do we plan to allow testing of all systems? 10:37:41 link to this presentation: -> https://docs.google.com/presentation/d/1zxqJfXcJR6hH74wYlBTzwNMSoQFUFYmqqeKlFec4LNM/pub?start=false&loop=false&delayms=3000&slide=id.g1156a10a0d_0_107 10:37:52 shanem: we are testing the interfaces we standardize. How we do this is interesting 10:38:11 today's agenda -> https://github.com/w3c/webpayments/wiki/Proposed-F2F-Day-2-agenda 10:38:36 ... some systems in this architecture have non-standard interfaces so we'd not expect to test those interfaces but we could include these in end-to-end tests 10:38:55 q? 10:38:56 q? 10:39:00 ack manu 10:39:00 manu, you wanted to ask how we tie in different merchant and payment app servers? 10:39:00 ack MaheshK 10:39:25 fdold has joined #wpwg 10:41:09 faraz has joined #wpwg 10:43:33 q+ to note that failure during pull payment is still bad. 10:44:05 MattS has joined #wpwg 10:44:20 q+ 10:44:45 lbolstad has joined #wpwg 10:44:50 present+ lbolstad 10:44:52 q+ 10:45:00 Discussion of -> https://github.com/w3c/browser-payment-api/issues/224 10:45:16 scribe: Ian 10:45:30 +1 on a correlation id 10:45:33 Roy: You can solve this on a per payment app basis, but the additional complexity from the merchant perspective 10:45:54 ...I hope a driver of adoption is that I can do a small number of integrations and let apps evolve without a lot more integration 10:46:12 ..if we have no structure around this, we will end up with one implementation by the merchant per payment app and that's not ideal 10:46:19 q 10:46:20 q/ 10:46:24 ack z 10:46:27 ack manu 10:46:27 manu, you wanted to note that failure during pull payment is still bad. 10:46:58 zkoch: We run into a problem that once you've handed control to the payment app , you don't have a consistent channel for handling this...that complicates implementation (e.g., on mobile platforms) 10:47:18 q+ 10:47:27 ...I think payment request API is to help with UX and bring new payment methods to the web. 10:47:33 ...it is the channel for more secure payment methods 10:47:46 ...but it's not been the case that this would mean there's no backend integration 10:48:04 ...I understand your point about easier merchant integration, but I don't think we'll see that quickly 10:48:22 ...I think the architectural limitation is something we need to consider if we were to adopt something like this 10:48:24 q? 10:48:28 Max: I support this idea. 10:48:29 ack Max 10:48:30 ack Max 10:48:38 q+ to get some clarity on the value of a generic push payment method 10:48:44 Max: This is an interesting problem and I think the WG should spend time thinking about it. 10:48:55 ..I'm happy to work with Roy on this 10:48:59 ack L 10:48:59 Max has joined #wpwg 10:49:09 Laurent: In the SEPA payment method, we identified the same issue 10:49:31 ...we were leaning toward a slightly different solution...to use an out-of-band HTTP callback (identified via a URL in the payment request) 10:49:47 ...this allows the server or payment app to provide confirmation to the merchant directly 10:50:15 Roy: That could work too. Mainly what I am looking for is something in the spec instead of proprietary solutions in each app 10:50:16 q? 10:50:19 ack AdrianHB 10:50:19 AdrianHB, you wanted to get some clarity on the value of a generic push payment method 10:51:02 adrianhb: The idea of a generic push payment spec that could be used by multiple third-party payments (e.g., Alipay) where the app (or server) processes the payment....it sounds like a good idea but I haven't figured out whether it would be useful. 10:51:19 ...if we decide there's a common way to do this (e.g., callback, signature, transaction id) 10:51:31 ...what value is there in these payment methods sharing a common payment method identifier. 10:51:47 q+ to say they don't need to share an identifier - there is benefit in sharing the mechanism and spec'ing that out. 10:52:11 ack manu 10:52:11 manu, you wanted to say they don't need to share an identifier - there is benefit in sharing the mechanism and spec'ing that out. 10:52:33 AdrianHB: Should this be "best practice" or in the spec? 10:52:44 NickTR: We could learn from specific instances 10:52:56 AdrianHB: But it doesn't solve the problem of "one payment method per payment app" that Roy raised 10:53:04 Manu: I think there's an incremental step we could take. 10:53:21 +1 to not sharing the identifier but standardizing the mecahnism 10:53:33 ...I think there's value in standardizing the mechanism...e.g., best practice 10:55:00 faraz has joined #wpwg 10:55:01 q+ 10:55:01 ...spec it out "If you want to verify the payment went through, do this" 10:55:11 AdrianHB: So that does not solve the fragmentation issue 10:55:12 q+ 10:55:14 Manu: That's ok (for now) 10:55:48 q+ to mention open schemes 10:55:55 porouz has joined #WPWG 10:56:03 q+ to mention that you could do both, see what the market decides 10:56:07 q- 10:56:07 zakim, close the queue 10:56:09 ok, Ian, the speaker queue is closed 10:56:12 ack faraz 10:56:45 Lauren_Jones has joined #wpwg 10:56:46 Faraz: I want to echo what Manu said..instead of creating a generic spec or collecting various payment methods...I think a concrete example is better. 10:56:55 ..make it a non-mandatory guidance 10:56:59 q? 10:57:09 ...or any status information... 10:57:11 ack L 10:57:16 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 10:57:37 Laurent: The problem is not so much fragmentation on the payment app side, the problem is integration cost for merchant 10:57:55 ...so you help the merchant if you provide a generic way to handle the response 10:58:14 ack AdrianHB 10:58:14 AdrianHB, you wanted to mention open schemes 10:58:35 adrianhb: I think what's great about this conversation is that it's crystalized some water cooler discussion 10:58:58 ...we've treated payment methods as "universal" to date but we recognize that there are also 1-1 mapping of payment method to payment app 10:59:17 ...compare those with the "open" payment schemes, where there are standards that enable anyone to write a payment app 10:59:35 q? 10:59:38 ...I think that one of the things that might have spurred this is the cryptocurrency world...there will be a bunch of payment apps 10:59:54 ..there is an incentive to create a standard to be able to do bitcoin payments from a variety of apps 11:00:03 ...I think the bottom line is that we support both of these use cases 11:00:12 ...that is "open" and "proprietary" payment methods 11:01:05 ...this connects to the comment zach made yesterday about user protection ... and whether we provide a way for browsers to protect users against apps from non-mandated distributors 11:01:08 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 11:01:29 [Break] 11:03:56 alyver has joined #wpwg 11:04:59 adamR has joined #wpwg 11:10:49 Max has joined #wpwg 11:11:16 alyver has joined #wpwg 11:14:41 alyver has joined #wpwg 11:30:28 alyver has joined #wpwg 12:14:12 alyver has joined #wpwg 13:00:50 zkoch has joined #wpwg 13:01:13 lbolstad has joined #wpwg 13:01:23 present+ lbolstad 13:02:27 conorhackett_wp has joined #wpwg 13:03:34 fdold has joined #wpwg 13:03:43 adamR has joined #wpwg 13:03:51 nick has joined #wpwg 13:04:45 Max has joined #wpwg 13:06:25 ben has joined #wpwg 13:06:38 Roy has joined #wpwg 13:08:13 nick has joined #wpwg 13:09:55 MattS has joined #wpwg 13:10:03 faraz has joined #wpwg 13:10:32 nicktr has joined #wpwg 13:10:46 Topic: Breakout Review 13:10:52 scribe: manu 13:11:46 CyrilV has joined #wpwg 13:11:56 AdrianHB: We redid how apps initiate payment - add listeners, receive payment request, we're going away from HTTP-based invocation. We will probably use postMessage-like mechanism to POST back to browser. 13:12:01 brian_s has joined #WPWG 13:12:57 q+ 13:13:03 AdrianHB: Within Javascript you can achieve most anything else - what we didn't answer, what happens when Javascript is not downloadable at the time that PaymentRequest is made. We may not specify that, but we didn't actually get into discussing that. That's invocation. 13:13:05 zakim, open the queue 13:13:05 ok, Ian, the speaker queue is open 13:13:20 Ian: Why give a link to Javascript instead of Javascript? 13:13:26 alyver has joined #wpwg 13:13:45 conference call is now open 13:14:04 pirouz has joined #WPWG 13:14:04 international calling numbers can all be found here -> https://github.com/w3c/webpayments/wiki/Proposed-F2F-Day-2-agenda 13:14:21 sorry - wrong paste buffer 13:14:22 AdamR: WebRTC is a derived URI - use the domain portion to form a URL on a .well-known path - it's not exactly the same thing, you're not literally passing the javascript. 13:14:51 AjayR has joined #wpwg 13:15:09 international calling numbers can all be found here -> https://www-emea.intercallonline.com/listNumbersByCode.action?confCode=875114&area=viewNumber 13:15:18 AdrianHB: We had another discussion around display options - current proposal talks about what payment apps support without enrollment, already have ability to process payment w/o enrollment. 13:15:19 conference number is 875114 13:15:42 q+ 13:16:03 AdrianHB: Designed to be able to prompt user to provide cards that may be enrolled. We decided to split between "active payment methods" and "enrollable payment methods" 13:17:38 AdrianHB: If browser knows that you have an enrollable payment method, it could provide it as an option. If user has to go through enrollment flow - merchant can decide to not give customer the option. 13:17:40 ack Ian 13:18:52 Ian: We should consider all these states together: (1) ready to use (2) installed but needs credentials (3) not yet installed 13:18:52 agenda -> https://github.com/w3c/webpayments/wiki/Proposed-F2F-Day-2-agenda 13:18:57 Ian: It may be worth considerting 3 states of payment app - ready to use, ready to add credentials to, ready to be installed. If site says "I take PayPal", and browser knows that payment app could enroll. 13:19:19 s/enroll./enroll, then PayPal could be enrolled./ 13:19:44 AdrianHB: Proposal is for group to take this up - proposal for payment apps API in browser 13:20:12 AdrianHB: The spec will be adopted as an editor's draft in its current form, with issues and new editors added. 13:20:16 Editors to add: Lauren, Ian 13:20:36 PROPOSED: Take up the payment app spec as a WG deliverable (with current editors + Laurent + Ian) 13:20:42 +1 13:20:44 +1 13:20:45 +1 13:20:49 +1 13:20:49 +1 13:20:52 +1 13:20:53 +1 13:20:54 +1 13:20:54 +1 13:20:54 +1 13:20:56 Laurent_ has joined #wpwg 13:20:56 +1 13:20:59 +1 13:21:01 +1 13:21:05 +…0 13:21:07 (No signs of hand in the room; just IRC +1s) 13:21:16 +1 13:21:22 kriske has joined #wpwg 13:21:31 Topic: Payment Method Identifiers Breakout 13:21:35 present+ kriske 13:21:49 jyrossi has joined #wpwg 13:21:55 present+ Cyril_Vignet 13:21:59 present+ jyrossi 13:22:51 Ian: There is more work to do, problem statement was trying to accommodate things like differential pricing, payment method identifiers. The sense from the ad-hoc conversation was that it is going to be important to provide constraints, strong agreement wrt. credit/debit switch - clear agreement on that one, figuring out how to express those so that browser can take into account what merchant says they accept. 13:23:24 Ian: How can payment apps express those things on their end, there are more conversations that need to happen. A second piece was a deeper problem of merchant adoption of the API. 13:23:56 adamR_ has joined #wpwg 13:24:21 Ian: For some payment methods, merchants know enough about the PayPal experience to trust passing off the experience to that third party. it's possible to have an open ended ecosystem of apps that provide responses for a given payment method and that may raise trust issues for merchants. That may lead to bad experiences or conversation problems. 13:24:48 AndreaF_ has joined #wpwg 13:25:26 Ian: One thought, in the same way that merchants could express what they like as payment apps, those preferences could take that into account as well. if Merchant says "I will take the Wells Fargo payment app" 13:25:54 Ian: The more complex the constraint algorithm and ecosystem, the harder time apps will have to be able to do that well. 13:27:05 Ian: Concretely, what would need to happen in the PaymentRequest API to have a constraint-based mechanism. I would assume people that have been working on this - people will meet to work on this. 13:27:31 NickTR: Aggregated payment session - good robust conversation. 13:28:34 NickTR: When we took a step back, we came to an insight on 3 pieces of information: scheme identifier, payer identifier, payee identifier. Why is it possible to do cards, but not possible to do push as generic payment methods. Fundamentally, there is a controlling organization for the payer identifier - it's ISO - they give out BINs, BIN controllers can issue identifiers in those namespaces 13:29:57 NickTR: What happens when things break? What's the behavior, whose left holding the problem? Where does the problem lay when things break. Cross product of apps and methods - how do you solve for that - how do you know if app can support the method - multiiple apps to support. The only way you can initiate a PayPal payment without going through a PayPal app. You can initiatie a Visa payment through a multitude of apps. 13:32:04 NickTR: It took us a long bit of time to synthesize those items - we were wondering about best practice - how to form payment method specifications - write something generic or abstract like cards - and when are we going to need specific instances - good news is that we have good volunteers to work on this. Define some things that need to be there, for example, you could build Visa payment method w/ cards interface. You could do it that way, or you could do it con 13:32:04 crete implementations - actually implement basic card as a spec, then apply restrictions - covers a multitude of specific payment methods. 13:33:01 NickTR: All of these are legitimate approaches, what are the pros and cons - we need to be able to bootstrap this ecosystem - describe an interface for multiwallets - but you'd never be able to send 3rd party payment wallet to something else - we need pros and cons and then try to get guidance on when to use those things. 13:33:48 AdrianHB: We have a good chunk of volunteers for this work - don't know if this is orthogonal to payment identifiers - we're sort of circleing around the same sort of issues. 13:34:13 jiajia has joined #wpwg 13:34:45 Ian: My sense is that they're mostly orthogonal, if we want to establish best practice - if there are cases we want to solve real fast right now. Since we've identified a weird problem, we don't need to work on best practices for those. 13:35:02 q? 13:35:04 Ian: There had to do with payment app identification - don't know if that's a best practice thing. 13:35:29 NickTR: We have a coalition of the willing to work on these items right now. 13:35:40 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 13:36:39 Ian: My expectation on payment method identifiers, we'll try to work with everyone to figure out what this would look like practically speaking - with Microsoft, Google, and Apple. 13:36:47 q+ 13:36:54 Adrianba: Our conversation was broader than this - had to do with how to converge. 13:36:56 Coalition of the willing on that payment methods "best practice" task force included Dapeng, Lauren, Nick TR, Matt S, Faraz, Jean-Yves 13:37:11 q? 13:37:15 ack MattS 13:37:17 q+ 13:37:31 q+ 13:37:37 MattS: I'm wondering, since we're trying to solve the same problem here - two groups - how to serve the long term and how to serve the short term. I'm concerned that we have a large group and it'll be hard to make progress. 13:37:41 q+ to suggest concrete progress for cards 13:37:47 ack nick 13:38:19 Lauren_Jones has joined #wpwg 13:38:25 NickS: One of the concerns that we had was that we could come up with a short term approach that's not sustainable for long term - we want to be able to share payment method descriptions between types - I wan't to find a singular approach that works for everyone (as hard as that might be) 13:38:48 ack jyrossi 13:39:45 JeanYves: I don't understand - if we need a best practice, I don't see why it's orthogonal - if we need to be involved in this process, why exclude us? 13:40:22 NickTR: There is plenty of opportunity for collaboration - anyone is welcome to collaborate with this work. 13:40:24 q? 13:41:00 ack AdrianHB 13:41:00 AdrianHB, you wanted to suggest concrete progress for cards 13:41:19 q+ 13:41:29 AdrianHB: That we're cirleing the issue of PMIs, we don't have a mechanism that is acceptable for everyone. Are we saying that this is not how we want to proceed - he thinks we need to have a single method for card. 13:41:47 q+ 13:41:57 AdrianHB: I'd like some clarity on whether or not the group agrees with the current direction. 13:42:01 q+ 13:42:03 ack MattS 13:42:25 MattS: I don't think what we have is sufficient at the moment - we had a number of ideas on the table, specs are in conflict with each other. 13:43:17 Ian: We've looked at different ways to modify those ways, but we have not put a final proposal to the group - when we put it forward to the group, we were asked to work on it more. We haven't come up with the right set of changes to make everyone happy with that. 13:43:36 AdrianHB: We can't progress, this is a blocking issue. 13:43:45 q+ to understand why this is a "blocking issue" 13:44:37 CyrilV: We need a payment method identifier that works for SCT, Bitcoin, etc. 13:44:38 q+ 13:44:40 ack CyrilV 13:44:41 ack Cyr 13:44:45 q+ to ask that we keep testability in mind when designing this scheme 13:45:00 NickTR: We're not just talking about cards. 13:45:49 zkoch: When we talked about implementation difficulties - we have hard coded strings, we have visa / mastercard - From where we're at, how we'll identify payment methods is the biggest issue. I think we have some thoughts on paper - this is the last blocking issue. 13:46:50 AdrianHB: The people that have been tasked by the group to solve this are not the implementers, we need both involved. 13:46:56 zkoch: That's not being proposed 13:47:09 q- 13:47:25 ? 13:47:25 ack zk 13:47:27 +1 let's do this together as a priority 13:47:33 q- 13:47:34 ack S 13:47:34 ShaneM, you wanted to ask that we keep testability in mind when designing this scheme 13:48:09 ShaneM: There are a couple of things you're looking at - keep testability in mind when doing it - if it becomes difficult to filter, it's going to be hard to test to be sure it works if it's really complex. 13:48:49 NickTR: I'm hearing Payment Method Identifiers - that's the main blocker for implementation - we could spend half an hour to do it. 13:49:23 AdrianHB: Let's try to create a concrete proposal for PMIs? It's also late in the day - if we want to delay, that's fine. 13:49:31 Let's do it! 13:49:52 Beer! 13:49:54 I mean...PMI 13:52:28 Manu: Why can't you just do negation? 13:52:39 Ian: You can't do differential pricing with just negation. 13:52:47 brian_s has joined #wpwg 13:52:52 Manu: Yes, you need two things... negation and ... *cliffhanger!* 13:53:35 I would like to understand if people have issues against PaymentRequest API that are not filed but they think need to be resolved prior to CR 13:53:46 Ian: For tokenized card spec, nick, faraz, and laurent. 13:54:02 adrianba, yes 13:54:16 adrianba - there are some questions about arguments, core messages, etc. 14:07:27 rrsagent, make minutes 14:07:27 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 14:07:30 rrsagent, set logs public 14:08:49 alyver has joined #wpwg 14:10:09 zakim, this log spans midnight 14:10:09 I don't understand 'this log spans midnight', Ian 14:10:12 zakim, this log spans midnight. 14:10:12 I don't understand 'this log spans midnight', Ian 14:10:16 zakim, this spans midnight. 14:10:16 I don't understand 'this spans midnight', Ian 14:10:23 rrsagent, this log spans midnight. 14:10:23 I'm logging. I don't understand 'this log spans midnight.', Ian. Try /msg RRSAgent help 14:10:24 rrsagent, this log spans midnight 14:10:24 I'm logging. I don't understand 'this log spans midnight', Ian. Try /msg RRSAgent help 14:10:58 rrsagent, this meeting spans midnight 14:11:05 rrsagent, make minutes 14:11:05 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 14:11:11 rrsagent, set logs public 14:12:05 alyver has joined #wpwg 14:12:16 rrsagent, make minutes 14:12:16 I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian 14:12:34 nick has joined #wpwg 14:13:26 alyver has joined #wpwg 14:19:37 rouslan has joined #wpwg 14:24:28 alyver has joined #wpwg 14:24:37 Max has joined #wpwg 14:25:45 rrsagent, bye 14:25:45 I see 7 open action items saved in http://www.w3.org/2016/07/07-wpwg-actions.rdf : 14:25:45 ACTION: AdamR to work on concrete spec language around currency codes [1] 14:25:45 recorded in http://www.w3.org/2016/07/07-wpwg-irc#T11-54-55 14:25:45 ACTION: Max to work with Ian on starting some payment method good practice documentation. [2] 14:25:45 recorded in http://www.w3.org/2016/07/07-wpwg-irc#T15-13-41 14:25:45 ACTION: Ian to work with AdamR and Jonny on raising an issue about privacy notifications about sharing identifiable information [3] 14:25:45 recorded in http://www.w3.org/2016/07/07-wpwg-irc#T16-11-28 14:25:45 ACTION: NickTR to try to get a security review organized within Worldpay [4] 14:25:45 recorded in http://www.w3.org/2016/07/07-wpwg-irc#T16-18-20 14:25:45 ACTION: Huw to try to get a security review within Amex [5] 14:25:45 recorded in http://www.w3.org/2016/07/07-wpwg-irc#T16-18-29 14:25:45 ACTION: Cyril to try to get a security review within BPCE [6] 14:25:45 recorded in http://www.w3.org/2016/07/07-wpwg-irc#T16-18-44 14:25:45 ACTION: AdrianHB to create a resource that speaks to security topics [7] 14:25:45 recorded in http://www.w3.org/2016/07/07-wpwg-irc#T16-21-25 14:25:47 zakim, bye 14:25:47 leaving. As of this point the attendees have been Cyril, Vignet, ShaneM, nicktr, zkoch, AdrianHB, brianSullivan, Ian, LarsErikBolstad, MattSaxon, Rouslan, Nicolas_A_, lbolstad, 14:25:47 Zakim has left #wpwg 14:25:50 ... joshua, kriske, VincentK, Brian_Sullivan, Charlie-Craven, BenSmith, Andrea, Dapeng, jiajia, SimonScorer, KrisKetels, VincentKuntz, Manu, Faraz, CyrilVignet, NichlasAncot, 14:25:50 ... Jean-Yves, zach, Sebastien, Dongwoo, LaurentCastillo, LaurentJones, Florian, NickS, Roy, Ade, Connor, AdamR, Farad, AHB, Ajay, DanAppelquist, DavidBirch, wseltzer, alyver, 14:25:50 ... nick, conorh_wp, AndreaF, sebsg, pirouz, Cyril_Vignet, …0, jyrossi 14:25:54 adamR has joined #wpwg