IRC log of wpwg on 2016-07-07

Timestamps are in UTC.

07:32:06 [RRSAgent]
RRSAgent has joined #wpwg
07:32:06 [RRSAgent]
logging to http://www.w3.org/2016/07/07-wpwg-irc
07:32:10 [Zakim]
Zakim has joined #wpwg
07:32:40 [manu]
rrsagent, meeting goes beyond midnight
07:32:40 [RRSAgent]
I'm logging. I don't understand 'meeting goes beyond midnight', manu. Try /msg RRSAgent help
07:32:59 [manu]
rrsagent, make minutes
07:32:59 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html manu
07:33:25 [manu]
rrsagent, make logs member
07:33:33 [CyrilV]
CyrilV has joined #wpwg
07:33:58 [manu]
Meeting: July 2016 Web Payments Working Group Face-to-Face Meeting
07:34:02 [manu]
rrsagent, make minutes
07:34:02 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html manu
07:34:36 [CyrilV]
Present+ Cyril Vignet
07:34:42 [ShaneM]
Present+ ShaneM
07:34:48 [manu]
s/Cyril Vignet/Cyril_Vignet/
07:34:51 [manu]
rrsagent, make minutes
07:34:51 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html manu
07:41:23 [Ian]
rrsagent, pointer?
07:41:23 [RRSAgent]
See http://www.w3.org/2016/07/07-wpwg-irc#T07-41-23
07:42:09 [manu]
rrsagent, this meeting spans midnight
07:45:49 [nicktr]
nicktr has joined #wpwg
07:45:54 [nicktr]
present+ nicktr
07:46:45 [brian_s]
brian_s has joined #WPWG
07:47:02 [manu-backup]
manu-backup has joined #wpwg
07:47:16 [MattS]
MattS has joined #wpwg
07:47:38 [manu]
Agenda: https://github.com/w3c/webpayments/wiki/Web-Payments-Working-Group-FTF-Meeting-%28July-2016%29
07:47:57 [manu]
Agenda: https://github.com/w3c/webpayments/wiki/Web-Payments-Working-Group-FTF-Meeting-%28July-2016%29
07:48:19 [zkoch]
zkoch has joined #wpwg
07:48:49 [lbolstad]
lbolstad has joined #WPWG
07:49:19 [sebsg]
sebsg has joined #wpwg
07:49:20 [zkoch]
present+ zkoch
07:49:31 [rouslan]
rouslan has joined #wpwg
07:49:57 [pirouz]
pirouz has joined #WPWG
07:50:42 [AdrianHB]
present+ AdrianHB
07:51:23 [rouslan]
rouslan has joined #wpwg
07:51:43 [manu]
present+ AdrianHB, brianSullivan, Ian, LarsErikBolstad, MattSaxon, Rouslan
07:52:10 [Nicolas_A_]
Nicolas_A_ has joined #wpwg
07:52:38 [Nicolas_A_]
present+ Nicolas_A_
07:52:59 [lbolstad]
present+ lbolstad
07:53:15 [jyr]
jyr has joined #wpwg
07:53:59 [joshua]
present+ joshua
07:54:03 [nick]
nick has joined #wpwg
07:55:28 [Ian]
Topic: Introducitons
07:55:32 [pirouz]
pirouz has joined #WPWG
07:55:36 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
07:55:45 [Ian]
Nick: Welcome!
07:55:56 [Ian]
present+
07:56:12 [manu]
scribe: manu
07:56:22 [MattS]
present+ MattS
07:56:29 [manu]
Topic: Introductions and Meeting Administrivia
07:56:31 [Roy]
Roy has joined #wpwg
07:56:40 [alyver]
alyver has joined #wpwg
07:56:42 [conorhackett_wp_]
conorhackett_wp_ has joined #wpwg
07:56:52 [manu]
nicktr: Welcome to all, we have some administrative stuff to go over first.
07:57:09 [fdold]
fdold has joined #wpwg
07:57:16 [manu]
nicktr: IRC channel is #wpwg, WiFi is on the board at the front of the room.
07:57:19 [kriske]
kriske has joined #wpwg
07:57:25 [kriske]
present+ kriske
07:57:37 [Ian]
agenda: https://github.com/w3c/webpayments/wiki/Web-Payments-Working-Group-FTF-Meeting-(July-2016)
07:57:55 [ben]
ben has joined #wpwg
07:58:03 [manu]
nicktr goes over other administrative items - talking, queue, github
07:58:19 [Andymills80]
Andymills80 has joined #wpwg
07:58:51 [VincentK]
VincentK has joined #wpwg
07:58:55 [manu]
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]
Lauren_Jones has joined #wpwg
07:59:16 [manu]
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 [VincentK]
present+
07:59:49 [maheshkk]
maheshkk has joined #wpwg
07:59:53 [charlie_craven]
charlie_craven has joined #wpwg
08:00:03 [manu]
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 [manu]
BrianS: Please object if you hear anything that sounds like sharing of competitive or commercially sensitive information.
08:00:50 [brian_s]
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 [manu]
Ian: If you wish to keep something off of the public record, please say "don't minute this"
08:01:14 [Ian]
present+ Brian_Sullivan
08:01:30 [Ian]
Huw_bailey
08:01:40 [Ian]
present+ Charlie-Craven
08:01:44 [Ian]
present+ BenSmith
08:01:49 [brian_s]
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 [Ian]
present+ Andrea
08:01:53 [Ian]
Present+ Dapeng
08:01:59 [Ian]
present+ jiajia
08:02:04 [Ian]
present+ SimonScorer
08:02:13 [Ian]
present+ KrisKetels
08:02:17 [Ian]
present+ VincentKuntz
08:02:22 [Ian]
present+ Shane
08:02:25 [Ian]
present+ Manu
08:02:29 [Ian]
present+ MattS
08:02:34 [Ian]
present+ Faraz
08:02:39 [Ian]
present+ CyrilVignet
08:02:44 [Ian]
present+ NichlasAncot
08:02:48 [Ian]
present+ Jean-Yves
08:02:54 [Ian]
present+ zach
08:02:56 [CyV]
CyV has joined #wpwg
08:02:57 [Ian]
present+ Sebastien
08:03:01 [Ian]
present+ LarsErik
08:03:03 [Ian]
present+ Dongwoo
08:03:09 [Ian]
present+ Rouslan
08:03:09 [manu]
present+ LaurentCastillo
08:03:12 [Ian]
present+ LaurentJones
08:03:15 [Ian]
present+ Florian
08:03:17 [Ian]
present+ Andre
08:03:23 [Ian]
present+ NickS
08:03:25 [Ian]
present+ Roy
08:03:28 [Ian]
present+ Ade
08:03:37 [Ian]
present+ Connor
08:03:42 [Ian]
present+ NickTR
08:03:45 [Ian]
present+ AdamR
08:03:51 [Ian]
present+ Farad
08:03:53 [Ian]
present+ AHB
08:04:04 [AjayRambocus]
AjayRambocus has joined #wpwg
08:04:05 [Ian]
present+ Ajay
08:04:06 [manu]
nicktr: On screen is the agenda, we're starting by talking about payment apps spec.
08:04:20 [Ian]
q+
08:04:34 [manu]
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 [manu]
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 [manu]
nicktr: This can't just rest on the shoulders of 2-3 people or just the editors.
08:06:24 [manu]
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 [manu]
Ian: There have been some requests for significant others, we may have some space.
08:07:15 [manu]
brian_s: We have security outside to guide you to restrooms, etc.
08:07:22 [Ian]
topic: Payment APps
08:07:34 [manu]
Topic: Payment Apps
08:07:34 [Ian]
Payment Request API
08:07:34 [Ian]
https://www.w3.org/TR/payment-request/
08:08:12 [nicktr]
q?
08:08:24 [nicktr]
ack Ian
08:08:25 [Ian]
q-
08:08:26 [manu]
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 [manu]
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 [manu]
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]
Laurent has joined #wpwg
08:10:50 [Max]
q+
08:10:52 [manu]
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 [manu]
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 [manu]
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 [manu]
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]
conorh has joined #wpwg
08:12:34 [manu]
AdrianHB: How does a payment app make browser aware that it's been uninstalled?
08:13:30 [manu]
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 [manu]
AdrianHB explains how payment flow works for what this WG is proposing.
08:13:55 [Ian]
Payment App spec -> https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html
08:15:04 [manu]
nicktr: There is a diagram in an architecture summary proposal that's helpful, we may be taking up that work tomorrow.
08:15:15 [nicktr]
q?
08:15:18 [manu]
AdrianHB: This is a simple Javascript API that we're defining.
08:15:58 [manu]
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 [nicktr]
q?
08:16:55 [manu]
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 [CyrilV]
* the link to the diagram ?
08:18:09 [manu]
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 [conorh]
https://w3c.github.io/webpayments/proposals/wparch/ (Section 4)
08:18:29 [Ian]
q+
08:18:32 [Ian]
ack Max
08:19:01 [zkoch]
q+
08:19:08 [manu]
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 [manu]
AdrianHB: That's roughly the same user experience
08:19:30 [nicktr]
q?
08:19:35 [nicktr]
ack Ian
08:20:02 [manu]
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 [manu]
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 [manu]
Ian: yesterday, in discussion with Alibaba, they asked why this new approach is going to benefit the customer.
08:22:19 [manu]
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 [manu]
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 [manu]
Ian: Third, users can specify via the underlying API where they can use certain payment apps - user choice.
08:24:17 [manu]
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 [manu]
Ian: For these cases, we may want to have a quick/automatic selection mechanism.
08:24:44 [nicktr]
q?
08:25:00 [manu]
Ian: This is independent from other topics wrt. how payment apps are quickly selected.
08:25:26 [manu]
Depeng: I suggest the Working Group focuses on how to improve that (the Alipay) case.
08:25:31 [Ian]
Max: We can help add "how this improves the user experience" info to the spec
08:25:39 [Ian]
https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html#paymentapp.register
08:25:49 [manu]
Depeng: Payment registration requires a URL, but that isn't useful for native apps.
08:26:57 [manu]
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 [Ian]
+1 to best practices documentation on how to create apps on different platforms
08:27:21 [manu]
Depeng: For native apps, maybe the Working Group can produce a provisional document for platform specific implementations.
08:28:02 [manu]
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 [Ian]
Max: We'd like to contribute to such good practice
08:28:24 [manu]
Depeng: Alipay would like to collaborate on this.
08:29:01 [zkoch]
q-
08:29:27 [manu]
nicktr: We can have this discussion via spec text and provide informative text like you describe via specs.
08:29:28 [Ian]
NickTR: +1 to create resources around good practices
08:29:47 [manu]
AdrianHB: How do you describe ordering of apps?
08:29:54 [manu]
AdrianHB: How do you bootstrap the ecosystem?
08:30:03 [manu]
AdrianHB: Do we need to say anything about defaults?
08:30:11 [Ian]
q+
08:31:06 [manu]
Mahesh: We (Samsung Pay) could collaborate on those practice as well.
08:31:23 [manu]
Ian: Let's walk through the spec and discuss specific issues after that.
08:32:34 [manu]
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 [manu]
Ian: In section 4, we set out the model on how this works.
08:33:03 [adrianba]
q+
08:33:03 [manu]
present+ DanAppelquist
08:33:12 [Faraz]
Faraz has joined #wpwg
08:33:14 [Max]
Mahesh， OK, thanks
08:34:24 [manu]
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 [manu]
Ian: A matching application should have /these/ properties.
08:34:39 [manu]
ack Ian
08:35:00 [rouslan]
q?
08:35:15 [adamR]
adamR has joined #wpwg
08:36:02 [manu]
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 [manu]
register something w/ the browser?
08:36:17 [manu]
q+ to note on layering issues.
08:36:23 [nicktr]
ack adrianba
08:36:53 [jiajia]
jiajia has joined #wpwg
08:37:18 [dka]
dka has joined #wpwg
08:37:57 [manu]
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 [manu]
support, etc.
08:38:46 [Ian]
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 [manu]
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 [AdrianHB]
q+ to respond to adrianba
08:38:53 [ShaneM]
q+ to say that we should not restrict methods to app origin
08:39:51 [ShaneM]
adamR I agree that it was a proposal
08:39:58 [nicktr]
q?
08:40:12 [rouslan_]
rouslan_ has joined #wpwg
08:40:22 [manu]
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 [zkoch]
Yeah, I don’t think Adrian is proposing that we limit apps to a singular origin
08:41:10 [manu]
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 [nicktr]
ack manu
08:41:18 [Zakim]
manu, you wanted to note on layering issues.
08:41:18 [manu]
adrianba: I'm not sure what the best way is to address.
08:41:20 [zkoch]
I think he’s just saying it’s unclear what assumptions were made to reach the current app spec
08:41:27 [Ian]
manu: I looked at the spec from the viewpoint of the HTTP API
08:41:46 [Ian]
...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__]
rouslan__ has joined #wpwg
08:42:05 [Ian]
...so it feels like the layering is off
08:42:15 [Ian]
q?
08:42:30 [Ian]
...E.g., would be easier to create a separate registration spec
08:42:46 [rouslan_]
rouslan_ has left #wpwg
08:42:47 [Ian]
...I think that HTTP spec should reuse the registration section but today it can't easily do so
08:42:59 [Ian]
..is the plan that it be reusable ?
08:43:07 [nicktr]
ack AdrianHB
08:43:07 [Zakim]
AdrianHB, you wanted to respond to adrianba
08:43:22 [rouslan_]
rouslan_ has joined #wpwg
08:44:23 [rouslan_]
q?
08:45:18 [manu]
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 [manu]
at was the design decision behind it. Reuse via HTTP API was not a goal.
08:45:48 [manu]
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 [manu]
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 [Ian]
ack S
08:46:18 [Zakim]
ShaneM, you wanted to say that we should not restrict methods to app origin
08:46:23 [manu]
ack ShaneM
08:46:28 [zkoch]
q+
08:46:54 [manu]
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 [manu]
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 [manu]
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 [manu]
adrianba: I wasn't proposing that, I suggested that to be deliberately provocative.
08:48:50 [Ian]
Manu: Having read through a lot of the spec text, a large part would be duplicated in the HTTP API
08:48:53 [nicktr]
q?
08:48:55 [Ian]
ack manu
08:48:55 [Zakim]
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 [Ian]
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 [Ian]
...I am starting to see that we are duplicating
08:50:31 [nicktr]
q+
08:50:41 [manu]
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]
jiajia has joined #wpwg
08:50:43 [manu]
ack zkoch
08:51:34 [manu]
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 [manu]
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 [manu]
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 [manu]
q+ to note that Coinbase just added PayPal support to their wallet.
08:53:06 [manu]
zkoch: We want players like LastPass to be able to play in the ecosystem.
08:53:35 [Ian]
q+ to ask how these closed loops system would change what we discuss in the spec
08:53:42 [manu]
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 [MattS]
q?
08:54:00 [Laurent]
q+
08:54:09 [MattS]
q+
08:54:15 [manu]
zkoch: I think we should consider that - notion of recommended payment apps - who provides that list.
08:54:58 [manu]
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 [Laurent]
+1 to Adrian
08:55:19 [manu]
q-
08:56:17 [manu]
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 [Ian]
zkoch: I can see partnerships as use cases (e.g., some company licenses another company to implement the proprietary system)
08:56:29 [manu]
zkoch: For right now, we could say closed loop systems have to match origin.
08:56:42 [nicktr]
q?
08:57:11 [nick]
I can certainly imagine a developer *accidentally* claiming to support a payment app they don’t
08:57:21 [Ian]
q-
08:57:38 [Laurent]
q-
08:57:54 [manu]
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 [Laurent]
q+
08:58:40 [manu]
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 [Ian]
q+
08:59:57 [nick]
q+
09:00:03 [manu]
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 [MattS]
q-
09:00:38 [manu]
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 [manu]
ack nicktr
09:00:58 [nicktr]
ack Laurent
09:01:02 [ben]
amex has a poin
09:01:08 [ben]
point
09:01:33 [Faraz]
I agree. Restrictions that potentially restricts players from the ecosystem are a bad idea.
09:01:35 [nicktr]
q+ to ask Amex for their input
09:01:35 [manu]
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 [Faraz]
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 [manu]
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 [manu]
AdrianHB: How do you stop payment apps from saying they'll support payment of something when they don't.
09:02:37 [nicktr]
ack Ian
09:03:10 [manu]
Ian: Let's take the approach for the moment that the standard doesn't support anything.
09:04:29 [manu]
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 [manu]
Ian: When I have something installed, it's not our point to say how that is displayed.
09:05:24 [manu]
Ian: User experience to deal with them - Zach, do you have suggestions on how this should be done?
09:05:34 [nicktr]
ack nick
09:06:28 [manu]
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 [manu]
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 [nicktr]
q?
09:07:44 [manu]
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 [manu]
AdrianHB: Amex payment method is not at Amex.
09:08:25 [manu]
nickS: Yes, but Walmart is.
09:08:50 [manu]
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 [manu]
nickS: Yes, but same origin is also a security issue.
09:09:09 [Max]
q+
09:09:17 [manu]
Ian: Yes, but the 'same origin' that was mentioned was not the 'same origin security' issue.
09:10:02 [manu]
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 [manu]
Charlie: We can't talk about anything wrt. restricting competition.
09:11:15 [Ian]
q?
09:11:23 [nicktr]
ack nicktr
09:11:23 [Zakim]
nicktr, you wanted to ask Amex for their input
09:11:33 [Ian]
[IJ thinks that that's precisely why the standard needs to not pick a particular regulatory regime]
09:12:03 [manu]
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 [manu]
Charlie: Yes, but we should be very careful here - we can't have discussions that restrict competition.
09:12:35 [Ian]
q+ to recharaterize
09:12:54 [manu]
AdrianHB: I'm hearing that we need to protect against malicious payment apps.
09:13:32 [adamR]
q+ to point out that per-spec prose doesn’t scale
09:13:51 [manu]
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 [nicktr]
q?
09:14:01 [manu]
q+ to note "display" language in spec.
09:14:05 [manu]
ack Max
09:14:33 [manu]
Depeng: With respect to fake payment methods, we don't want users to be misled.
09:14:48 [manu]
AdrianHB: There are certainly concerns wrt. phishing, etc.
09:15:02 [nicktr]
ack Ian
09:15:02 [Zakim]
Ian, you wanted to recharaterize
09:15:10 [manu]
AdrianHB: We may have another session on this.
09:15:34 [manu]
Ian: There are two framings - one from payment method provider perspective, another from user perspective.
09:15:51 [nicktr]
q?
09:16:03 [manu]
AdrianHB: I think this will be dealt with in payment method specs.
09:16:13 [manu]
Ian: Yes, but let's not make that decision now.
09:16:53 [Ian]
IJ: I think that we may need to augment the payment API re: registration data
09:17:00 [Ian]
q?
09:17:09 [manu]
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 [manu]
adamR: Something that puts restrictions on a per-payment method spec is not going to scale.
09:17:38 [nicktr]
ack adamR
09:17:38 [Zakim]
adamR, you wanted to point out that per-spec prose doesn’t scale
09:17:44 [nicktr]
ack manu
09:17:44 [Zakim]
manu, you wanted to note "display" language in spec.
09:17:53 [Ian]
manu: There's a lot of language in the algorithms about display requirements
09:18:02 [Ian]
...I don't have a strong opinion on that other than it feels strange
09:18:06 [Ian]
q+
09:18:28 [nicktr]
ack Ian
09:19:44 [manu]
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 [ShaneM]
friendly comment - we should say "present", not "display"
09:20:10 [manu]
ian: These things may be obvious/unnecessary to say - we are trying to provide intent on what should be displayed.
09:20:22 [adrianba]
q+
09:20:25 [manu]
manu: +1 on "present"
09:20:49 [nicktr]
ack adrianba
09:20:49 [manu]
Ian: We try to frame things in ways that show intent.
09:21:45 [manu]
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 [manu]
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 [manu]
Ian: When we've only provided "why" only, we haven't gotten interoperability either.
09:22:30 [nicktr]
q?
09:23:01 [manu]
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 [nick]
q+
09:23:36 [Ian]
q+
09:24:02 [adamR]
q+
09:24:23 [manu]
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 [Faraz]
q+
09:24:56 [nicktr]
ack nick
09:25:02 [manu]
zakim, close queue
09:25:02 [Zakim]
ok, manu, the speaker queue is closed
09:25:05 [Ian]
queue=adamR,Faraz,Ian
09:25:09 [Max]
q+
09:25:18 [adamR]
q-
09:25:40 [manu]
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 [nicktr]
q?
09:26:51 [manu]
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_]
rouslan_ has joined #wpwg
09:27:06 [Ian]
Nick: Present entire ecosystem, e.g., may lose placement but also will get more conversions
09:27:08 [manu]
nicks: We need to look at the entire ecosystem in order to convince merchants.
09:27:43 [manu]
Faraz: The word "ordering" is also problematic - objection to talk about that.
09:28:11 [manu]
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 [manu]
Ian: Recommended apps - flesh it out w/ "the why" - how can it be used and misused.
09:29:02 [manu]
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 [manu]
Ian: Refactorization may be the right thing to do in time.
09:29:24 [manu]
Ian: Connor sent a few things to the list as well.
09:29:36 [manu]
nicktr: Break for coffee, we'll be back in a bit.
09:29:42 [manu]
rrsagent, draft minutes
09:29:42 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html manu
09:30:47 [manu]
s/Payment APps/Payment Apps/
09:30:51 [manu]
rrsagent, draft minutes
09:30:51 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html manu
09:31:25 [manu]
s/Topic: Introducitons//
09:31:28 [manu]
rrsagent, draft minutes
09:31:28 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html manu
09:58:54 [nick]
nick has joined #wpwg
10:00:15 [nick]
nick has joined #wpwg
10:07:14 [MaheshK]
MaheshK has joined #wpwg
10:17:22 [Max]
Max has joined #wpwg
10:17:24 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
10:18:13 [dka]
dka has joined #wpwg
10:18:26 [alyver]
alyver has joined #wpwg
10:18:30 [nick]
nick has joined #wpwg
10:20:13 [rouslan_]
rouslan_ has joined #wpwg
10:20:13 [adamR]
adamR has joined #wpwg
10:20:19 [Lauren_Jones]
Lauren_Jones has joined #wpwg
10:20:36 [zkoch]
zkoch has joined #wpwg
10:20:42 [Ian]
scribe: Ian
10:20:57 [Ian]
Topic: Implementation Experience
10:21:07 [lbolstad]
lbolstad has joined #wpwg
10:21:13 [lbolstad]
present+
10:21:34 [Ian]
adrianhb: We'd like in this session to hear back from implementers about their experiences and implications for the spec
10:21:44 [fdold]
fdold has joined #wpwg
10:21:52 [Laurent]
Laurent has joined #wpwg
10:22:31 [Ian]
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]
Faraz_Babar has joined #wpwg
10:22:40 [pirouz]
pirouz has joined #WPWG
10:22:54 [Nicolas_A_]
Nicolas_A_ has joined #wpwg
10:23:20 [Roy]
Roy has joined #wpwg
10:23:49 [Ian]
adrianhb: Also want to know priority of issues to make progress
10:23:57 [jyrossi]
jyrossi has joined #wpwg
10:24:22 [Ian]
adrianba: API is in development at MS
10:24:32 [Ian]
...the number one thing that is important to us to stabilize the API
10:24:50 [Ian]
...our current implementation is experimental both in terms of UX experience and integration,
10:25:00 [Ian]
..but also the way that we have prototyped it means that it's not production ready
10:25:14 [Ian]
..for us to transition to shipping version, we want greater confidence that changes are diminishing
10:25:16 [Roy]
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 [Ian]
...to the point where changes come from implementation experience rather than feature desires
10:26:08 [zkoch]
zkoch has joined #wpwg
10:26:17 [VincentK]
VincentK has joined #wpwg
10:26:19 [Ian]
...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 [VincentK]
present+ VincentK
10:26:49 [Ian]
...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 [Ian]
...what a user should do next based on the reason the merchant cannot shop
10:27:26 [Ian]
s/shop/ship
10:27:49 [Ian]
...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 [Ian]
...so we need to figure how (the API can) do this interaction with the user
10:28:22 [Ian]
...e.g., should there be an enumeration of popular reasons
10:28:33 [Ian]
...but we may not want to support a generic message from the Web site
10:28:55 [Ian]
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 [Ian]
..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 [Ian]
present+ DavidBirch
10:30:10 [Ian]
...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 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
10:30:29 [Ian]
...initially, adopting the API might risk merchant conversion rates
10:30:49 [Ian]
...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 [nicktr]
q?
10:30:54 [Ian]
q-
10:30:56 [Ian]
q-
10:31:02 [Ian]
q- Faraz
10:31:15 [Ian]
adrianba: We need feedback from merchants about how integration might work.
10:32:00 [Ian]
...e.g., we may need to figure out how merchants can learn what is supported
10:32:16 [Ian]
...we want to avoid adding yet another button to busy sites
10:32:25 [nicktr]
q?
10:32:25 [Ian]
...so we may need some other API feature in order to bootstrap the ecosystem
10:32:26 [AdrianHB]
q?
10:32:30 [nicktr]
q+
10:32:34 [nicktr]
zakim, open the queue
10:32:34 [Zakim]
ok, nicktr, the speaker queue is open
10:32:37 [nicktr]
q+
10:32:40 [Ian]
...so I'd like to hear from merchants (or those with relationships) to hear how integration will work
10:32:50 [Ian]
adrianhb: I suggest that we have a session specifically on bootstrapping
10:33:05 [manu]
q+ to ask about privacy thoughts/implications of sharing shipping address, email, and any other information shared via selection events.
10:33:36 [Ian]
agenda+ Bootstrapping the ecosystem
10:33:48 [Ian]
ack nicktr
10:34:21 [Ian]
NickTR: I agree that bootstrapping is an issue; the Worldpay demo is helping us talking to our own customers
10:34:30 [Ian]
ack manu
10:34:30 [Zakim]
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 [Ian]
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 [nicktr]
q?
10:35:34 [Ian]
Manu: Have implementers had feedback on privacy?
10:35:42 [ben]
ben has joined #wpwg
10:36:04 [Ian]
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 [Ian]
...in terms of address, I"m not sure the problem has been solved...we redact our addresses
10:36:39 [Ian]
...we return 5-digit zip in the US, we redact other information in Europe
10:36:49 [Ian]
...some merchants have very unique use cases (e.g., 1 hour delivery)
10:36:59 [Ian]
...sometimes the same zip code in the us can be subject to different taxes
10:37:15 [Ian]
...if we ever were to release a full address, it would be with user consent
10:37:58 [Ian]
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 [Ian]
...Apple offers customization in some fields...that's not supported in payment request API
10:38:37 [Ian]
...e.g., changing some of the terminology used...for example, if you are a ride share service you don't "ship"
10:38:47 [Ian]
...so one topic is whether the payment request API should support customization this way
10:39:11 [Ian]
...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 [Ian]
...Another topic - billing address...we heard from merchants that a lot of their systems require it.
10:40:01 [Ian]
...we also have a "Discovery API"....this comes back to merchants and how they want to implement the API
10:40:27 [Ian]
...we hope that payment request API will improve conversion...some merchants may want push users to use it
10:40:47 [Ian]
...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 [Ian]
...so that's a more generic question than "specific payment methods"
10:41:47 [Ian]
...we have the discovery API...that API is validated (merchant identity)...not sure that validation is necessary here.
10:42:06 [Ian]
...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 [Ian]
...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 [Ian]
...I think we should consider merchant validation
10:43:11 [Ian]
...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 [Ian]
...helpful, eg., if a merchant's domain has been compromised.
10:43:36 [Ian]
...I can see various ways that could work in the API...my webkit colleagues can provide details
10:44:04 [Ian]
...generically, the question is whether we can go to the payment method provider and get acknowledgment before a bad user experience
10:44:25 [Ian]
...I think we should consider the case where a payment method provider does not want to accept a payment request
10:44:37 [nicktr]
q?
10:44:49 [Ian]
...there may be other reasons to not support a payment (e.g., security infrastructure issues)
10:45:00 [Ian]
...I hope to have concrete issues in github over the next couple of weeks
10:45:13 [Ian]
...Apple implementation of our API is available in developer release
10:45:21 [AdrianHB]
q?
10:46:01 [Ian]
zkoch: First a status update: Blink implementation is in line with the current spec
10:46:16 [Ian]
..you can call the API with support for per-payment-method pricing, the UI does not yet support it
10:46:32 [Ian]
...check out android developer channel (chrome dev)
10:46:40 [Ian]
..we continue to iterate ... we made public our intent to ship
10:47:11 [Ian]
zkoch: In terms of issues, I have a few topics
10:47:26 [Ian]
...like AdrianB I support goal of getting to CR rapidly
10:47:33 [Ian]
...I think merchant feedback is really important
10:47:39 [Ian]
..so spec does not have to be perfect
10:47:54 [Ian]
..we've heard back that "knowing whether a payment method is available" is something merchants have asked for
10:48:22 [Ian]
...trying to balance merchant and privacy requirements is tricky; we don't have a good proposal yet
10:48:54 [Ian]
...another issue is that we need a way to bootstrap the ecosystem for card payment methods and sub-brands
10:49:00 [Ian]
...we'd like to resolve that dependency ASAP
10:49:25 [Ian]
...autofill has a security/privacy model
10:49:54 [Ian]
...regarding sharing shipping address, we do share it in the DOM
10:50:04 [nicktr]
q?
10:50:10 [Ian]
...we are happy with this from a user consent perspective
10:50:44 [Ian]
..but there are some issues...we can't use information as seamlessly as we might, due to consent requirement around privacy
10:50:51 [Ian]
...we use "pay" as a user consent model
10:51:12 [pirouz]
pirouz has joined #WPWG
10:51:23 [Ian]
...as we get more merchant feedback I will share
10:51:26 [Ian]
...e.g., iframe has come up
10:51:40 [Ian]
...one question is whether to support payment request in a secure iframe even when not in a secure context
10:52:23 [adamR]
q+
10:52:34 [Ian]
...also, we might benefit in providing some higher-level information for merchants
10:53:07 [Ian]
...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 [Ian]
...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 [Ian]
...we want this to be in place by Q4 (before holiday freeze)
10:54:38 [Ian]
q+
10:54:55 [Ian]
q-
10:55:14 [nicktr]
holiday season varies by geography but see November and December typically as no-go areas for change for merchants
10:55:21 [nicktr]
ack adamR
10:55:28 [Ian]
adamr: Is blink implementation basic card?
10:55:33 [Ian]
zkoch: Yes.
10:55:45 [Ian]
...potentially also support for android pay
10:56:15 [Ian]
...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 [nicktr]
q?
10:57:27 [AjayR]
AjayR has joined #wpwg
10:57:33 [nicktr]
q?
10:57:43 [conorh]
+q
10:58:07 [nicktr]
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]
Lauren_Jones has joined #wpwg
10:58:58 [nicktr]
q?
10:59:53 [zkoch]
zkoch has joined #wpwg
10:59:55 [Ian]
conor: Worldpay happy to participate in the task force
10:59:58 [zkoch]
q?
11:00:06 [Ian]
https://github.com/w3c/webpayments/wiki/PaymentApp_Notes
11:00:07 [nicktr]
ack conorh
11:00:57 [Ian]
q?
11:01:30 [Ian]
DanAppelquist: We are working on this at Samsung.
11:01:49 [Ian]
...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 [Ian]
q+
11:02:14 [Max]
q+
11:02:16 [Ian]
...so please include is in the list of implementers
11:03:09 [Ian]
Roy: At Facebook we did a hackathon and I implemented (draft) payment app proposal and interface with payment request API
11:03:35 [Ian]
...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 [Ian]
...on native we had to wing it and see how the payment app proposal would translate...we used intents on Android
11:04:04 [Ian]
...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]
brian_s has joined #WPWG
11:04:49 [Ian]
....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 [Ian]
q?
11:05:13 [Lauren_Jones_]
Lauren_Jones_ has joined #wpwg
11:05:19 [Ian]
adrianhb: Clarification - do you mean that when I register an app that registration information is shared across devices?
11:05:22 [Ian]
Roy: That, too.
11:05:54 [Ian]
...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 [Ian]
...we ended up implementing this through our FB SDK
11:06:24 [Ian]
...that seemed to be the most natural UX
11:06:53 [adrianba]
q+
11:06:57 [Ian]
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 [Ian]
ack me
11:07:41 [manu]
Ian: Following up on what Dan said - I've been reaching out to more payment method providers to roadtest the API
11:08:18 [manu]
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 [manu]
Ian: Please keep this in mind as we continue the discussion.
11:08:46 [zkoch]
q+
11:08:48 [Ian]
nicktr: Do you anticipate (NickS) that there would be an Apple Pay payment method spec?
11:09:14 [Ian]
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 [Ian]
...so "potentially"...might depend on things I mentioned earlier such as merchant validation
11:09:39 [zkoch]
q-
11:10:02 [Ian]
zkoch: I expect we will have "documentation" (though probably not a w3c spec)
11:10:43 [Ian]
[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 [Ian]
q?
11:14:14 [Ian]
ack max
11:14:24 [nicktr]
ack Max
11:14:39 [Ian]
Max: On issue 2 - should payment request API only be available in top-level context (or iframe)
11:14:55 [Ian]
...we support the idea of providing a security mechanism
11:15:11 [Ian]
adrianhb: Current proposal is top level PLUS other contexts authorized by the top-level context
11:15:27 [Ian]
...e.g., top level can provide an attribute to the iframe provided by a payment service provider
11:15:53 [Ian]
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 [Ian]
...we do that to support Stripe, for example, which drop in a checkout form in an iframe
11:16:20 [jyrossi]
jyrossi has joined #wpwg
11:16:34 [Ian]
...also the proposal on github regarding delegation seems like it would do the job
11:16:46 [ben]
ben has joined #wpwg
11:17:28 [Ian]
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 [Ian]
adrianhb: The intention here is that we are not being specific about what the browser does....
11:18:01 [nicktr]
q?
11:18:27 [Ian]
...in the case where ther is no content in the response....
11:18:36 [Ian]
..there is a response even if there is no data in the response
11:18:47 [Ian]
..the promise resolution returns control to the browser
11:19:27 [Ian]
AdrianBA: The API takes into account the use case where the response data is empty
11:19:54 [Ian]
Max: What happens when there is a delay before the response?
11:20:47 [Ian]
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 [Ian]
AdrianBA: Regarding support in native apps,
11:22:35 [nicktr]
ack adrianba
11:22:35 [Ian]
...UX considerations are important (e.g., to avoid spoofing UI)
11:22:35 [Ian]
q?
11:26:07 [Ian]
[Worldpay demo]
11:27:48 [Ian]
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 [Ian]
[Conor shows polyfill usage from Ade on top of the service]
11:29:19 [Ian]
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 [Ian]
...tokenization happens on world pay's server
11:30:50 [Ian]
Conor: Browser gets data, sends to worldpay which tokenizes and sends back to the merchant
11:34:36 [nick]
q+
11:35:07 [Ian]
[More discussion of tokenization]
11:35:11 [Ian]
[One-time v. reuse]
11:35:42 [Ian]
MattS: This implementation is a one-time token
11:35:47 [Ian]
...to avoid passing the PAN
11:36:09 [nick]
q-
11:36:09 [Ian]
q?
11:37:32 [Lauren_Jones]
Lauren_Jones has joined #wpwg
11:41:46 [Roy]
q+
11:41:52 [nicktr]
q?
11:43:32 [Ian]
Roy: When we built the Facebook version of this we did things similarly.
11:44:00 [Ian]
...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 [nicktr]
q?
11:44:09 [Ian]
ack R
11:44:20 [AdrianHB]
q+ to suggest we define an enhancement to card for encrypted pan
11:44:34 [conorh]
conorh has joined #wpwg
11:44:35 [Ian]
....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 [Ian]
IJ: I mentioned three ways to do things (which may be useful in a transition period)
11:45:00 [Ian]
1) Split context in the browser where there's a merchant app and also PSP code that is separate
11:45:12 [Ian]
2) Third party payment app does work
11:45:21 [Ian]
3) Payment method spec itself means token circulates
11:45:29 [Ian]
Topic: Expanded card payment spec
11:45:41 [Ian]
Nick: I have recruited a volunteer to help me write a tokenized spec
11:45:49 [Ian]
AdrianHB: Yes, let's call for volunteers
11:46:03 [Ian]
AdrianHB: I'd like to close two issues on our issue list in next 15 mins
11:46:15 [Ian]
- non-standard currencies
11:46:19 [Ian]
- which data goes to payment apps
11:46:33 [manu]
q+ to ask about "new payment methods"
11:47:10 [manu]
q-
11:47:16 [manu]
My point is that this sounds like it's out of charter
11:47:39 [Ian]
People who want to work on advanced card spec: NickTR, Faraz, Laurent, Kevin(?) from Facebook?
11:47:55 [Ian]
topic: Proposal related to non-standard currencies
11:47:58 [Max]
Max has joined #wpwg
11:48:11 [Ian]
--------
11:48:11 [Ian]
Starters:
11:48:11 [Ian]
Carpaccio 1
11:48:11 [Ian]
Salmon 7
11:48:12 [Ian]
Aubergine 3
11:48:13 [Ian]
Scallops 8
11:48:14 [Ian]
--------
11:48:16 [Ian]
Mains:
11:48:18 [Ian]
gnocchi 2
11:48:20 [Ian]
duck breast 4
11:48:22 [Ian]
Rib Eye steak 7
11:48:24 [Ian]
sea bass 7
11:48:26 [Ian]
--------
11:48:28 [Ian]
Desserts:
11:48:30 [Ian]
Ice cream/sorbet 2
11:48:32 [Ian]
Tiramisu 7
11:48:34 [Ian]
Panna Cotta 3
11:48:38 [Ian]
https://github.com/w3c/browser-payment-api/issues/185#issuecomment-228117620
11:48:40 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
11:48:51 [rouslan_]
rouslan_ has joined #wpwg
11:49:59 [Lauren_Jones]
Lauren_Jones has joined #wpwg
11:50:03 [Ian]
[AHB summarizes the proposal]
11:50:12 [Ian]
- you specify registry and entry in registry
11:50:25 [Ian]
- default registry is ISO 4217 registry
11:50:27 [nicktr]
q?
11:50:33 [nicktr]
ack AdrianHB
11:50:33 [Zakim]
AdrianHB, you wanted to suggest we define an enhancement to card for encrypted pan
11:50:52 [Ian]
Kris: ISO is looking at a way to extend their current mechanism to meet this sort of requirement
11:51:40 [Ian]
q?
11:51:56 [Ian]
Kris: ISO also looking at using URLs
11:52:53 [nicktr]
q?
11:53:31 [Ian]
PROPOSED: Adopt AdamR's proposal for handling currency codes and addressing 185
11:53:36 [manu]
+1
11:53:39 [nicktr]
+1
11:53:43 [AdrianHB]
+1
11:53:45 [rouslan]
+1
11:53:59 [Ian]
+1
11:54:00 [alyver]
+1
11:54:00 [ShaneM]
+1
11:54:08 [CyrilV]
+1
11:54:19 [adamR]
+1
11:54:23 [conorh]
+1
11:54:24 [Ian]
[No objections]
11:54:26 [MaheshK]
+1
11:54:28 [Ian]
SO RESOLVED
11:54:40 [Dongwoo]
+1
11:54:42 [Laurent]
+1
11:54:55 [Ian]
ACTION: AdamR to work on concrete spec language around currency codes
11:54:56 [trackbot]
Created ACTION-20 - Work on concrete spec language around currency codes [on Adam Roach - due 2016-07-14].
11:55:08 [Ian]
[Issue 157]
11:55:26 [Ian]
AHB: Question is how much data to pass to the payment app of the original payment request
11:55:28 [Ian]
q?
11:55:35 [fnisar]
fnisar has joined #wpwg
11:55:44 [MattS]
q?
11:55:56 [MattS]
q?
11:56:13 [manu]
q+ to note security implications of this decision.
11:56:14 [rouslan]
q+
11:56:31 [adrianba]
q+
11:57:16 [Ian]
[Pros and cons of sending all the original data v. sending only a subset]
11:57:25 [Ian]
Subset: Don't send unnecessary data; preserve merchant privacy
11:57:29 [nicktr]
zakim, close the queue
11:57:29 [Zakim]
ok, nicktr, the speaker queue is closed
11:57:30 [Ian]
Full data: Signing
11:57:33 [nicktr]
ack manu
11:57:33 [Zakim]
manu, you wanted to note security implications of this decision.
11:57:50 [Ian]
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 [Ian]
...general concern is inability to sign messages...since some data is at the top level
11:58:32 [Ian]
...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 [nicktr]
q?
11:58:53 [Ian]
...potential security issue where you can recompose messages to do things that the merchant never wanted to do
11:58:57 [Ian]
ack rouslan
11:58:58 [Fawad]
Fawad has joined #wpwg
11:59:09 [Laurent]
+1 to Manu on impact on signatures
11:59:28 [Ian]
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 [Ian]
...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 [AdrianHB]
q?
12:00:21 [AdrianHB]
Q= to close
12:00:33 [Ian]
...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 [Ian]
q?
12:00:43 [nicktr]
q?
12:00:44 [Ian]
ack ad
12:01:27 [Ian]
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 [Ian]
AdrianHB: I am ok to close this in the payment request API repo and opening in the payment app issues list
12:02:08 [dka]
Possibly of relevance to this discussion: https://www.w3.org/2001/tag/doc/APIMinimization.html
12:02:30 [Ian]
PROPOSAL: Close issue 185 on payment request api and move to the general issue list.
12:02:38 [Ian]
+1
12:02:55 [adrianba]
+1
12:02:59 [Ian]
[No objections]
12:03:01 [Ian]
SO RESOLVED
12:03:04 [Ian]
LUNCH
12:03:07 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
12:19:44 [Adam_]
Adam_ has joined #wpwg
12:26:42 [Roy]
Roy has joined #wpwg
12:29:48 [sam]
sam has joined #wpwg
12:38:38 [nick]
nick has joined #wpwg
12:44:31 [rouslan]
rouslan has joined #wpwg
12:49:16 [lbolstad]
lbolstad has joined #wpwg
12:51:03 [Max]
Max has joined #wpwg
12:56:00 [alyver]
alyver has joined #wpwg
12:58:55 [Faraz]
Faraz has joined #wpwg
13:01:03 [fdold]
fdold has joined #wpwg
13:01:16 [alyver]
alyver has joined #wpwg
13:04:09 [conorh]
conorh has joined #wpwg
13:06:26 [nick]
nick has joined #wpwg
13:11:07 [adamR]
adamR has joined #wpwg
13:11:51 [dka]
dka has joined #wpwg
13:12:59 [nicktr]
nicktr has joined #wpwg
13:13:29 [adamR]
adamR has joined #wpwg
13:13:35 [Ian]
topic: Payment Methods
13:13:53 [zkoch]
zkoch has joined #wpwg
13:15:09 [brian_s]
brian_s has joined #WPWG
13:15:12 [Ian]
[SEPA / Direct Credit ]
13:15:40 [VincentK]
VincentK has joined #wpwg
13:15:55 [Ian]
[Basic Card]
13:15:55 [Ian]
https://w3c.github.io/webpayments-methods-card/
13:16:04 [VincentK]
present+
13:16:32 [zkoch]
Nick, can you zoom in on screen?
13:16:34 [Ian]
MattS: First topic there to resolve is payment method identifiers
13:16:43 [adrianba]
q+
13:16:46 [Ian]
...there's a long list of identifiers in the spec
13:16:49 [Nicolas_A_]
Nicolas_A_ has joined #wpwg
13:16:49 [Ian]
zakim, open the queue
13:16:49 [Zakim]
ok, Ian, the speaker queue is open
13:16:58 [adrianba]
q+
13:17:06 [Ian]
...one thing that I think is an issue is "how we match"
13:17:39 [Ian]
...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 [CyrilV]
q+
13:17:59 [nicktr]
q?
13:18:08 [Ian]
adrianhb: We have a lot of time dedicated to payment method identifiers
13:18:19 [jyrossi]
jyrossi has joined #wpwg
13:18:32 [Lauren_Jones]
Lauren_Jones has joined #wpwg
13:18:38 [pirouz]
pirouz has joined #WPWG
13:19:17 [Ian]
agenda+ PMIs (grouping and bootstrapping)
13:19:49 [Ian]
MattS: The basic card spec currently has no data for payment request input
13:20:04 [Ian]
...one pull request from me involves the ability for a merchant to specify information as required
13:20:10 [Ian]
https://w3c.github.io/webpayments-methods-card/
13:20:46 [Ian]
https://github.com/w3c/webpayments-methods-card/pull/4
13:21:11 [Ian]
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_]
Lauren_Jones_ has joined #wpwg
13:21:29 [Ian]
...some merchants do not collect CVV, for example, and that's a business decision
13:21:29 [AdrianHB]
q?
13:21:34 [nicktr]
q?
13:21:35 [Ian]
q+
13:21:47 [nicktr]
ack adrianba
13:22:43 [Ian]
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]
AjayR has joined #wpwg
13:23:28 [Ian]
..for this spec you mentioned the point about differentiating debit and credit
13:23:36 [Ian]
...and why it's a useful feature for some scenarios
13:23:40 [Ian]
..and complexities around other matching
13:23:51 [kriske]
kriske has joined #wpwg
13:23:58 [kriske]
present+ kriske
13:24:13 [Ian]
...given "cards" are special, I am leaning toward the approach where there is just one identifier for card payments
13:24:28 [Ian]
..and within the payment method specific data we can provide other data such as which networks are supported
13:25:18 [Ian]
...keep the URL matching simple and move extensibility elsewhere
13:25:32 [Ian]
...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 [AdrianHB]
q?
13:25:59 [manu]
q+ to mention "tags" vs. "hierarchy" of what the merchant wants.
13:26:19 [nicktr]
q?
13:26:20 [manu]
q-
13:26:49 [Ian]
MattS: SEPA also has some "required" fields requirements
13:27:14 [nicktr]
ack CyrilV
13:27:38 [Ian]
Cyril: Please note that EMV has some identifier schemes
13:27:41 [Ian]
..for card payments
13:28:02 [brian_s]
q+
13:28:03 [Ian]
...we might want to refer to that work
13:28:23 [Nicolas_A_]
q+
13:28:27 [Ian]
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 [Ian]
ack bri
13:28:53 [Ian]
Nick: You can't necessarily rely on AIDs belonging to the networks that manage them
13:29:26 [manu]
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 [manu]
Ian: I can't tell whether you feel like it should be "I don't need this, don't bother."
13:30:39 [manu]
Ian: I hear you saying - "this may be a requirement, maybe we should pull it out into the Payment Request API"?
13:30:49 [manu]
Ian: Maybe, but not yet - that's my personal sense.
13:31:02 [manu]
MattS: We called it out in SEPA spec.
13:31:25 [Ian]
MattS: The basic card spec does not support PCI compliance well yet
13:31:29 [Nicolas_A_]
q-
13:31:32 [Ian]
..I think we also need to address that
13:31:40 [Ian]
NickTR: We have agreed we will do a tokenized spec
13:32:16 [Ian]
MattS: Who has an implementation of basic card?
13:32:19 [Ian]
Zach: We have
13:32:37 [Ian]
Andre: We are considering it
13:32:53 [Ian]
AdrianHB: This is our "bootstrap" spec
13:33:17 [Ian]
AdrianHB: It should be possible for a merchant to support basic card as an interim step before their existing payment page
13:33:21 [nicktr]
q?
13:33:23 [adrianba]
q+
13:33:50 [Ian]
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 [Ian]
ack me
13:34:17 [manu]
Ian: I heard a proposal from Matt to accept pull request - can we try to close that loop?
13:34:44 [zkoch]
q+
13:34:50 [adrianba]
q- later
13:34:52 [ben]
ben has joined #wpwg
13:34:54 [Ian]
PROPOSED: The basic card spec should support "required fields" specification from the merchant
13:35:00 [manu]
+1 to AdrianHB
13:38:03 [Ian]
pull request -> https://github.com/w3c/webpayments-methods-card/pull/4/commits/ba6c5c5d679596246db446ef3137f8adbffb5ecd
13:38:11 [AdrianHB]
+1
13:38:15 [manu]
+1
13:38:24 [Ian]
Zkoch: May want editorial work to make clear that this is input data.
13:38:28 [MattS]
MattS has joined #wpwg
13:38:33 [Roy]
Roy has joined #wpwg
13:38:34 [rouslan]
rouslan has joined #wpwg
13:38:47 [Ian]
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 [Ian]
...this seems like an unnecessary refinement
13:39:01 [Ian]
+1 to the proposal
13:40:18 [Ian]
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 [Ian]
...depending on the card type, there are some fields and you have them you should return them.
13:40:51 [Ian]
...one thing that MattS is suggesting is that the security code that merchants may not request
13:40:52 [nick]
q+
13:41:07 [Laurent]
q+
13:41:09 [Faraz]
q+
13:41:11 [AndreaF]
AndreaF has joined #wpwg
13:41:33 [Ian]
...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]
conorhackett_wp has joined #wpwg
13:41:47 [yaso_]
yaso_ has joined #wpwg
13:41:47 [yaso__]
yaso__ has joined #wpwg
13:41:55 [Ian]
...each new requirement increases implementation and testing cost
13:42:11 [Ian]
...my position is that we can still be successful without this feature...we can add later
13:42:15 [nicktr]
ack zkoch
13:42:24 [Ian]
zkoch: In the case you return back more data than the merchant has requested you don't lose anything
13:42:42 [Ian]
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 [Ian]
zkoch: The case of "not getting data you need" is worse than "getting too much data beyond what you want"
13:44:26 [Ian]
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 [nicktr]
q?
13:44:40 [nicktr]
ack adrianba
13:45:04 [Ian]
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 [Ian]
...this is therefore a "nice to have" feature.
13:45:28 [Ian]
AdrianBA: You could add to the spec and we ignore it.
13:45:51 [nicktr]
ack nick
13:46:09 [Ian]
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 [Ian]
...the current proposal doesn't address some use cases
13:47:20 [nicktr]
q?
13:47:26 [Ian]
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 [Ian]
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 [Ian]
Nick: I think it's unlikely that user agents will know what to do for each payment method
13:48:35 [AdrianHB]
laurent: getting too much data may have compliance implications
13:48:39 [Ian]
Laurent: There's also a question about receiving sensitive data (e.g., PCI compliance) that you don't want
13:48:42 [AdrianHB]
... eg for PCI DSS
13:49:04 [nicktr]
ack Laurent
13:49:21 [Ian]
Laurent: So if you get more data than you want, it may harm your compliance
13:49:24 [Ian]
ack Faraz
13:50:13 [Ian]
Faraz: One alternative is to not query the customer if you recently gathered data from the user
13:50:22 [Ian]
...so there may be other ways to minimize friction
13:51:07 [Ian]
NickTR: I am not hearing consensus yet.
13:51:17 [Ian]
..therefore we will not resolve the issue in this session
13:51:19 [nicktr]
q?
13:51:41 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
13:53:39 [nicktr]
q?
13:53:45 [huwb]
huwb has joined #wpwg
13:53:55 [Ian]
{IJ wonders whether we should think about "optional" approach and see if that's easier to manage)
13:54:00 [Ian]
[Direct Credit]
13:54:35 [Ian]
http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/
13:55:08 [shepazu]
shepazu has joined #wpwg
13:55:19 [Ian]
MattS: As it is written, it is the SEPA Credit Transfer spec
13:55:53 [Ian]
...we stripped out non-SEPA stuff and also direct debit stuff
13:55:57 [Ian]
...we have narrowed the scope
13:56:24 [Ian]
...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 [Ian]
...in the SEPA CT case, the payment app initiates the payment
13:57:12 [Ian]
(the push version)
13:57:33 [nicktr]
q+
13:57:43 [Ian]
..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 [Ian]
...this is a case where the payment method absolutely needs input fields
13:58:27 [zkoch]
q+
13:59:13 [Ian]
MattS: Do people feel that collaboration diagrams are a better way of diagramming than a sequence diagram?
13:59:13 [Laurent]
+1 to collaboration diagram
13:59:20 [Adam__]
Adam__ has joined #wpwg
13:59:21 [zkoch]
+0 I have no idea what those mean
13:59:23 [zkoch]
:)
13:59:23 [nicktr]
0 because I like both
13:59:26 [pirouz]
+1
13:59:35 [jyrossi]
+1
13:59:37 [AdrianHB]
+0 (-1 maybe because I like sequence diagrams)
13:59:42 [manu]
I don't think the diagrams help all that much (the ones in the spec right now)
13:59:43 [ShaneM]
+0 I also like both
13:59:44 [VincentK]
+1 Collaboration diagram
13:59:45 [Ian]
I don't know what collaboration diagram v. sequence
14:00:03 [conorhackett_wp]
0
14:00:06 [conorhackett_wp]
+0
14:00:14 [adamR]
-1 — sequence diagrams make information flow much clearer, IMHO (although I appear to be in the minority here)
14:00:22 [Ian]
NickTR: SEPA Pull anticipates something we've not seen in the wild yet....
14:00:41 [Ian]
MattS: I think this points at PSD2
14:00:58 [Ian]
DavidBirch: In the UK payments version of this this is called "request to pay"
14:01:16 [Ian]
...maybe avoid the phrase "pull" since that might create some confusion
14:01:44 [AdrianHB]
q?
14:01:46 [Ian]
MattS: I am ok to refactor to common vocabulary; our focus was more on SEPA and using that terminology
14:01:48 [nicktr]
ack nicktr
14:02:28 [Ian]
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 [Ian]
...I think credit transfer may become a bigger part of the landscape
14:02:53 [Ian]
...so I think it's worth investing the effort
14:02:54 [nicktr]
ack zkoch
14:03:18 [Ian]
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]
emschwartz has joined #wpwg
14:03:47 [Ian]
Cyril: for cards, all merchants are connected to acquirers, so it works
14:04:08 [Ian]
...for credit transfer .... if someone wants to develop a SEPA app, it may be a bank for its own customers
14:04:24 [Ian]
...the API needs to be secure (with auth, etc.)
14:04:58 [Ian]
..the idea of PSD2 is to generalize the mechanism so that any type of regulated entity can have access
14:05:27 [Ian]
zkoch: So it's more regulated
14:05:48 [AdrianHB]
q?
14:05:53 [Ian]
MattS: Part of PSD2 is the open banking API....
14:06:24 [Ian]
DavidBirch: there is strong support for the open api framework
14:06:53 [Ian]
nickTR: You can build third party apps to log into an online banking Api that lets you do credit transfers
14:06:58 [jyrossi]
q+
14:07:24 [Ian]
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 [Ian]
DavidBirch: This is being mandated in Europe
14:07:42 [manu]
q+ to make a few comments on spec - flows are too detailed, align vocabulary.
14:07:57 [Ian]
zkoch: The input and responses to these are well-defined by regulatory bodies
14:08:35 [nicktr]
q?
14:08:50 [Ian]
zkoch: What is added value of our own specs if these are specified elsewhere?
14:09:00 [fdold]
fdold has joined #wpwg
14:09:34 [Ian]
MattS: The spec (5.1) does reference the SEPA rule book.
14:09:42 [Ian]
...not every thing from the SEPA rule book is required
14:09:53 [Ian]
...we've also turned terms into what we think will be more developer-friendly
14:10:04 [Ian]
q+
14:10:30 [Ian]
DavidBirch: IN the UK and in EU environment, the likely implementation of this....
14:10:34 [Ian]
...will be done through directories
14:10:45 [Ian]
...I want to illustrate that in the final version will be more user-friendly
14:10:56 [Ian]
...you won't type things in
14:11:12 [Ian]
..just to illustrate why we should be thinking about this use cases
14:11:37 [Ian]
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 [nicktr]
q?
14:12:09 [Ian]
ack jy
14:12:19 [Ian]
jyrossi: The ecosystem has been created through regulation...it's a work in progress
14:12:41 [Ian]
q+ DavidBirch
14:13:21 [Ian]
ack manu
14:13:21 [Zakim]
manu, you wanted to make a few comments on spec - flows are too detailed, align vocabulary.
14:14:07 [Ian]
Manu: Regarding diagram in the SEPA spec...I appreciate that amount of detail, but I think it's "too much"
14:14:18 [Ian]
...for the spec...I think it would be ok to link to it...or a simpler diagram
14:14:26 [Ian]
...also, the vocabulary that's used in the messages
14:14:58 [Ian]
...it would be good to get consistency across specs (e.g., how we express input and output across the specs)
14:15:22 [AdrianHB]
q?
14:15:26 [Ian]
...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 [AdrianHB]
q+ to discuss code conventions and commonality across payment method specs
14:17:38 [nicktr]
ack Ian
14:18:16 [Max]
Max has joined #wpwg
14:18:45 [kriske]
q+
14:20:30 [nicktr]
q+
14:20:54 [jyrossi]
q+
14:21:01 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
14:21:03 [nick]
+1, I would also like to discuss the AliPay spec
14:21:24 [Ian]
ack DavidBirch
14:21:40 [Ian]
DavidBirch: The EBA is not creating technical specs
14:22:24 [Ian]
IJ: When are EBA requirements coming out?
14:22:32 [Ian]
NickTR/DavidBirch: This month
14:22:44 [nicktr]
ack AdrianHB
14:22:44 [Zakim]
AdrianHB, you wanted to discuss code conventions and commonality across payment method specs
14:23:02 [Ian]
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 [Ian]
[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 [Nicolas_A_]
q+
14:23:49 [Ian]
AdrianHB: Our payment method specs say what data is necessary to initiate or send back a payment request/response
14:24:00 [nick]
nick has joined #wpwg
14:24:07 [Ian]
...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 [Ian]
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 [nicktr]
+1 to AHB - we need to write some of things to find the generalisations
14:25:00 [Ian]
...even if three different payment methods require addresses, there may be specifics per payment method
14:25:09 [nicktr]
q?
14:25:21 [Ian]
+! to not trying to harmonize up front (but keeping it in mind for later)
14:25:23 [nicktr]
ack kriske
14:25:26 [Ian]
ack kriske
14:25:52 [Ian]
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 [Ian]
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 [Ian]
...if they are not the same types, some magic will have to happen somewhere (mapping)
14:26:45 [nicktr]
akc nicktr
14:26:46 [Ian]
...we need to have these types interoperable
14:26:50 [Ian]
zakim, close the queue
14:26:50 [Zakim]
ok, Ian, the speaker queue is closed
14:26:50 [nicktr]
ack nicktr
14:27:02 [Ian]
nicktr: I am a very strong +1 that we define these payment methods
14:27:12 [Ian]
...the reason that they are instructive are they let us examine other specifications closely
14:27:23 [Ian]
..and ensure the underlying specs are not card-specific
14:27:47 [nicktr]
ack jyrossi
14:27:54 [Ian]
...we want the Web spec to be usable all over the world
14:28:15 [jiajia]
jiajia has joined #wpwg
14:28:27 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
14:28:47 [jiajia]
jiajia has left #wpwg
14:28:56 [Ian]
jyrossi: +1 to making sure we look at these flows
14:29:09 [jiajia]
jiajia has joined #wpwg
14:29:19 [Ian]
...I think we should continue to study SEPA Direct Debit (which was pulled out of the SEPA CT spec yesterday)
14:29:37 [nicktr]
q?
14:29:54 [Ian]
DavidBirch: I think we should not pay attention to direct debit
14:30:07 [Ian]
...to susceptible to fraud
14:30:22 [Ian]
ack Ni
14:30:45 [CyrilV]
q+
14:30:49 [Ian]
Nicolas_A_: Credit transfers are not just the future; e.g., in NL 90% use credit transfer today
14:31:14 [CyrilV]
SDD is still in use in EUROPE. Thanks for us.
14:31:23 [Ian]
[Alipay]
14:31:35 [nick]
q+ once Alipay and Ian have done the intros / explainer
14:31:44 [rouslan]
rouslan has joined #wpwg
14:32:15 [Ian]
zakim, open the queue
14:32:15 [Zakim]
ok, Ian, the speaker queue is open
14:32:19 [nick]
q+
14:32:22 [Ian]
Alipay spec (without diagram) -> https://w3c.github.io/webpayments/proposals/Alipay-payment-method.html
14:32:22 [Max]
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]
fdold has joined #wpwg
14:32:44 [fdold_]
fdold_ has joined #wpwg
14:32:48 [nicktr]
zakim, open the queue
14:32:48 [Zakim]
ok, nicktr, the speaker queue is open
14:33:13 [nicktr]
q?
14:33:23 [Ian]
Max: I think Alipay is similar to other third party payment methods
14:33:30 [Ian]
[Max reviews the flow]
14:33:43 [Ian]
....user can select Alipay as a payment method
14:34:37 [Ian]
..alipay server sends synchronized message to the browser
14:34:42 [Ian]
...and async message to the merchant server
14:34:49 [Ian]
...merchant can confirm payment using either one
14:36:41 [Ian]
...another comment that I think is valid for other similar payment methods
14:37:11 [Ian]
...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 [Ian]
...sometimes the third party payment provider may have customized UI
14:37:41 [nicktr]
q+ to note redirect URL could be part of the registration
14:37:54 [rouslan]
q+
14:38:11 [nicktr]
q-
14:38:16 [manu]
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 [nicktr]
ack nick
14:38:27 [Ian]
q+ to talk about other user experience topics
14:38:54 [Ian]
nickS: Why are there fields that overlap with payment request API
14:38:54 [adrianba]
https://w3c.github.io/webpayments/proposals/Alipay-payment-method.html
14:39:19 [manu]
q+ to ask how signatures are created over this information? Is it in the spec?
14:39:26 [Ian]
Max: This was our first try, so if there are params in payment request API, then we should not duplicate them
14:39:35 [Ian]
ack rou
14:39:49 [Ian]
rouslan: Thanks for producing the draft! You put "charset" in there
14:39:54 [Ian]
...javascript is almost always Unicode 16
14:40:04 [Ian]
...do you use input charset for other purposes than communicating with the browser?
14:40:40 [Ian]
Max: We support multiple encodings...UTF8 is popular for some customers
14:40:49 [Ian]
Rouslan: Some of these fields might need some examples
14:41:10 [Ian]
...do you have links to original documentation? ...suggest links to official documentation
14:41:12 [Ian]
Ian: +1
14:41:18 [nicktr]
q?
14:41:24 [manu]
q-
14:41:26 [nicktr]
ack Ian
14:41:26 [Zakim]
Ian, you wanted to talk about other user experience topics
14:41:36 [manu]
q+ to ask about how signatures are used.
14:42:17 [nicktr]
q+ to propose that we take up the alipay specification as a working group work item
14:42:26 [manu]
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 [MattS]
q?
14:43:17 [nicktr]
q?
14:43:18 [manu]
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 [nicktr]
q?
14:43:52 [manu]
zkoch: We've been talking about this - direct passthrough, there are circumstances under which it might make sense.
14:44:07 [manu]
Ian: I mention that to bring up - we would probably not specify, but we could call that out.
14:44:36 [manu]
nicks: Another use case - today, many merchants have paid placement agreements.
14:45:05 [manu]
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 [manu]
Ian: You might say "I accept payment app registrations", facilitating registration so that the user has to do even less.
14:46:07 [manu]
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 [zkoch]
q+
14:46:35 [manu]
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 [nicktr]
ack zkoch
14:47:09 [dka]
q+
14:47:31 [manu]
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 [CyrilV]
q+
14:47:56 [manu]
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 [manu]
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... <these other payment methods>"
14:49:01 [manu]
Ian: So, what merchants what might like.
14:49:05 [MattS]
q?
14:49:07 [MattS]
q?
14:49:17 [nicktr]
q- later
14:49:37 [manu]
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 [Max]
q+
14:50:35 [manu]
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 [manu]
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 [nicktr]
q+ to note merchant feedback on coupons and loyalty
14:51:42 [manu]
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 [manu]
ack manu
14:51:43 [Zakim]
manu, you wanted to ask about how signatures are used.
14:51:51 [Ian]
Manu: Alipay spec uses signatures
14:52:04 [Ian]
...both merchant-initiated and Alipay response signatures
14:52:07 [Ian]
...can you say why?
14:52:26 [Ian]
Max: We want to ensure that message is actually coming from Alipay (or from merchant)
14:52:50 [Ian]
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 [Ian]
Max: HTTPS can only secure the channel, not the content of the message, so we sign the data as well
14:53:42 [Ian]
zkoch: Is it similar to the way that Apple Pay does merchant validation?
14:54:48 [nicktr]
zakim, close the queu
14:54:48 [Zakim]
I don't understand 'close the queu', nicktr
14:54:49 [Ian]
Max: Yes
14:54:51 [nicktr]
zakim, close the queue
14:54:51 [Zakim]
ok, nicktr, the speaker queue is closed
14:55:06 [Ian]
q?
14:55:26 [Ian]
ack dka
14:55:46 [Ian]
danielA: Ian, I wanted to respond to something you said earlier about making it easier for payment apps to be registered
14:56:09 [nicktr]
q- later
14:56:29 [manu]
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 [manu]
dka: I'm very concerned about that.
14:56:52 [manu]
dka: A payment app by itself is powerful, it can reach into your device - it's active, not inert.
14:57:04 [manu]
Ian: All that's being given to the browser is just information about the app.
14:57:23 [nicktr]
q?
14:57:37 [manu]
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 [Ian]
daniel: I am concerned about registration security...e.g., a fingerprinting issue
14:57:38 [manu]
dka: it could still be a fingerprinting issue.
14:57:47 [Ian]
ack Cyr
14:58:08 [Ian]
CyrilV: Ian, I want to comment about what you said about authentication....this is a key security component for payment
14:58:30 [Ian]
...so far authentication for card schemes is accepted by the card schemes (including ways like Apple Pay)
14:58:38 [Ian]
...that's because responsibilities are clear
14:58:53 [Ian]
...and there are regulatory obligations as well (e.g., 2factor with exceptions)
14:59:03 [dka]
cf TAG finding on unsanctioned tracking https://www.w3.org/2001/tag/doc/unsanctioned-tracking/
14:59:11 [Ian]
...we should leave authentication issues to the payment mechanism
14:59:20 [nicktr]
q?
14:59:37 [nicktr]
ack Max
15:00:11 [Ian]
Max: Regarding HTTPS, we don't use it to authenticate the merchant...rather the merchant authenticates directly to our server
15:00:46 [Ian]
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 [Ian]
{IJ thinks this will be supported]
15:01:01 [nicktr]
ack nicktr
15:01:01 [Zakim]
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 [Ian]
NickTR: When I talk to merchants, they are really enthusiastic about coupons in payment apps
15:01:57 [Ian]
NickTR: Second point I want to make is that we take up Alipay spec as a payment method spec
15:02:22 [Ian]
PROPOSED: The WG should take up the Alipay payment method spec to published as a W3C Note
15:02:33 [Ian]
AdrianBA: I object to that.
15:03:05 [Ian]
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 [Ian]
...as a way of taking forward the original flows work in a more concrete way
15:03:32 [Ian]
...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 [Roy]
q+
15:03:46 [Ian]
...that in fact we should be encouraging a practice where vendors publish them
15:03:51 [Ian]
zakim, open the queue
15:03:51 [Zakim]
ok, Ian, the speaker queue is open
15:03:53 [Ian]
q+ Roy
15:04:13 [Max]
q+
15:04:20 [nick]
+1, I think it could rapidly become unmanageable
15:04:22 [Ian]
...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 [Ian]
ack Roy
15:04:50 [Ian]
Roy: I have the same concern expressed by AdrianBA
15:05:01 [AdrianHB]
q+
15:05:02 [Ian]
...I question whether this is the best medium for exploring payment methods
15:05:18 [manu]
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 [Ian]
...should we use a lighter weight approach to producing the spec than a WG?
15:05:24 [nicktr]
ack Max
15:05:44 [manu]
q+ or send them to a Payment Method Community Group.
15:05:45 [Ian]
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 [manu]
q+ to say or send them to a Payment Method Community Group.
15:05:56 [Ian]
...what's the difference between that and other payment methods?
15:06:10 [Ian]
AdrianBA: I plan to propose that we remove PMIs from the basic card spec
15:06:17 [Ian]
...but I haven't had time
15:06:40 [Ian]
...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 [Ian]
...I agree it's problematic to have only some brands in the basic card spec or not
15:06:59 [Ian]
ack adrianhb
15:07:15 [Ian]
Max: Maybe we should attempt a generic approach
15:07:24 [MattS]
q+
15:07:28 [Ian]
AdrianHB: It could be valuable to see whether there is commonality among different types of payment methods
15:07:33 [adrianba]
q+
15:07:39 [Ian]
...we may find that there are commonalities and it's worth creating a standard
15:07:52 [Roy]
q+
15:07:56 [Ian]
adrianhb: I appreciate the concern about publishing vendor-specific specs
15:08:06 [Ian]
...I think we could even call it a "push payment" spec
15:08:24 [Ian]
...e.g., where there's a merchant id and a call back URL and a transaction id
15:08:31 [Ian]
...this might help us avoid massive fragmentation
15:08:50 [AdrianHB]
q-
15:09:26 [Ian]
ack Manu
15:09:26 [Zakim]
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 [Zakim]
... to a Payment Method Community Group.
15:09:36 [Max]
q+
15:10:07 [Ian]
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 [rouslan]
q+
15:10:31 [Ian]
...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 [MattS]
+1 to Manu
15:10:39 [nicktr]
+1 for working on the illustrative specs in this group
15:10:42 [rouslan]
+1 to manu
15:10:47 [Laurent]
+1 to manu
15:10:47 [MattS]
q-
15:10:48 [Ian]
ack M
15:10:54 [nicktr]
ack adrianba
15:10:54 [Nicolas_A_]
+1 to manu
15:10:54 [Ian]
queue=Roy,Max,rouslan
15:11:21 [Ian]
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 [Ian]
IJ: we can just work on it in our github repo
15:12:16 [nicktr]
zakim, close the queue
15:12:16 [Zakim]
ok, nicktr, the speaker queue is closed
15:12:31 [Ian]
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 [manu]
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 [manu]
Ian: Should we do payment method spec guidance? Anyone want to volunteer for that?
15:13:41 [Ian]
ACTION: Max to work with Ian on starting some payment method good practice documentation.
15:13:41 [trackbot]
Error finding 'Max'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.
15:13:46 [Ian]
q?
15:13:49 [Ian]
ack roy
15:14:02 [ShaneM]
I would be happy to assist with the guidance document Ian and Max
15:14:05 [alyver]
Ian - happy to help with the Payment Method specs
15:14:07 [Ian]
Roy: One thing that stands out with this payment method is the push part
15:14:09 [rouslan]
q-
15:14:45 [Ian]
Roy: It would be interesting to look for commonalities among push payments
15:15:02 [fawad]
fawad has joined #wpwg
15:15:05 [nicktr]
q?
15:15:53 [adamR_]
adamR_ has joined #wpwg
15:16:47 [Ian]
rrsagent, make minutes
15:16:47 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
15:35:47 [nick]
nick has joined #wpwg
15:37:22 [rouslan]
rouslan has joined #wpwg
15:40:58 [dka]
dka has joined #wpwg
15:42:47 [rouslan]
rouslan has joined #wpwg
15:42:48 [lbolstad]
lbolstad has joined #wpwg
15:42:52 [lbolstad]
present+
15:44:00 [Roy]
Roy has joined #wpwg
15:44:33 [wseltzer]
zakim, code?
15:44:33 [Zakim]
no conference has been identified yet, wseltzer
15:44:59 [Max]
Max has joined #wpwg
15:46:36 [rouslan]
rouslan has joined #wpwg
15:46:38 [alyver]
alyver has joined #wpwg
15:47:19 [Ian]
topic: Security Review
15:47:29 [Ian]
https://lists.w3.org/Archives/Public/public-payments-wg/2016Jul/att-0013/WebpaymentsAPISecurityandPrivacyChecklist.pdf
15:47:38 [nicktr]
security review -> https://docs.google.com/document/d/1w7ginyzNg-xZUmITK4vzcGUKB4gbMOAvlkWWaRtX14k/edit?pli=1#
15:47:48 [Ian]
AdamR: We used the TAG checklist (still in development) to do a security review
15:47:58 [nicktr]
or pdf -> https://lists.w3.org/Archives/Public/public-payments-wg/2016Jul/att-0013/WebpaymentsAPISecurityandPrivacyChecklist.pdf
15:47:59 [Ian]
...Evgeny, Ian, and I developed answers to the questions
15:48:08 [zkoch]
zkoch has joined #wpwg
15:48:10 [Ian]
...we wanted today to go over the recommendations that resulted from the analysis
15:48:14 [wseltzer]
zakim, code?
15:48:14 [Zakim]
no conference has been identified yet, wseltzer
15:48:18 [fdold]
fdold has joined #wpwg
15:48:42 [nick]
nick has left #wpwg
15:48:49 [nick]
nick has joined #wpwg
15:48:53 [nicktr]
Call in numbers are here, Wendy
15:48:53 [Ian]
3.1 Does this specification deal with personally-identifiable information?
15:48:55 [nicktr]
https://www-emea.intercallonline.com/listNumbersByCode.action?confCode=875114&area=viewNumber
15:49:05 [nicktr]
and conference code is 875114
15:49:14 [nicktr]
q?
15:49:15 [Ian]
AdamR: We recommend for this one enhancing privacy considerations of Payment Request API spec
15:49:21 [nicktr]
ack Max
15:49:25 [nicktr]
zakim, open the queue
15:49:25 [Zakim]
ok, nicktr, the speaker queue is open
15:49:27 [Max]
q-
15:50:12 [wseltzer]
present+ wseltzer
15:50:58 [MattS]
MattS has joined #wpwg
15:51:12 [Ian]
3.2 Does this specification deal with high-value data?
15:52:14 [zkoch]
q+
15:52:30 [ben]
ben has joined #wpwg
15:53:12 [AdrianHB]
q+
15:53:44 [Ian]
zkoch: I am not sure that it's our place to tell businesses where to store or not store credentials.
15:53:52 [nicktr]
akc zkoch
15:53:56 [Ian]
...I want to push back on PCI specifically
15:53:56 [nicktr]
ack zkoch
15:54:02 [Ian]
...this is governed outside of us
15:54:20 [Ian]
..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 [Ian]
AdamR: The card spec strongly encourages storing credit card information...a casual read might suggest that is best practice
15:54:54 [Ian]
...I think that we need to highlight that that is NO LONGER a best practice given the payment request API
15:55:07 [Ian]
...and we should not have flows or language that Encourage storage
15:55:22 [Ian]
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 [Ian]
q?
15:55:55 [Ian]
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 [Ian]
zkoch: I am ok with that...expressing goals and implying that storage is no longer
15:56:16 [Ian]
adamr: That sounds good
15:56:59 [Ian]
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 [wseltzer]
+1 to saying something
15:57:18 [wseltzer]
to alert people to the security consideration
15:57:19 [Ian]
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 [Ian]
adrianhb: I support the approach were we are explicit that we are not making PCI go away
15:58:25 [nicktr]
q?
15:58:30 [Ian]
ack ad
15:58:55 [Ian]
3
15:58:55 [Ian]
.
15:58:55 [Ian]
4
15:58:55 [Ian]
D
15:58:56 [Ian]
o
15:58:57 [Ian]
e
15:58:58 [Ian]
s
15:59:00 [Ian]
t
15:59:02 [Ian]
h
15:59:04 [Ian]
i
15:59:06 [Ian]
s
15:59:08 [Ian]
s
15:59:10 [Ian]
p
15:59:14 [Ian]
e
15:59:16 [Ian]
c
15:59:18 [Ian]
i
15:59:20 [Ian]
f
15:59:22 [Ian]
i
15:59:24 [Ian]
c
15:59:26 [Ian]
a
15:59:28 [Ian]
t
15:59:30 [Ian]
i
15:59:32 [Ian]
o
15:59:34 [Ian]
n
15:59:36 [Ian]
e
15:59:38 [Ian]
x
15:59:40 [Ian]
p
15:59:44 [Ian]
o
15:59:46 [Ian]
s
15:59:48 [Ian]
e
15:59:50 [Ian]
p
15:59:52 [Ian]
e
15:59:54 [Ian]
r
15:59:56 [Ian]
s
15:59:58 [Ian]
i
16:00:00 [Ian]
s
16:00:02 [Ian]
t
16:00:04 [Ian]
e
16:00:06 [Ian]
n
16:00:08 [Ian]
t
16:00:10 [Ian]
,
16:00:14 [Ian]
c
16:00:16 [Ian]
r
16:00:18 [Ian]
o
16:00:20 [Ian]
s
16:00:22 [Ian]
s
16:00:24 [Ian]
-
16:00:26 [Ian]
o
16:00:28 [Ian]
r
16:00:30 [Ian]
i
16:00:32 [Ian]
g
16:00:34 [Ian]
i
16:00:36 [Ian]
n
16:00:38 [Ian]
s
16:00:40 [Ian]
t
16:00:42 [nick]
💩
16:00:44 [Ian]
a
16:00:46 [Ian]
t
16:00:48 [Ian]
e
16:00:50 [Ian]
t
16:00:52 [Ian]
o
16:00:54 [Ian]
t
16:00:56 [Ian]
h
16:00:58 [Ian]
e
16:01:00 [Ian]
w
16:01:02 [Ian]
e
16:01:04 [Ian]
b
16:01:06 [Ian]
?
16:01:08 [Ian]
3.4 Does this specification expose persistent, cross-origin state to the web?
16:01:14 [Ian]
AdamR: We recommended adopting the "required fields" PR for privacy reasons
16:01:14 [nicktr]
q?
16:01:16 [Ian]
AdamR: We also think that there should be some consideration to exposing some sort of tracking potential to the user
16:01:19 [Ian]
...from a UX perspective
16:02:42 [Ian]
IJ: Any other examples of alerting the user that "by doing this there may be privacy implications"?
16:03:00 [nicktr]
q?
16:03:24 [Ian]
Wseltzer: Check out TAG guidance on unsanctioned tracking
16:03:25 [AdrianHB]
q+
16:03:32 [wseltzer]
https://www.w3.org/2001/tag/doc/unsanctioned-tracking/
16:03:49 [Ian]
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 [Ian]
...is the difference that there is less friction?
16:04:05 [Ian]
AdamR: Furthermore it's potentially automated.
16:04:38 [rouslan]
rouslan has joined #wpwg
16:05:03 [wseltzer]
q+
16:05:09 [nicktr]
ack AdrianHB
16:05:29 [wseltzer]
q+ to ask if the tracking comes from exposing addtional information apart from credit card
16:06:05 [Ian]
IJ: question is whether to give users a slights head-up given ease of transaction
16:06:18 [Ian]
AdamR: Also notice that other payment methods will reduce traceability
16:06:23 [wseltzer]
q-
16:06:25 [manu]
For those that haven't seen this - it's really interesting/scary: https://panopticlick.eff.org/
16:06:38 [Ian]
Nick: Note that in EMV tokens are persistent
16:06:51 [Ian]
..the token PAN is the same (e.g., from Apple Pay) every time
16:07:02 [Ian]
NickS: The token is the same; what changes is the bit that embeds the amount
16:07:07 [rouslan]
rouslan has joined #wpwg
16:07:14 [Ian]
..[with apple pay] the token is different across devices, however
16:07:21 [wseltzer]
-> https://www.w3.org/TR/2015/NOTE-fingerprinting-guidance-20151124/ PING note on Fingerprinting Guidance
16:07:34 [Ian]
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 [Ian]
nickS: I think this is a reasonable concern. I think the answer is to let the user know they can disable
16:08:37 [Ian]
adamr: I don't think payment request API is the right place
16:09:27 [manu]
q+ to focus on more important security issues (that review didn't catch, imho)
16:10:12 [Ian]
IJ: Should this be in payment app spec?
16:10:15 [Laurent]
Laurent has joined #wpwg
16:10:30 [Ian]
adrianhb: May not suffice...also makes sense for card payments in payment request
16:11:02 [Ian]
RESOLVED: Add an issue on the privacy considerations
16:11:28 [Ian]
ACTION: Ian to work with AdamR and Jonny on raising an issue about privacy notifications about sharing identifiable information
16:11:29 [trackbot]
'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ijacobs, ijmad).
16:11:40 [nicktr]
q?
16:11:43 [nicktr]
ack manu
16:11:43 [Zakim]
manu, you wanted to focus on more important security issues (that review didn't catch, imho)
16:11:45 [Ian]
q+
16:12:27 [rouslan]
rouslan has joined #wpwg
16:12:34 [AdrianHB]
manu: we need to talk about man in the middle attacks
16:12:50 [AdrianHB]
nick: isn't that a payment method specific concern
16:12:52 [rouslan]
rouslan has joined #wpwg
16:13:28 [AdrianHB]
manu: not only. There are aspects of the request which can still be subject to attack
16:13:39 [AdrianHB]
nick: how would you secure a basic card payment?
16:13:58 [AdrianHB]
manu: a signature on the whole message?
16:14:01 [nicktr]
q?
16:14:01 [AdrianHB]
q+
16:14:06 [nicktr]
ack Ian
16:14:47 [AdrianHB]
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 [AdrianHB]
manu: we need to talk to experts?
16:15:24 [AdrianHB]
ian: this is happening inside member companies. no opposition to soliciting other reviews
16:15:52 [rouslan]
rouslan has joined #wpwg
16:16:01 [Ian]
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 [Ian]
...I like the report that I'm seeing; it's a good validation of the process
16:16:27 [nicktr]
q+
16:16:44 [Ian]
ack nick
16:17:14 [Ian]
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 [Ian]
...I'm happy to sponsor a task force within this WG
16:17:30 [Ian]
q?
16:17:37 [manu]
q+ to start tracking attacks in "Security" document.
16:18:01 [AdrianHB]
q?
16:18:08 [AdrianHB]
q-
16:18:20 [Ian]
ACTION: NickTR to try to get a security review organized within Worldpay
16:18:20 [trackbot]
Created ACTION-21 - Try to get a security review organized within worldpay [on Nick Telford-Reed - due 2016-07-14].
16:18:29 [Ian]
ACTION: Huw to try to get a security review within Amex
16:18:29 [trackbot]
Error finding 'Huw'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.
16:18:44 [Ian]
ACTION: Cyril to try to get a security review within BPCE
16:18:44 [trackbot]
Created ACTION-22 - Try to get a security review within bpce [on Cyril VIGNET - due 2016-07-14].
16:18:59 [Ian]
NickTR: I think that security reviews are largely going to be payment method specific.
16:19:03 [Ian]
s/NickTR/NickS
16:19:17 [Ian]
...it will be beneficial for those with payment methods to consider how they might mitigate security concerns
16:19:25 [rouslan]
rouslan has joined #wpwg
16:19:27 [Ian]
AdrianHB: I think our priority will be generic payment methods
16:19:31 [nicktr]
q?
16:19:36 [Ian]
ack Manu
16:19:36 [Zakim]
manu, you wanted to start tracking attacks in "Security" document.
16:19:51 [Ian]
Manu: I would feel much better if the group were to track potential attacks against the API and document those
16:20:12 [wseltzer]
q+
16:20:16 [AdrianHB]
q+ to propose a wiki page
16:20:18 [Ian]
...for a man-in-the-middle attack in a card payment, here's what we do or don't do
16:20:20 [Ian]
q?
16:20:21 [wseltzer]
q- later
16:20:44 [CyrilV]
q?
16:20:51 [Ian]
Manu: We need to record the knowledge
16:20:54 [Ian]
Ack Ad
16:20:54 [Zakim]
AdrianHB, you wanted to propose a wiki page
16:21:11 [Ian]
adrianhb: I am prepared to create a page to track this stuff, and to organize the information by payment method
16:21:19 [ShaneM]
assemble the knowledge in a wiki! Maybe at some point publish a Note
16:21:25 [Ian]
ACTION: AdrianHB to create a resource that speaks to security topics
16:21:26 [trackbot]
Error finding 'AdrianHB'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.
16:21:52 [nicktr]
q?
16:21:56 [Ian]
...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 [nicktr]
ack wseltzer
16:21:59 [Ian]
ack wseltzer
16:22:15 [Ian]
wseltzer: I like the thought that I'm hearing going ... thanks to the group for taking on that work
16:22:26 [manu]
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 [Ian]
...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 [wseltzer]
https://tools.ietf.org/html/rfc3552
16:23:12 [brian_s]
brian_s has joined #WPWG
16:23:12 [Ian]
wseltzer: With respect to protocol design, see IETF guidance on security considerations
16:23:24 [Ian]
q?
16:23:41 [manu]
IETF Guidelines for Security Considerations: https://www.ietf.org/rfc/rfc3552.txt
16:23:50 [Ian]
3.14 How should this specification work in the context of a user agent’s "incognito" mode?
16:24:38 [Ian]
AdamR: We think the api should work in incognito mode
16:24:54 [rouslan]
rouslan has joined #wpwg
16:24:54 [Ian]
...but since we've talked about the ability to grant permission to get a 1-click experience
16:25:08 [Ian]
...obviously that has some privacy implications especially in incognito mode
16:25:39 [Ian]
...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 [Ian]
[Review of existing incognito mode]
16:26:36 [Ian]
NickS: Apple Pay - We don't disclose information to the site that payment methods are available when in incognito mode
16:27:07 [rouslan]
rouslan has joined #wpwg
16:27:07 [Ian]
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 [Ian]
...I think what NickS says is about third party apps...and I agree we need to think hard about incognito mode
16:27:31 [AdrianHB]
q?
16:27:46 [ShaneM]
q+ to ask if it makes sense to even talk about this in a spec that does not talk about UI?
16:28:15 [AdrianHB]
q+ to ask about probing in general
16:28:22 [ShaneM]
q- in that case
16:28:23 [Ian]
adamR: Sites should not be able to easily know that a user is operating in incognito mode
16:28:27 [ShaneM]
q-
16:28:46 [Ian]
...there may also be ways to figure out what's going on (e.g., time required for a promise to return)
16:28:51 [nicktr]
q?
16:29:09 [Adam__]
Adam__ has joined #wpwg
16:29:13 [Ian]
..we also recommend that the web payment app operates in incognito mode as well
16:29:27 [Ian]
...we recommend that text be brought into the payment request API spec
16:29:39 [Ian]
..in some form
16:29:46 [ShaneM]
is there a generic term for "incognito mode" that is used in the W3C specs
16:29:55 [Ian]
(I don't know)
16:30:12 [Ian]
danielappelquist: There is no standard definition of a private browsing mode
16:30:23 [Ian]
...we wonder whether there should be such a definition
16:30:32 [ShaneM]
hey wendy - have your group(sP define that for us, would you?
16:30:47 [ShaneM]
s/\(sP/(s)/
16:30:57 [Ian]
3.16 Does this specification have a "Security Considerations" and "Privacy Considerations" section?
16:31:01 [ShaneM]
rrsagent, make minutes
16:31:01 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html ShaneM
16:31:15 [Ian]
AdamR: We think all the docs should have privacy/security considerations sections
16:31:29 [Ian]
...we do call out that the PMI spec should point to the security section of the URI spec
16:31:39 [Ian]
...so we need to augment privacy/security sections of the docs larger
16:31:46 [dka]
TAG open issue on private modes: https://github.com/w3ctag/spec-reviews/issues/101 (just FYI)
16:31:46 [Ian]
3.17 Does this specification allow downgrading default security characteristics?
16:32:17 [Ian]
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 [Ian]
NickTR: Can I ask that the task force will work on concrete proposals (issues or PRs)
16:33:01 [nicktr]
q?
16:33:42 [Ian]
IJ: I would like to set the expectation we'll have suggestions by 4 August
16:33:48 [Ian]
ack Adr
16:33:48 [Zakim]
AdrianHB, you wanted to ask about probing in general
16:34:03 [Ian]
adrianhb: I want to raise the point about probing.
16:34:10 [Ian]
...it comes up now and again as a kind of sideline topic
16:34:18 [Ian]
...we often thing of the API as something the site might call once
16:34:29 [Ian]
...but a site might use the API to farm user information
16:34:45 [Ian]
...we might want to note in the page we are starting privacy attacks that might be made through the API
16:35:10 [Ian]
...e.g., submitting payment requests 1 by 1, and the merchant trying things after silent failures to enforce ordering
16:35:14 [nicktr]
q
16:35:17 [nicktr]
Q?
16:35:19 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
16:35:41 [Ian]
NickTR: We will return to the meeting 8:30am tomorrow
16:36:48 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
17:07:03 [Max]
Max has joined #wpwg
17:13:50 [Max]
Max has joined #wpwg
17:20:36 [Max]
Max has joined #wpwg
17:30:48 [Max]
Max has joined #wpwg
17:34:27 [Max]
Max has joined #wpwg
17:40:57 [dka]
dka has joined #wpwg
17:43:55 [yaso_]
yaso_ has joined #wpwg
17:43:55 [yaso__]
yaso__ has joined #wpwg
18:04:03 [alyver]
alyver has joined #wpwg
18:21:41 [alyver]
alyver has joined #wpwg
18:37:12 [nick]
nick has joined #wpwg
19:37:29 [fdold]
fdold has joined #wpwg
19:39:33 [dka]
dka has joined #wpwg
21:25:25 [Max]
Max has joined #wpwg
22:14:20 [alyver]
alyver has joined #wpwg
22:19:00 [adamR]
adamR has joined #wpwg
23:32:51 [alyver]
alyver has joined #wpwg
06:47:46 [nicktr]
nicktr has joined #wpwg
07:21:19 [conorhackett_wp]
conorhackett_wp has joined #wpwg
07:33:45 [Max]
Max has joined #wpwg
07:36:32 [nicktr]
nicktr has joined #wpwg
07:38:06 [conorhackett_wp]
conorhackett_wp has joined #wpwg
07:38:21 [zkoch]
zkoch has joined #wpwg
07:38:23 [faraz]
faraz has joined #wpwg
07:38:25 [rouslan]
rouslan has joined #wpwg
07:40:43 [nick]
nick has joined #wpwg
07:42:58 [MattS]
MattS has joined #wpwg
07:43:19 [alyver]
alyver has joined #wpwg
07:44:13 [Nicolas_A_]
Nicolas_A_ has joined #wpwg
07:45:06 [fdold]
fdold has joined #wpwg
07:46:21 [alyver]
alyver has joined #wpwg
07:47:26 [AndreaF]
AndreaF has joined #wpwg
07:48:06 [pirouz]
pirouz has joined #WPWG
07:48:16 [Ian]
trackbot, start meeting
07:48:18 [trackbot]
RRSAgent, make logs public
07:48:20 [trackbot]
Zakim, this will be
07:48:20 [Zakim]
I don't understand 'this will be', trackbot
07:48:21 [trackbot]
Meeting: Web Payments Working Group Teleconference
07:48:21 [trackbot]
Date: 08 July 2016
07:48:28 [Ian]
zakim, this meeting spans midnight
07:48:28 [Zakim]
I don't understand 'this meeting spans midnight', Ian
07:48:34 [Ian]
zakim, this call spans midnight
07:48:34 [Zakim]
I don't understand 'this call spans midnight', Ian
07:48:35 [adamR]
adamR has joined #wpwg
07:48:41 [Ian]
zakim, logs span midnight
07:48:41 [Zakim]
I don't understand 'logs span midnight', Ian
07:48:47 [Ian]
zakim, span midnight
07:48:47 [Zakim]
I don't understand 'span midnight', Ian
07:49:26 [ShaneM]
zakim, this meeting spans midnight
07:49:26 [Zakim]
I don't understand 'this meeting spans midnight', ShaneM
07:49:41 [ShaneM]
rrsagent, this meeting spans midnight
07:49:58 [manu]
rrsagent, make minutes
07:49:58 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html manu
07:50:14 [Ian]
zakim, this meeting spans midnigh
07:50:14 [Zakim]
I don't understand 'this meeting spans midnigh', Ian
07:50:15 [Ian]
zakim, this meeting spans midnight
07:50:15 [Zakim]
I don't understand 'this meeting spans midnight', Ian
07:50:17 [Ian]
zakim, this meeting spans midnight.
07:50:17 [Zakim]
I don't understand 'this meeting spans midnight', Ian
07:50:29 [Ian]
zakim, meeting spans midnight.
07:50:29 [Zakim]
I don't understand 'meeting spans midnight', Ian
07:50:30 [Ian]
zakim, meeting spans midnight
07:50:30 [Zakim]
I don't understand 'meeting spans midnight', Ian
07:50:42 [zkoch]
present+ zkoch
07:51:17 [AjayR]
AjayR has joined #wpwg
07:53:04 [Laurent_]
Laurent_ has joined #wpwg
07:56:38 [Max]
Max has joined #wpwg
07:58:34 [manu]
Topic: Introductions and Agenda Bash
07:58:48 [Ian]
https://github.com/w3c/webpayments/wiki/Web-Payments-Working-Group-FTF-Meeting-%28July-2016%29
07:59:08 [Ian]
scribe: Ian
07:59:15 [Ian]
[We review updated agenda]
07:59:22 [VincentK]
VincentK has joined #wpwg
07:59:27 [MattS]
present+ MattS
07:59:34 [Ian]
present+ Ian
08:00:36 [alyver]
present+ alyver
08:00:49 [VincentK]
present+ VincentKuntz
08:00:50 [nick]
present+ nick
08:01:17 [VincentK]
present+
08:01:42 [jyrossi]
jyrossi has joined #wpwg
08:02:19 [nicktr]
q?
08:02:56 [manu]
present+ Manu
08:02:58 [ShaneM]
present+ ShaneM
08:02:59 [nicktr]
present+ nicktr
08:03:02 [Roy]
Roy has joined #wpwg
08:03:05 [adamR]
r+
08:03:06 [AdrianHB]
present+ AdrianHB
08:03:06 [lbolstad]
lbolstad has joined #wpwg
08:03:06 [conorhackett_wp]
present+ conorh_wp
08:03:11 [lbolstad]
present+
08:03:12 [rouslan]
present+ Rouslan
08:03:15 [Nicolas_A_]
present+
08:03:15 [Roy]
present+ Roy
08:03:16 [sebsg]
sebsg has joined #wpwg
08:03:19 [faraz]
faraz has joined #wpwg
08:03:20 [AndreaF]
present+ AndreaF
08:03:29 [sebsg]
present+ sebsg
08:03:38 [lbolstad]
present+ lbolstad
08:03:39 [Fawad]
Fawad has joined #wpwg
08:03:57 [ben]
ben has joined #wpwg
08:04:37 [brian_s]
brian_s has joined #WPWG
08:05:04 [adamR]
present+ adamR
08:05:11 [Fawad]
+1
08:05:21 [Dongwoo]
present+ Dongwoo
08:05:41 [CyrilV]
CyrilV has joined #wpwg
08:05:53 [CyrilV]
present+ Cyril Vignet
08:06:13 [Ian]
Topic: Explainer doc
08:06:14 [Ian]
https://w3c.github.io/webpayments/proposals/wparch/
08:07:42 [MattS]
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 [ShaneM]
MattS: thanks!
08:08:49 [nicktr]
q?
08:09:08 [nicktr]
q?
08:09:17 [ShaneM]
note that plantuml DOES have some support for this: http://plantuml.com/component.html
08:09:28 [Ian]
nickTR: I think there is some language alignment that needs to be done.
08:09:38 [Ian]
...by taking it up as a work item we agree we'll work on it
08:09:48 [Ian]
..I'd be interested in getting the perspectives from those relatively new to the group
08:09:50 [Ian]
...was it useful?
08:09:51 [Max]
q+
08:10:05 [Ian]
...for those of us who would be talking to clients, would this be a useful artifact?
08:10:10 [Ian]
ack m
08:10:18 [nicktr]
q?
08:10:27 [MaheshK]
MaheshK has joined #wpwg
08:10:37 [Ian]
Max: Clarification question - payment options/details/methods are shown as "layers" ... is layering intentional?
08:10:46 [Ian]
Manu: No, it was intended as a container
08:10:56 [fdold]
q+
08:11:01 [Ian]
...happy to clarify that if desired
08:11:09 [Ian]
ack fdold
08:11:24 [Ian]
Florian: I'm missing here the relationship between the payment request API and the HTTP API
08:11:38 [Ian]
Manu: I don't go into that detail in the diagram
08:11:48 [Ian]
(In figure 3)
08:12:17 [Ian]
...HTTP API or payment request API can be used to send messages.
08:12:19 [ShaneM]
q+ to affirm that an intro like this would be helpful for me when promoting our work
08:12:24 [Ian]
...are you saying you'd rather see it mentioned or not?
08:13:10 [Ian]
ack sh
08:13:10 [Zakim]
ShaneM, you wanted to affirm that an intro like this would be helpful for me when promoting our work
08:13:30 [Ian]
ShaneM: I talk about our work a lot; I find this useful.
08:13:31 [nicktr]
q?
08:13:47 [AdrianHB]
q?
08:13:48 [Ian]
...I would like to use it ... but only if blessed by the group
08:13:50 [AdrianHB]
q+
08:14:06 [Dongwoo]
+1 to ShaneM
08:14:40 [manu]
q+ to suggest strongly as a NOTE in W3C space
08:15:00 [nicktr]
Q?
08:15:05 [ShaneM]
REQUEST: can we update this https://w3c.github.io/webpayments/
08:15:23 [huwby]
huwby has joined #wpwg
08:16:01 [Ian]
q?
08:16:08 [Ian]
ack AdrianHB
08:16:19 [Ian]
IJ: I could see this as a Note, or web page, or slide deck
08:16:35 [Ian]
...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 [Ian]
AdrianHB: Agree with Ian on that point
08:16:52 [Ian]
...my concrete proposal is that the WG adopts this as an ED of a Note
08:17:03 [Ian]
PROPOSED: Take up the explainer as an ED of a NOTE
08:17:10 [manu]
q-
08:17:42 [Ian]
AdrianHB: It's important to change the title to something like "Web Payments Overview"
08:17:55 [AdrianHB]
+1
08:17:56 [manu]
+1
08:17:56 [adamR]
+1
08:17:57 [AndreaF]
+1
08:17:58 [fdold]
+1
08:17:58 [conorhackett_wp]
+1
08:17:59 [alyver]
+1
08:18:01 [Roy]
+1
08:18:01 [ShaneM]
+1 and I am open to a title
08:18:01 [lbolstad]
+1
08:18:01 [rouslan]
+1
08:18:02 [Laurent_]
+1
08:18:03 [Max]
+1
08:18:05 [Dongwoo]
+1
08:18:05 [zkoch]
+1
08:18:25 [Ian]
+0
08:18:39 [Ian]
Editors: Nick, Roy, AHB, Manu, Dapeng
08:18:58 [Ian]
[IJ appreciates the content; not 100% sure yet should be a Note hence +0]
08:19:15 [Ian]
topic: Payment Method Identifiers
08:19:49 [Ian]
PMI spec -> https://www.w3.org/TR/payment-method-id/
08:20:27 [Ian]
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 [jyrossi]
present+ Nicolas_A
08:20:47 [Ian]
...so we are looking at augmenting matching to satisfy these use cases:
08:20:59 [Ian]
===
08:21:00 [Ian]
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 [Ian]
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 [Ian]
===
08:21:02 [jyrossi]
present+ pirouz
08:21:21 [Ian]
AdrianHB: MattS and Ian and I have been looking at this closely; have contemplated a variety of proposals
08:21:40 [Ian]
...various proposals involving more computation by the browser, and other options forcing payment apps to do the work
08:22:00 [nicktr]
q?
08:22:03 [faraz]
faraz has joined #wpwg
08:22:32 [Nicolas_A_]
q+
08:22:45 [nick]
q+
08:23:16 [AdrianHB]
q+ to make a further observation
08:23:20 [brian_s]
brian_s has joined #WPWG
08:23:38 [adamR]
q+ to comment about “addressing differential pricing”
08:23:42 [zkoch]
-1 to needing to support second use case right now
08:23:44 [manu]
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 [nicktr]
q?
08:24:27 [AndreaF]
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 [brian_s]
q+
08:25:08 [Ian]
ack Nicolas_A_
08:25:09 [manu]
q+ to propose a potential solution
08:25:36 [Ian]
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 [zkoch]
q+
08:25:56 [Ian]
ack Nick
08:26:19 [Ian]
nick: These two use cases aren't quite the same ... the first use case (credit/debit) are two distinct payment instruments
08:26:28 [Ian]
...they are processed differently...
08:26:41 [Ian]
...the second use case (accepting cards from a particular country, or a corporate)
08:26:49 [Ian]
...they are not being processed differently...it's more a property of the card
08:27:08 [Ian]
...I think Manu is right that today these are supported (via payment method identifiers)
08:27:19 [Ian]
...we may not know whether a card is corporate / personal
08:27:25 [Ian]
...I think one is achievable, one is much harder
08:27:32 [AdrianHB]
Q+ Huw
08:27:35 [Ian]
ack AdrianHB
08:27:35 [Zakim]
AdrianHB, you wanted to make a further observation
08:28:05 [Ian]
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 [Ian]
..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 [Ian]
...so we may be able to address just cards today and learn for future use cases
08:29:12 [Ian]
AdamR: +1 to supporting differential pricing use case
08:29:47 [AdrianHB]
q?
08:29:50 [Ian]
IJ: Support here means "augmented mediator matching algorithm"
08:29:52 [AdrianHB]
ack AdamR
08:29:52 [Zakim]
adamR, you wanted to comment about “addressing differential pricing”
08:30:31 [Ian]
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 [Ian]
...I am wondering whether all that's missing now is a way to say "not"
08:31:04 [nick]
q+
08:31:36 [ShaneM]
q?
08:31:39 [ShaneM]
ack manu
08:31:39 [Zakim]
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 [Zakim]
... solution
08:31:50 [AdrianHB]
Ian: to have not, you need groups
08:32:19 [AdrianHB]
q?
08:32:29 [Ian]
Manu: You can define the groups in the card specs
08:32:47 [Ian]
...maybe you can get by with "not" and grouping semantics defined in the spec
08:33:07 [Ian]
IJ: You would need the spec to be able to expand over time to catch all the groups
08:34:09 [Ian]
Zkoch: I agree with Nick that there are two use cases here (1) credit/debit (2) various branding / subclassing
08:34:21 [Ian]
...I think we should support (1); I am less concerned about (2)
08:34:53 [Ian]
...payment request may not be able to support all the use cases at the tart
08:34:57 [Ian]
s/tart/start
08:34:58 [kriske]
kriske has joined #wpwg
08:35:02 [Ian]
q?
08:35:04 [kriske]
present+ kriske
08:35:05 [Ian]
ack brian_s
08:35:06 [alyver]
+1 to Zach (and Nick)
08:35:07 [Ian]
ack zkoch
08:35:10 [Ian]
ack Huw
08:35:19 [Ian]
ack nick
08:35:38 [Ian]
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 [Ian]
...not sure how we would list different charges
08:36:23 [Ian]
...this comes into play in cases of other payment methods where more information is known up front
08:36:34 [Ian]
...I think this is going to be needed for tokenized schemes
08:36:43 [Ian]
NickTR: The payment app could be doing that
08:37:11 [Nicolas_A_]
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 [Ian]
NickTR: BIN lookups are hard
08:38:03 [Ian]
IJ: how are implementers doing this?
08:38:13 [Ian]
Nick: For apple pay we get additional information from the network
08:38:25 [Ian]
...we don't get all the information that we've talked about today
08:38:45 [AdrianHB]
q?
08:38:47 [Ian]
..so we'd have to show the differential prices in brute form, and that list might be lengthy
08:38:53 [ShaneM]
https://en.wikipedia.org/wiki/Payment_card_number
08:38:59 [Ian]
NickTR: We will have a breakout on this at noon
08:39:31 [Ian]
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 [Ian]
...so we might only be able to do rudimentary lookup (e.g., of network)
08:40:10 [Ian]
...and we can fall back to the existing behavior which is the payment is rejected after some processing
08:40:12 [AndreaF]
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 [nick]
…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 [Ian]
NickTR: Some sophisticated pages are doing dynamic lookup
08:40:55 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
08:41:03 [Ian]
Topic: HTTP API/Core messages
08:41:23 [manu]
https://docs.google.com/presentation/d/1a3oiG8H4DMTwhC37BnkA-1OJ90NB2WcZQb12VphqVOo/edit#slide=id.p
08:41:26 [Ian]
Core messages -> https://w3c.github.io/webpayments-core-messages/
08:41:34 [Ian]
HTTP API -> https://w3c.github.io/webpayments-http-api/
08:42:47 [Ian]
Manu: Goal is to get to FPWD, or understand concerns
08:43:16 [Ian]
manu: Purpose of core messages spec is to understand what messages flow through the system
08:43:24 [nicktr]
q?
08:43:31 [Ian]
...payment request API is for interactive payments, HTTP API is for non-interactive payments
08:44:03 [Ian]
...core messages spec is split in two: general data model; then some different serialization options
08:46:25 [nicktr]
q+
08:48:58 [kriske]
q+
08:49:18 [AdrianHB]
q?
08:49:25 [Laurent_]
q+
08:49:26 [AdrianHB]
q+ to discuss 402
08:49:56 [Ian]
Demo -> * [7 July](https://www.w3.org/2016/07/07-wpwg-minutes)
08:50:14 [Ian]
/
08:50:36 [Ian]
demo -> http://http-mediator-demo.web-payments.io/
08:50:42 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
08:51:10 [Ian]
Manu: Do we want to publish these documents as FPWDs?
08:51:15 [ShaneM]
q?
08:51:24 [Ian]
...one critique of these specs is that they've not had as much attention on them
08:51:37 [Ian]
...an FPWD does not imply agreement to the content by the WG
08:51:45 [Ian]
ack ni
08:51:50 [Max]
q+
08:52:11 [Ian]
nickTR: Who was aware of this spec?
08:52:21 [Ian]
(just about everyone)
08:52:25 [Ian]
NickTR: Who has read it
08:52:27 [Ian]
(fewer people)
08:52:39 [Ian]
NickTR: Who thinks that there are valuable use cases?
08:52:58 [Ian]
(@@ was typing and did not see show of hands for that one@@)
08:53:05 [Ian]
ack kriske
08:53:16 [faraz]
q+
08:53:34 [AdrianHB]
q+ Faraz
08:53:40 [Ian]
q?
08:54:05 [Ian]
Kriske: How close is message to ISO20022?
08:54:16 [Ian]
Manu: That is a "native payment message" so it would be whatever is called for
08:54:54 [Ian]
Kriske: How will the resource be defined? As an ISO20022 structure? Or something proprietary?
08:55:11 [Ian]
Manu: This diagram is just one example; you can have other flows
08:55:20 [Ian]
...the question is for steps 9 and 10, who is defining and executing that?
08:55:26 [nicktr]
q?
08:55:27 [Ian]
I think 9 and 10 are out of scope for this group
08:55:29 [nicktr]
q+
08:55:40 [Ian]
Manu: I would expect it would be native to whatever payment network it's submitted to
08:55:59 [Ian]
Kriske: The reason I ask is that there are constraints imposed by the payment network
08:56:11 [Ian]
...if these pieces of information are not properly structured, the payment will fail
08:56:24 [Ian]
..it would be interesting for this proposal to take into account those requirements
08:56:33 [Ian]
...ISO20022 has taken that into account
08:56:53 [AdrianHB]
q?
08:57:00 [Ian]
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 [Ian]
ack Laurent
08:57:28 [Ian]
Laurent_: Do you take into account payment method extensibility?
08:57:36 [Ian]
...also do you have a push model for message 3 and 4?
08:57:52 [Ian]
q- nicktr
08:58:22 [Ian]
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 [AdrianHB]
q?
08:58:45 [Ian]
...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 [Ian]
Laurent: Do payment methods have to define something beyond what they do today to work with this API?
08:59:16 [Ian]
Manu: By design it should just work
08:59:24 [jyrossi]
q+
09:00:03 [nicktr]
ack AdrianHB
09:00:03 [Zakim]
AdrianHB, you wanted to discuss 402
09:00:04 [jyrossi]
q-
09:00:12 [Ian]
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 [Ian]
Manu: Yes
09:00:21 [Ian]
AdrianHB: The HTTP 402 use case is interesting.
09:00:58 [nicktr]
q?
09:01:23 [Ian]
...we should decide whether we want to use this spec as a way to respond to 402
09:01:37 [Ian]
...other activity in this space e.g., cryptocurrency folks
09:02:35 [Ian]
Manu: Had some discussion with Mark Nottingham about this...some pushback
09:02:50 [AdrianHB]
q?
09:02:58 [Ian]
...there would be need for more discussion with IETF
09:03:04 [Ian]
q+
09:03:08 [Ian]
Max: What is the security mechanism?
09:03:19 [Ian]
Manu: I assume it would be the same as used by the browser; right now seems to be HTTPS
09:03:33 [Ian]
..the HTTP API is following browser API (currently no signatures)
09:03:42 [Ian]
Max: What payment methods can you use?
09:03:53 [Ian]
Manu: Whatever payment method you want, as defined by the payment method specs
09:04:05 [Ian]
Max: Step #5....select payment app...is that interaction?
09:04:38 [Ian]
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 [Ian]
Max: In step #11, what happens if message does not reach the mediator?
09:04:58 [Ian]
Manu: Right now that's out of scope
09:05:13 [AdrianHB]
q?
09:05:17 [Ian]
...up to mediator...different approaches might be taken
09:05:19 [AdrianHB]
ack max
09:05:26 [Ian]
...I think that group has this question for the work we are doing
09:05:29 [Ian]
ack faraz
09:05:35 [Roy]
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 [AdrianHB]
yes
09:06:06 [Ian]
faraz: You are saying the HTTP API spec should support payment methods ... how would something like paypal work non-interactively?
09:06:23 [Ian]
Manu: Good point; if the payment method itself does not support automatic payments, then you could not achieve fully automatic payments
09:06:39 [Ian]
faraz: The same applies to entry of PAN
09:06:51 [Max]
q+
09:06:52 [Ian]
....I am hearing you say that unless PAN has been previously entered, this would not work
09:06:54 [Ian]
Manu: Correct
09:07:17 [ShaneM]
q?
09:07:22 [Roy]
q+
09:07:24 [Ian]
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 [AdrianHB]
q?
09:07:50 [ShaneM]
q+ to point out that there is an opportunity to use this even in a paypal model via "subscriptions"
09:07:52 [AdrianHB]
ian: what is the current state of implementor interest?
09:08:13 [faraz]
q+
09:08:24 [AdrianHB]
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 [AdrianHB]
nicktr: WorldPay are working on this in our IoT architecture
09:08:40 [AdrianHB]
q?
09:08:43 [Ian]
ack Ian
09:08:44 [Ian]
ack Max
09:08:51 [faraz]
Support for Tokenisation plus trid in core messages
09:09:05 [Ian]
Max: For the paypal use case, in this diagram I think the payee and the payment network are together
09:09:18 [Ian]
...so the message #3 and #4 will be very payment method specific
09:10:14 [Ian]
...3 and 4 may not be able to be simple HTTP POST...might require some additional parameters (e.g., credentials)
09:10:17 [Roy]
q-
09:10:42 [Ian]
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 [Ian]
[AHB shows a push payment variation via the screen]
09:11:59 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
09:11:59 [nick]
nick has joined #wpwg
09:12:06 [AdrianHB]
q?
09:12:10 [Ian]
ack shane
09:12:10 [Zakim]
ShaneM, you wanted to point out that there is an opportunity to use this even in a paypal model via "subscriptions"
09:12:13 [Ian]
zakim, close the queue
09:12:13 [Zakim]
ok, Ian, the speaker queue is closed
09:12:20 [Ian]
ack faraz
09:13:01 [Ian]
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 [Ian]
Manu: That's an aspiration; not enforced by the spec
09:13:08 [AdrianHB]
q?
09:13:11 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
09:14:50 [Ian]
[Review of process]
09:14:56 [AdrianHB]
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 [Ian]
q+
09:15:21 [AdrianHB]
zakim, open the queue
09:15:21 [Zakim]
ok, AdrianHB, the speaker queue is open
09:16:53 [AdrianHB]
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 [Ian]
zakim, open the queue
09:17:12 [Zakim]
ok, Ian, the speaker queue is open
09:17:25 [Ian]
NickTR: Show of hands whether you would likely be supportive of a call for consensus
09:17:36 [Laurent_]
+1
09:17:36 [Ian]
(Which will happen formally with a 1-week window)
09:17:39 [AndreaF]
+1
09:17:42 [adamR]
+0
09:17:42 [conorhackett_wp]
+1
09:17:43 [ShaneM]
+1 and agree that the chairs need to manage priorities
09:17:45 [AdrianHB]
+1
09:17:45 [kriske]
+1
09:17:46 [alyver]
+1
09:17:46 [zkoch]
+0
09:17:49 [manu]
+1 to issue call for consensus on HTTP API and Core Messages
09:17:50 [Roy]
0, still working to understand how it fits in
09:17:57 [nick]
+0
09:17:58 [rouslan]
+0 does not seem to affect browsers
09:17:58 [jyrossi]
+1
09:18:03 [Nicolas_A_]
+0
09:18:07 [MattS]
+1
09:18:07 [Ian]
(No +1's or -1's by hand in the room)
09:18:17 [Ian]
+0
09:18:34 [VincentK]
+1
09:18:36 [MaheshK]
+0
09:18:39 [AndreaF]
Yes, useful to clarify push payments too
09:18:41 [Ian]
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 [pirouz]
+0
09:18:47 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
09:18:52 [ben]
+1
09:19:05 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
09:21:11 [Nicolas_A_]
Nicolas_A_ has joined #wpwg
09:24:26 [AndreaF]
Could we please clarify the breakouts? Seems you have combined a few?
09:26:13 [alyver]
alyver has joined #wpwg
09:32:25 [adamR]
adamR has joined #wpwg
09:34:37 [sebsg]
sebsg has joined #wpwg
09:39:40 [MaheshK]
MaheshK has joined #wpwg
09:46:33 [nick]
nick has joined #wpwg
09:46:41 [faraz]
faraz has joined #wpwg
09:56:53 [alyver]
alyver has joined #wpwg
10:02:42 [ShaneM]
AdrianHB: does this address your push concern? https://w3c.github.io/webpayments-http-api/#h-issue10
10:04:41 [AdrianHB]
shanem - I think we should show a push flow. The current use case flow is being interpreted as the overall flow
10:05:13 [ShaneM]
AdrianHB: I agree - I just wanted to capture the issue for now.
10:05:28 [AdrianHB]
works for me
10:05:57 [Max]
Max has joined #wpwg
10:07:51 [ShaneM]
(I will go off and try to draw a pretty picture - or invite Max to help!)
10:08:42 [Max]
Glad to help.
10:09:04 [AndreaF]
Could you please add the link to the photo here? Thanks :)
10:09:51 [nick]
+1 for photo
10:10:18 [MattS]
MattS has joined #wpwg
10:12:54 [nicktr]
scribenick: nicktr
10:12:57 [zkoch]
zkoch has joined #wpwg
10:13:03 [ben]
ben has joined #wpwg
10:13:14 [CyrilV]
CyrilV has joined #wpwg
10:13:24 [nicktr]
subject: Testing strategy
10:13:30 [CyrilV]
present+ Cyril_Vignet
10:13:43 [nicktr]
shaneM: we're writing tests that should run 'forever'
10:14:13 [nicktr]
...CR means we have to show our specification can run in at least two implementations
10:14:33 [nicktr]
...payment request API is important as it has the momentum
10:15:06 [nicktr]
...core messages and vocabulary
10:15:12 [nicktr]
...HTTP API
10:15:21 [nicktr]
...app registration
10:15:43 [nicktr]
ShaneM: introducing web platform tests framework
10:16:01 [nicktr]
...one of the nice bits is automated reporting
10:16:35 [nicktr]
...but I need help to develop a stubbed payment applicatoin
10:16:40 [nicktr]
...so that we can test flows
10:17:26 [nicktr]
...the way to do this is -manual.html files which are automatable via webdriver
10:18:01 [nicktr]
...for the .js api
10:18:10 [nicktr]
q?
10:18:20 [Max]
q+
10:18:27 [nicktr]
...HTTP API is easily automatable
10:18:29 [AdrianHB]
scribenick: adrianhb
10:18:47 [AdrianHB]
shanem: The WPT framework is very customizable
10:19:15 [AdrianHB]
... allows backend comms to check message integrity
10:19:32 [AdrianHB]
[talking through helpful diagram]
10:19:58 [AdrianHB]
... automateable through Selenium or Webdriver
10:20:11 [nicktr]
ack Max
10:20:25 [AdrianHB]
... we should right enough to get good coverage but not too many so that its onerous to maintain
10:21:06 [AdrianHB]
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 [Ian]
https://www.w3.org/community/awpat/
10:21:24 [Ian]
Advancing Web Platform Application Testing Community Group
10:21:31 [AdrianHB]
shanem: yes, would great
10:21:44 [AdrianHB]
[What is WPT]
10:21:57 [AdrianHB]
... really is simple
10:22:10 [AdrianHB]
... built in support for taking in WebIDL and test interfaces
10:22:40 [Ian]
q?
10:22:41 [Ian]
q+
10:22:42 [Max]
ADVANCING WEB PLATFORM APPLICATION TESTING COMMUNITY GROUP
10:22:44 [AdrianHB]
... WPT has recently been extended to support testing JSON messaging which we need
10:22:51 [Max]
https://www.w3.org/community/awpat/
10:22:53 [AdrianHB]
[The Plan]
10:23:13 [adrianba]
-> http://github.adrianba.net/paymentrequest-demo/tests/payment-tests.html Example of testharness.js tests
10:23:19 [AdrianHB]
shanem: ceating the buckets that the tests will go into (a framework)
10:23:35 [AdrianHB]
... need help developing a skeleton payment app
10:24:06 [Ian]
q-
10:24:12 [AdrianHB]
... longer term we will work app and API devs to ensure the tests are ready when we get tp CR
10:24:30 [AdrianHB]
[What does test look like?]
10:25:13 [AdrianHB]
... tests should have clear explanations
10:25:23 [AdrianHB]
[What does a test look like (2)]
10:25:33 [AdrianHB]
... shows javascript behind test
10:25:41 [AdrianHB]
... this example shows an async test
10:26:02 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
10:26:08 [AdrianHB]
... test calls done() when it's finished
10:26:25 [AdrianHB]
... lots of primitives for us to use
10:27:00 [AdrianHB]
[What does running a test look like?]
10:27:20 [AdrianHB]
[Shane demos a test]
10:27:43 [Ian]
agenda?
10:27:50 [Ian]
zakim, clear agenda
10:27:50 [Zakim]
agenda cleared
10:29:23 [AdrianHB]
shanem: there is a PR to add more output meta-data
10:29:35 [AdrianHB]
[What does a report look like?]
10:29:39 [AdrianHB]
[link to report]
10:30:30 [AdrianHB]
... for each test there are sub tests which show sub test results from each tested implementation
10:30:48 [AdrianHB]
... this is pushed up by the implementors (presumeably from their CI)
10:30:51 [Roy]
Roy has joined #wpwg
10:30:55 [nicktr]
q?
10:31:04 [AdrianHB]
... we need 2 passing implementations to get to CR
10:31:38 [AdrianHB]
[What do I need from you?]
10:31:53 [AdrianHB]
... stable spec means less changes to tests
10:32:03 [AdrianHB]
... need peer reviews of tests
10:32:20 [AdrianHB]
nicktr: analogous to a spec editor?
10:32:21 [Max]
q+
10:32:41 [AdrianHB]
shanem: no, it's enough to understand the test (i.e. not just being an editor)
10:33:08 [AdrianHB]
... my job is manage the infrastructure. I hope we get volunteers to write tests
10:33:12 [AdrianHB]
q?
10:33:37 [manu]
q+ to ask how we tie in different merchant and payment app servers?
10:33:41 [AdrianHB]
max: I volunteer to review tests!
10:33:47 [AdrianHB]
[loud applause]
10:33:58 [rouslan]
rouslan has joined #wpwg
10:34:13 [AdrianHB]
nicktr: I suspect that testing needs some people on the ground to do work, are there any other volunteers?
10:34:32 [AdrianHB]
manu: DigitalBazaar will provide some resources
10:34:54 [AdrianHB]
zkoch: we already have some tests in Chromium. We'll port them over
10:35:03 [AdrianHB]
roy: We will also help review
10:35:30 [AdrianHB]
shanem: after we have finalised payment apps we'll have a better idea of what to test
10:35:49 [AdrianHB]
... if there isn't wide support for payment apps then this architecture obviously won't work
10:36:09 [AdrianHB]
... if that's not true I'd appreciate help on correcting my assumptions
10:36:15 [Ian]
q?
10:36:18 [AdrianHB]
nicktr: thanks Shanem
10:36:22 [Ian]
ack max
10:36:24 [AdrianHB]
ack max
10:37:19 [AdrianHB]
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 [nicktr]
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 [AdrianHB]
shanem: we are testing the interfaces we standardize. How we do this is interesting
10:38:11 [nicktr]
today's agenda -> https://github.com/w3c/webpayments/wiki/Proposed-F2F-Day-2-agenda
10:38:36 [AdrianHB]
... 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 [AdrianHB]
q?
10:38:56 [nicktr]
q?
10:39:00 [AdrianHB]
ack manu
10:39:00 [Zakim]
manu, you wanted to ask how we tie in different merchant and payment app servers?
10:39:00 [nicktr]
ack MaheshK
10:39:25 [fdold]
fdold has joined #wpwg
10:41:09 [faraz]
faraz has joined #wpwg
10:43:33 [manu]
q+ to note that failure during pull payment is still bad.
10:44:05 [MattS]
MattS has joined #wpwg
10:44:20 [zkoch]
q+
10:44:45 [lbolstad]
lbolstad has joined #wpwg
10:44:50 [lbolstad]
present+ lbolstad
10:44:52 [Max]
q+
10:45:00 [Ian]
Discussion of -> https://github.com/w3c/browser-payment-api/issues/224
10:45:16 [Ian]
scribe: Ian
10:45:30 [faraz]
+1 on a correlation id
10:45:33 [Ian]
Roy: You can solve this on a per payment app basis, but the additional complexity from the merchant perspective
10:45:54 [Ian]
...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 [Ian]
..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 [Ian]
q
10:46:20 [Ian]
q/
10:46:24 [Ian]
ack z
10:46:27 [manu]
ack manu
10:46:27 [Zakim]
manu, you wanted to note that failure during pull payment is still bad.
10:46:58 [Ian]
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 [Laurent_]
q+
10:47:27 [Ian]
...I think payment request API is to help with UX and bring new payment methods to the web.
10:47:33 [Ian]
...it is the channel for more secure payment methods
10:47:46 [Ian]
...but it's not been the case that this would mean there's no backend integration
10:48:04 [Ian]
...I understand your point about easier merchant integration, but I don't think we'll see that quickly
10:48:22 [Ian]
...I think the architectural limitation is something we need to consider if we were to adopt something like this
10:48:24 [nicktr]
q?
10:48:28 [Ian]
Max: I support this idea.
10:48:29 [Ian]
ack Max
10:48:30 [nicktr]
ack Max
10:48:38 [AdrianHB]
q+ to get some clarity on the value of a generic push payment method
10:48:44 [Ian]
Max: This is an interesting problem and I think the WG should spend time thinking about it.
10:48:55 [Ian]
..I'm happy to work with Roy on this
10:48:59 [Ian]
ack L
10:48:59 [Max]
Max has joined #wpwg
10:49:09 [Ian]
Laurent: In the SEPA payment method, we identified the same issue
10:49:31 [Ian]
...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 [Ian]
...this allows the server or payment app to provide confirmation to the merchant directly
10:50:15 [Ian]
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 [Ian]
q?
10:50:19 [Ian]
ack AdrianHB
10:50:19 [Zakim]
AdrianHB, you wanted to get some clarity on the value of a generic push payment method
10:51:02 [Ian]
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 [Ian]
...if we decide there's a common way to do this (e.g., callback, signature, transaction id)
10:51:31 [Ian]
...what value is there in these payment methods sharing a common payment method identifier.
10:51:47 [manu]
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 [Ian]
ack manu
10:52:11 [Zakim]
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 [Ian]
AdrianHB: Should this be "best practice" or in the spec?
10:52:44 [Ian]
NickTR: We could learn from specific instances
10:52:56 [Ian]
AdrianHB: But it doesn't solve the problem of "one payment method per payment app" that Roy raised
10:53:04 [Ian]
Manu: I think there's an incremental step we could take.
10:53:21 [Laurent_]
+1 to not sharing the identifier but standardizing the mecahnism
10:53:33 [Ian]
...I think there's value in standardizing the mechanism...e.g., best practice
10:55:00 [faraz]
faraz has joined #wpwg
10:55:01 [faraz]
q+
10:55:01 [Ian]
...spec it out "If you want to verify the payment went through, do this"
10:55:11 [Ian]
AdrianHB: So that does not solve the fragmentation issue
10:55:12 [Laurent_]
q+
10:55:14 [Ian]
Manu: That's ok (for now)
10:55:48 [AdrianHB]
q+ to mention open schemes
10:55:55 [porouz]
porouz has joined #WPWG
10:56:03 [manu]
q+ to mention that you could do both, see what the market decides
10:56:07 [manu]
q-
10:56:07 [Ian]
zakim, close the queue
10:56:09 [Zakim]
ok, Ian, the speaker queue is closed
10:56:12 [Ian]
ack faraz
10:56:45 [Lauren_Jones]
Lauren_Jones has joined #wpwg
10:56:46 [Ian]
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 [Ian]
..make it a non-mandatory guidance
10:56:59 [Ian]
q?
10:57:09 [Ian]
...or any status information...
10:57:11 [Ian]
ack L
10:57:16 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
10:57:37 [Ian]
Laurent: The problem is not so much fragmentation on the payment app side, the problem is integration cost for merchant
10:57:55 [Ian]
...so you help the merchant if you provide a generic way to handle the response
10:58:14 [Ian]
ack AdrianHB
10:58:14 [Zakim]
AdrianHB, you wanted to mention open schemes
10:58:35 [Ian]
adrianhb: I think what's great about this conversation is that it's crystalized some water cooler discussion
10:58:58 [Ian]
...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 [Ian]
...compare those with the "open" payment schemes, where there are standards that enable anyone to write a payment app
10:59:35 [nicktr]
q?
10:59:38 [Ian]
...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 [Ian]
..there is an incentive to create a standard to be able to do bitcoin payments from a variety of apps
11:00:03 [Ian]
...I think the bottom line is that we support both of these use cases
11:00:12 [Ian]
...that is "open" and "proprietary" payment methods
11:01:05 [Ian]
...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 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
11:01:29 [Ian]
[Break]
11:03:56 [alyver]
alyver has joined #wpwg
11:04:59 [adamR]
adamR has joined #wpwg
11:10:49 [Max]
Max has joined #wpwg
11:11:16 [alyver]
alyver has joined #wpwg
11:14:41 [alyver]
alyver has joined #wpwg
11:30:28 [alyver]
alyver has joined #wpwg
12:14:12 [alyver]
alyver has joined #wpwg
13:00:50 [zkoch]
zkoch has joined #wpwg
13:01:13 [lbolstad]
lbolstad has joined #wpwg
13:01:23 [lbolstad]
present+ lbolstad
13:02:27 [conorhackett_wp]
conorhackett_wp has joined #wpwg
13:03:34 [fdold]
fdold has joined #wpwg
13:03:43 [adamR]
adamR has joined #wpwg
13:03:51 [nick]
nick has joined #wpwg
13:04:45 [Max]
Max has joined #wpwg
13:06:25 [ben]
ben has joined #wpwg
13:06:38 [Roy]
Roy has joined #wpwg
13:08:13 [nick]
nick has joined #wpwg
13:09:55 [MattS]
MattS has joined #wpwg
13:10:03 [faraz]
faraz has joined #wpwg
13:10:32 [nicktr]
nicktr has joined #wpwg
13:10:46 [manu]
Topic: Breakout Review
13:10:52 [manu]
scribe: manu
13:11:46 [CyrilV]
CyrilV has joined #wpwg
13:11:56 [manu]
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]
brian_s has joined #WPWG
13:12:57 [Ian]
q+
13:13:03 [manu]
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 [Ian]
zakim, open the queue
13:13:05 [Zakim]
ok, Ian, the speaker queue is open
13:13:20 [manu]
Ian: Why give a link to Javascript instead of Javascript?
13:13:26 [alyver]
alyver has joined #wpwg
13:13:45 [nicktr]
conference call is now open
13:14:04 [pirouz]
pirouz has joined #WPWG
13:14:04 [nicktr]
international calling numbers can all be found here -> https://github.com/w3c/webpayments/wiki/Proposed-F2F-Day-2-agenda
13:14:21 [nicktr]
sorry - wrong paste buffer
13:14:22 [manu]
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]
AjayR has joined #wpwg
13:15:09 [nicktr]
international calling numbers can all be found here -> https://www-emea.intercallonline.com/listNumbersByCode.action?confCode=875114&area=viewNumber
13:15:18 [manu]
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 [nicktr]
conference number is 875114
13:15:42 [Ian]
q+
13:16:03 [manu]
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 [manu]
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 [nicktr]
ack Ian
13:18:52 [Ian]
Ian: We should consider all these states together: (1) ready to use (2) installed but needs credentials (3) not yet installed
13:18:52 [nicktr]
agenda -> https://github.com/w3c/webpayments/wiki/Proposed-F2F-Day-2-agenda
13:18:57 [manu]
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 [manu]
s/enroll./enroll, then PayPal could be enrolled./
13:19:44 [manu]
AdrianHB: Proposal is for group to take this up - proposal for payment apps API in browser
13:20:12 [manu]
AdrianHB: The spec will be adopted as an editor's draft in its current form, with issues and new editors added.
13:20:16 [Ian]
Editors to add: Lauren, Ian
13:20:36 [Ian]
PROPOSED: Take up the payment app spec as a WG deliverable (with current editors + Laurent + Ian)
13:20:42 [ShaneM]
+1
13:20:44 [conorhackett_wp]
+1
13:20:45 [manu]
+1
13:20:49 [lbolstad]
+1
13:20:49 [AndreaF]
+1
13:20:52 [adamR]
+1
13:20:53 [MattS]
+1
13:20:54 [Ian]
+1
13:20:54 [MaheshK]
+1
13:20:54 [Roy]
+1
13:20:56 [Laurent_]
Laurent_ has joined #wpwg
13:20:56 [Dongwoo]
+1
13:20:59 [Laurent_]
+1
13:21:01 [rouslan]
+1
13:21:05 [zkoch]
+…0
13:21:07 [Ian]
(No signs of hand in the room; just IRC +1s)
13:21:16 [pirouz]
+1
13:21:22 [kriske]
kriske has joined #wpwg
13:21:31 [manu]
Topic: Payment Method Identifiers Breakout
13:21:35 [kriske]
present+ kriske
13:21:49 [jyrossi]
jyrossi has joined #wpwg
13:21:55 [CyrilV]
present+ Cyril_Vignet
13:21:59 [jyrossi]
present+ jyrossi
13:22:51 [manu]
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 [manu]
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_]
adamR_ has joined #wpwg
13:24:21 [manu]
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_]
AndreaF_ has joined #wpwg
13:25:26 [manu]
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 [manu]
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 [manu]
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 [manu]
NickTR: Aggregated payment session - good robust conversation.
13:28:34 [manu]
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 [manu]
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 [manu]
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 [manu]
crete implementations - actually implement basic card as a spec, then apply restrictions - covers a multitude of specific payment methods.
13:33:01 [manu]
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 [manu]
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]
jiajia has joined #wpwg
13:34:45 [manu]
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 [AdrianHB]
q?
13:35:04 [manu]
Ian: There had to do with payment app identification - don't know if that's a best practice thing.
13:35:29 [manu]
NickTR: We have a coalition of the willing to work on these items right now.
13:35:40 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
13:36:39 [manu]
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 [MattS]
q+
13:36:54 [manu]
Adrianba: Our conversation was broader than this - had to do with how to converge.
13:36:56 [nicktr]
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 [nicktr]
q?
13:37:15 [nicktr]
ack MattS
13:37:17 [nick]
q+
13:37:31 [jyrossi]
q+
13:37:37 [manu]
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 [AdrianHB]
q+ to suggest concrete progress for cards
13:37:47 [nicktr]
ack nick
13:38:19 [Lauren_Jones]
Lauren_Jones has joined #wpwg
13:38:25 [manu]
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 [nicktr]
ack jyrossi
13:39:45 [manu]
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 [manu]
NickTR: There is plenty of opportunity for collaboration - anyone is welcome to collaborate with this work.
13:40:24 [nicktr]
q?
13:41:00 [nicktr]
ack AdrianHB
13:41:00 [Zakim]
AdrianHB, you wanted to suggest concrete progress for cards
13:41:19 [MattS]
q+
13:41:29 [manu]
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 [CyrilV]
q+
13:41:57 [manu]
AdrianHB: I'd like some clarity on whether or not the group agrees with the current direction.
13:42:01 [zkoch]
q+
13:42:03 [nicktr]
ack MattS
13:42:25 [manu]
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 [manu]
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 [manu]
AdrianHB: We can't progress, this is a blocking issue.
13:43:45 [manu]
q+ to understand why this is a "blocking issue"
13:44:37 [manu]
CyrilV: We need a payment method identifier that works for SCT, Bitcoin, etc.
13:44:38 [Ian]
q+
13:44:40 [manu]
ack CyrilV
13:44:41 [Ian]
ack Cyr
13:44:45 [ShaneM]
q+ to ask that we keep testability in mind when designing this scheme
13:45:00 [manu]
NickTR: We're not just talking about cards.
13:45:49 [manu]
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 [manu]
AdrianHB: The people that have been tasked by the group to solve this are not the implementers, we need both involved.
13:46:56 [manu]
zkoch: That's not being proposed
13:47:09 [manu]
q-
13:47:25 [MattS]
?
13:47:25 [Ian]
ack zk
13:47:27 [AdrianHB]
+1 let's do this together as a priority
13:47:33 [Ian]
q-
13:47:34 [Ian]
ack S
13:47:34 [Zakim]
ShaneM, you wanted to ask that we keep testability in mind when designing this scheme
13:48:09 [manu]
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 [manu]
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 [manu]
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 [Roy]
Let's do it!
13:49:52 [zkoch]
Beer!
13:49:54 [zkoch]
I mean...PMI
13:52:28 [manu]
Manu: Why can't you just do negation?
13:52:39 [manu]
Ian: You can't do differential pricing with just negation.
13:52:47 [brian_s]
brian_s has joined #wpwg
13:52:52 [manu]
Manu: Yes, you need two things... negation and ... *cliffhanger!*
13:53:35 [adrianba]
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 [manu]
Ian: For tokenized card spec, nick, faraz, and laurent.
13:54:02 [manu]
adrianba, yes
13:54:16 [manu]
adrianba - there are some questions about arguments, core messages, etc.
14:07:27 [Ian]
rrsagent, make minutes
14:07:27 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
14:07:30 [Ian]
rrsagent, set logs public
14:08:49 [alyver]
alyver has joined #wpwg
14:10:09 [Ian]
zakim, this log spans midnight
14:10:09 [Zakim]
I don't understand 'this log spans midnight', Ian
14:10:12 [Ian]
zakim, this log spans midnight.
14:10:12 [Zakim]
I don't understand 'this log spans midnight', Ian
14:10:16 [Ian]
zakim, this spans midnight.
14:10:16 [Zakim]
I don't understand 'this spans midnight', Ian
14:10:23 [Ian]
rrsagent, this log spans midnight.
14:10:23 [RRSAgent]
I'm logging. I don't understand 'this log spans midnight.', Ian. Try /msg RRSAgent help
14:10:24 [Ian]
rrsagent, this log spans midnight
14:10:24 [RRSAgent]
I'm logging. I don't understand 'this log spans midnight', Ian. Try /msg RRSAgent help
14:10:58 [Ian]
rrsagent, this meeting spans midnight
14:11:05 [Ian]
rrsagent, make minutes
14:11:05 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
14:11:11 [Ian]
rrsagent, set logs public
14:12:05 [alyver]
alyver has joined #wpwg
14:12:16 [Ian]
rrsagent, make minutes
14:12:16 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/07-wpwg-minutes.html Ian
14:12:34 [nick]
nick has joined #wpwg
14:13:26 [alyver]
alyver has joined #wpwg
14:19:37 [rouslan]
rouslan has joined #wpwg
14:24:28 [alyver]
alyver has joined #wpwg
14:24:37 [Max]
Max has joined #wpwg
14:25:45 [Ian]
rrsagent, bye
14:25:45 [RRSAgent]
I see 7 open action items saved in http://www.w3.org/2016/07/07-wpwg-actions.rdf :
14:25:45 [RRSAgent]
ACTION: AdamR to work on concrete spec language around currency codes [1]
14:25:45 [RRSAgent]
recorded in http://www.w3.org/2016/07/07-wpwg-irc#T11-54-55
14:25:45 [RRSAgent]
ACTION: Max to work with Ian on starting some payment method good practice documentation. [2]
14:25:45 [RRSAgent]
recorded in http://www.w3.org/2016/07/07-wpwg-irc#T15-13-41
14:25:45 [RRSAgent]
ACTION: Ian to work with AdamR and Jonny on raising an issue about privacy notifications about sharing identifiable information [3]
14:25:45 [RRSAgent]
recorded in http://www.w3.org/2016/07/07-wpwg-irc#T16-11-28
14:25:45 [RRSAgent]
ACTION: NickTR to try to get a security review organized within Worldpay [4]
14:25:45 [RRSAgent]
recorded in http://www.w3.org/2016/07/07-wpwg-irc#T16-18-20
14:25:45 [RRSAgent]
ACTION: Huw to try to get a security review within Amex [5]
14:25:45 [RRSAgent]
recorded in http://www.w3.org/2016/07/07-wpwg-irc#T16-18-29
14:25:45 [RRSAgent]
ACTION: Cyril to try to get a security review within BPCE [6]
14:25:45 [RRSAgent]
recorded in http://www.w3.org/2016/07/07-wpwg-irc#T16-18-44
14:25:45 [RRSAgent]
ACTION: AdrianHB to create a resource that speaks to security topics [7]
14:25:45 [RRSAgent]
recorded in http://www.w3.org/2016/07/07-wpwg-irc#T16-21-25
14:25:47 [Ian]
zakim, bye
14:25:47 [Zakim]
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]
Zakim has left #wpwg
14:25:50 [Zakim]
... joshua, kriske, VincentK, Brian_Sullivan, Charlie-Craven, BenSmith, Andrea, Dapeng, jiajia, SimonScorer, KrisKetels, VincentKuntz, Manu, Faraz, CyrilVignet, NichlasAncot,
14:25:50 [Zakim]
... Jean-Yves, zach, Sebastien, Dongwoo, LaurentCastillo, LaurentJones, Florian, NickS, Roy, Ade, Connor, AdamR, Farad, AHB, Ajay, DanAppelquist, DavidBirch, wseltzer, alyver,
14:25:50 [Zakim]
... nick, conorh_wp, AndreaF, sebsg, pirouz, Cyril_Vignet, …0, jyrossi
14:25:54 [adamR]
adamR has joined #wpwg