15:54:40 RRSAgent has joined #wpwg 15:54:40 logging to http://www.w3.org/2016/07/28-wpwg-irc 15:54:42 RRSAgent, make logs public 15:54:42 Zakim has joined #wpwg 15:54:44 Zakim, this will be 15:54:44 I don't understand 'this will be', trackbot 15:54:45 Meeting: Web Payments Working Group Teleconference 15:54:45 Date: 28 July 2016 15:54:55 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20160728 15:56:26 Present+ AdrianHB 15:56:41 Chair: AdrianHB 15:56:41 scribe: Ian 15:57:54 present+ Ian 15:57:56 present+ Manu 15:58:47 present+ Laurent 15:59:24 Laurent has joined #wpwg 16:00:38 Adam__ has joined #wpwg 16:01:04 alyver has joined #wpwg 16:01:21 present+ ShaneM 16:01:54 Topic: Where are we with publishing HTTP-API and Core messages for FPWD? 16:02:17 Adrian: I think it is premature and I would object to issuing a call for consensus 16:02:51 ...this is a view expressed with a chair's hat. We do not yet have a common data model and so I think we are sending the wrong message if we are saying this is how the design of the APIs is happening. 16:03:12 present+ adamR 16:03:13 ...I prefer that we publish what we agree on, namely payment request API and HTTP API. And if we can extract the core data model later we can do that. 16:03:30 present+ MaheshK 16:03:36 Manu: I've sent some comments; no replies yet 16:03:43 AdrianHB: I've been traveling; sorry for the delay 16:03:50 present+ MattS 16:04:16 Manu: Great 16:04:20 MattS has joined #wpwg 16:04:56 AdrianHB: There were no objections at the FTF but not a lot of support for the FPWD of Core messages; it didn't yet feel like we will get consensus. 16:05:08 ..I hope to respond by week's end 16:05:18 -> Agenda https://github.com/w3c/webpayments/wiki/Agenda-20160728 16:05:46 present+ MattS 16:05:58 maheshk has joined #wpwg 16:06:04 present+ Shane 16:06:34 Adrian: I have been traveling a lot; sorry for silence; back at home now. Thanks to Ian for carrying the baton 16:07:10 ...note that the payment apps task force is sending agendas and minutes to the WG's list 16:07:26 Topic: TPAC 2016 16:07:30 alyver has joined #wpwg 16:07:39 https://www.w3.org/2002/09/wbs/35125/TPAC2016/?login 16:07:51 https://github.com/w3c/webpayments/wiki/FTF-Sep2016 16:07:55 present+ alyver 16:07:56 Ian: Please register as soon as possible. The rate goes up after September 2nd 16:08:15 Ian: I have created a page for the agenda, please put agenda ideas there. We welcome thoughts on building the Agenda and goals for the meeting. 16:08:19 PLEASE REGISTER! 16:08:25 regrets: NickTR 16:08:54 AdrianHB: We meet for 2 days and want to set some goals. We meet Monday and Tuesday 16:09:12 ...also suggest hanging around for the plenary day (Weds) as well as Thursday and Friday (IG meeting) 16:10:03 q? 16:10:10 ...in terms of setting the agenda, it would be great for group participants who have specific goals to put them in the wiki 16:10:24 TPAC is in Lisbon 16:10:29 TPAC is 19-23 Sep 16:10:34 WG meeting is 19-20 Sep 16:10:43 Topic: PMI Proposal related to matching use cases 16:11:03 PMI proposal was just made available yesterday: 16:11:03 https://github.com/zkoch/zkoch.github.io/blob/master/pmi.md 16:11:21 ian: The propsoal includes a few pieces 16:11:22 Ian: The proposal includes a few pieces 16:11:47 Ian: The proposal is pretty short, doesn't intend to substitute entirely for entire PMI spec. 16:12:26 dezell has joined #wpwg 16:12:34 Ian: There are a couple of requirements in here - a distinction between "open" systems and "proprietary" systems. Where "proprietary" means that some entity owns the payment method and it's the only entity that creates a payment app to create that payment method (or they sublicense that ability). 16:13:04 Ian: Whether or not it has an impact on the ultimate specification is not known yet. There is an n-to-1 mapping for open payment mechanisms. There is a 1-to-1 for proprietary ones. 16:13:24 "singleton payment method" 16:13:43 Ian: There is a naming mechanism wrt. bootstrapping the ecosystem. For proprietary systems, payment methods are identified via URLs. Open Payment methods are published by W3C and are URNs that don't resolve to anything. 16:14:26 Ian: it is a goal to not have those identifiers dereferencable. For other ones, it may be good to have them dereferenceable. Other people are not implementing the payment method... just the owner. 16:14:54 Ian: Then there is fine-grained matching - especially in the case of card payments. Whether we needed a general mechanism for PMIs that would somehow involve complex subclassing. 16:15:05 Ian: There are two use cases that we should keep in mind: 16:15:11 === 16:15:12 The merchant accepts both Visa Credit and Visa Debit. Merchant wishes to charge a differential price for specific types, most commonly credit vs debit. 16:15:12 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. 16:15:12 ==== 16:17:10 Ian: the way matching works isn't through more sophisticated payment method syntax... it's still just URLs for PMIs... but there is extra data in payment request API to say debit vs. credit, to add constraints through payment method request API. End of proposal says how to do that. THere is an implication that mediators will need to enhance basic matching if basic matching is URL equivalence testing. A given payment method may have additional matching semantics th 16:17:10 at implement that payment method would also have to implement. Per payment method matching semantics is noted in this specification as well. 16:17:31 q+ to ask what happens when there are extra tags that are unknown to the mediator. 16:18:15 Ian: The current spec says that if you encounter the same PMI, fail. The change would be to pick the first one. This update is relatively simple, gets us a few use cases, hints at how second use case might work with a different payment method. 16:18:16 q+ 16:18:23 ack manu 16:18:23 manu, you wanted to ask what happens when there are extra tags that are unknown to the mediator. 16:18:25 q+ 16:18:43 Manu: The general approach sounds good. I have some concerns about URNs but that can be pushed off. 16:18:53 ...What happens if a mediator doesn't understand extra information? 16:19:04 q+ to mention other standards group should able to define 'open' methods 16:19:11 ...Basically you are saying "Basic card + constraints" 16:19:29 ..what happens when a mediator does not understand one of the constraints? 16:19:58 IJ: Please register an issue against the document. 16:20:41 Ian: wrt. URNs, they will be documented in specs. 16:20:44 Manu: How would identifier registry be managed? 16:20:54 q? 16:20:56 ack MattS 16:21:17 MattS: First question - this is in Zach's repository...should we raise issues there or bring into repo? 16:21:32 Adrian: We should pull into proposals folder in the core repo and raise issues in the core repo? 16:21:40 ACTION: AdrianHB to work with Zach to get proposal into W3C repo. 16:21:41 Error finding 'AdrianHB'. You can review and register nicknames at . 16:22:08 MattS: You think it only meets the first use case. It seems also to meet the second use case. We are saying that the payment method defines constraints. 16:22:45 Ian: The actual proposal only includes stuff for the basic card spec 16:23:02 Ian: Someone else might create another payment method that does something more. 16:24:02 q? 16:24:13 Ian: This requires changes to payment mediator - don't know if browsers in the short term will implement the more advanced card selection mechanism. I don't know if this addresses the second use case. 16:24:31 q+ 16:24:46 MattS: It may not have to be the mediator that does matching. 16:24:50 MattS: It may not have to be the mediator that does this matching, don't know if the specification requires it. Multiple match data, the payment app could do the more detailed matching. 16:24:53 ..it could be that the payment app could do some of the matching 16:24:53 q- 16:25:07 ack Ad 16:25:19 AdrianHB: I have a bunch of comments. 16:25:26 ...first comment on URNs: +1 16:25:45 ...solves problem of server load issue with dereferencing (as Mike has pointed out) 16:25:59 ...I think "don't dereference" is the right thing here. 16:26:18 ...I don't think we need a registry, we are creating one implicitly through the specs 16:26:36 (IJ: +1 to not maintaining a SEPARATE registry in the long term; maybe short term for bootstrapping ok) 16:26:54 AdrianHB: In general I like the approach, specifically the idea between distinguishing Open v. Proprietary 16:27:23 ..I think we are starting to get to a point where we are solving some problems where previously we our generic solutions were ugly or vice versa 16:27:27 q+ to note that it's best practice to create registries for URNs at IETF - https://www.ietf.org/assignments/urn-namespaces/urn-namespaces.xml 16:27:43 ...my biggest concern is that for the generic methods we are putting a lot behind the mediators behind the browsers to make changes 16:27:56 ...so if a new generic payment method comes along, browsers are gatekeepers for new matching semantics 16:28:01 ...so that's a potential weakness 16:28:32 ...we could address his with a generic tag-based matching algorithm 16:28:54 ...so simple tag-based matching + simple enhancements 16:29:08 q+ to talk about going general 16:29:20 AdrianHB: I don't think we should put data-for-mediators in the data blob 16:29:27 ...I think that data should be a separate member of the object 16:29:32 q+ 16:29:33 ...e.g., payment methods, then filters, then data 16:29:40 ...I will raise some of these as issues 16:29:41 +1 to seperate filters prop 16:29:43 ack Laurent 16:29:43 Laurent, you wanted to mention other standards group should able to define 'open' methods 16:29:52 +1 to separate tags/filters 16:30:53 Laurent: I think it should be possible for other standards bodies to define open methods. 16:31:13 +1 to other groups ability to publish 16:31:15 (Please raise that issue on the spec) 16:31:34 q? 16:31:47 Laurent: I will raise this on the group's issues list 16:31:49 ack Manu 16:31:49 manu, you wanted to note that it's best practice to create registries for URNs at IETF - https://www.ietf.org/assignments/urn-namespaces/urn-namespaces.xml 16:32:11 Manu: Regarding URNs, I think it's good practice to register URNs 16:32:21 Take a look at this RFC: https://tools.ietf.org/html/rfc3406#section-3.3 16:32:38 +1 to allowing anyone to create a generic payment method spec - this could be addressed by having some "generic" functions that apply to all methods even if the URN isn't known to the mediator 16:33:24 ACTION: AdamR to look into what the right practice is if we use URNs. 16:33:25 Created ACTION-23 - Look into what the right practice is if we use urns. [on Adam Roach - due 2016-08-04]. 16:33:30 ack adamR 16:34:15 +1 to a single URN space and leave it at that 16:34:16 AdamR: In WebRTC we looked into whether we could use URNs. I think we can register a single URN space easily; would not want others to maintain values under that. 16:35:11 Ian: We need to decide how other organizations create their own payment methods 16:35:39 Ian: Open in W3C vs. Open elsewhere... we may complicate our lives more if we start managing urn:payment-method - I'd -1 that, I don't want to get into that business. 16:35:47 q? 16:35:48 ack me 16:35:48 Ian, you wanted to talk about going general 16:36:32 q+ to say this proposal lets us compromise 16:36:41 q? 16:36:45 q+ 16:37:06 Ian: Adrian, regarding your points about PMI generic matching and filtering... my sense is that is a fine thing to get to after some experience. Do we want to state up front that there is a generic pattern for future values that can be matched, and would that lower the cost of implementing this in browsers? I asked some browser vendors about this and they said it wouldn't matter to them - let's not try to create a generic syntax. If we find that this is the right 16:37:06 pattern, we can go generic. 16:37:11 IJ: I suggest we try the pattern out a few times before going generic 16:37:31 ack AdrianHB: My response to that is that if we adopt something like this proposal, we have an opportunity to compromise a bit. 16:38:07 ...if we take the approach that's proposed here - matching is only likely to apply to generic payment methods which are few -- that immediately removes some needs to worry about some payment methods (e.g., paypal) 16:38:19 ...presumably we could make the matching thing a separate piece of payment request 16:38:41 ...the filters could be one thing, and data could be its own thing: data is opaque to mediators; filters are not 16:39:29 ...if a payment method is developed outside W3C it can leverage simple matching 16:39:54 ...and if more complex matching is needed, they can come to w3c to have a payment method published through w3c to get more advanced matching algorithms 16:40:04 q? 16:40:30 ...if we pull matching filters stuff out of data and put it in its own place and define matching we already have a generic matching algorithm 16:40:31 +1 to pull matching "stuff" out of method-specific data. 16:40:41 +1 for basic tag-based matching algorithm 16:41:02 q- 16:41:21 I think there is a good middle-ground here. 16:41:28 IJ: There are security issues (as I recall) for infinite lists with unknown strings; I think that's why the proposal is for a fixed list. 16:41:33 I don't think I am confortable with browser vendors being in charge of deciding who is a real payment method and who is not 16:41:36 (as in, there is a general approach, but only specific values will work for security reasons. 16:42:24 q? 16:42:27 ack AdrianHB 16:42:27 AdrianHB, you wanted to say this proposal lets us compromise 16:42:28 Ian: We will have to look at this in more depth, but I don't want the "let's be as generic as possible" to undermine the specific use cases and solutions we have today. 16:42:48 (IJ: seems fine to pull filters out of data; I would have to look more closely) 16:43:02 q? 16:43:22 Topic: Push payments 16:43:28 https://github.com/w3c/browser-payment-api/pull/223 16:43:35 Laurent has joined #wpwg 16:43:40 q+ 16:43:46 AdrianHB: I am ok to make a comment here...this came up at the FTF meeting 16:43:51 q+ to mention "push" payments and HTTP API 16:44:20 ...when we look at push methods, if a payment app is processing the payment, then there are new communications issues that arise 16:44:36 ...e.g., merchant needs to know that they have been paid in order to agree to ship goods 16:44:56 ...Roy's proposal is to include an event ... I personally think this proposal won't work, but I agree that we need something 16:45:24 ...I suggest that we look at today's push flows (e.g., paypal, alipay, etc.) and ask "what happens if something breaks at this point in the flow?" 16:45:41 ...specifically the risk is that the payment is proceed and the merchant does not receive notice 16:45:58 ...I think there are some generic ideas that we can use to get interop, otherwise the space will be fragmented 16:46:15 q? 16:46:28 ack MattS 16:46:35 MattS: +1 to looking at this problem. 16:46:58 ...one debate is "where it goes" but I think we need to address the the use cases a bit more before deciding where the proposal should go 16:47:15 zakim, agenda? 16:47:15 I see nothing on the agenda 16:47:21 AdrianHB: +1 to taking a step back to look more closely at the problem statement and getting clarity before we propose spec changes 16:47:21 q? 16:47:24 ack Manu 16:47:24 manu, you wanted to mention "push" payments and HTTP API 16:47:44 Manu: This also affects the HTTP API spec. 16:47:50 present+ dezell (in part) 16:47:59 ...+1 to getting people together to look at what happens when the flow breaks at various times 16:48:19 q+ to mention something about breakdowns 16:48:26 ack me 16:48:26 Ian, you wanted to mention something about breakdowns 16:48:26 ack ia 16:48:43 Ian: I had done a bit of analysis w/ Alibaba folks about communication breakdown in the flows. 16:48:56 Ian: Under model and design considerations: 16:49:14 Ian: The details are somewhere in there, section 8 16:50:03 Ian: You begin to observe that our responsibility is only partial, for example, it's still useful to draw them out, but I don't think we're responsible for breakdowns in javascript running in browser to merchant website, it's not our groups consideration. It may be a Javascript problem, or Web architecture problem, but not necessarily a Payment API problem. 16:50:41 Ian: It may be that we have some good practice things to say about that stuff, that's fine, but we may be able to make certain assumptions about browser to javascript communication. What's left is payment app to browser communication, I think that's the biggest place that we should focus. 16:50:56 Ian: From a standardization standpoint, there is only how we mitigate that flaw in both directions between browser and payment app. 16:51:02 q? 16:52:30 AdrianHB: I think we are all saying similar things...this could be addressed at the payment method level, but we could look at this and realize that a field in the payment request (e.g., a place for a callback) would make this easier to address across payment methods). Let's do the analysis first, and determine whether it's best left to the payment method or a field in payment request API 16:52:45 Adrian: Who is interested in being part of a mini-task force to discuss this? 16:53:00 q+ 16:53:02 I'd like to join 16:53:37 Since it is flows, we could do it as part of the Flows Tasks force? 16:53:43 Ian: Let's try to make this more low key. 16:54:32 Also we've looked at this as part of SEPA which is the same task force 16:54:47 AdrianHB: We could call this Push Payments analysis - that's all I'm suggesting for now. 16:54:58 Topic: FTF review 16:55:15 rouslan has joined #wpwg 16:55:15 Ian: I wanted to point out that we had some actions from the meeting. 16:55:44 Ian: People signing up to do work, we had a lull after the F2F - didn't want us to forget that people had signed up to do things around testing, payment method development, best practices, etc. 16:55:54 Ian: We had not gotten together w/ the chairs recently. 16:56:14 q+ 16:56:27 Ian: There were volunteers to work on the tokenized spec - that person could take responsibility for organizing whatever needs to be done. Those people that volunteered... 16:56:33 Ian: Tokenized - laurent, nick, and faraz 16:56:46 Ian: Does Laurent want to take ownership of that? 16:57:02 AdrianHB: That was the group that wanted to do a slightly more advanced card spec. 16:57:25 Laurent: I think we're waiting on Matt for that? 16:57:27 There was also some interest in producing a generic payment method guidelines document... right? 16:57:28 Laurent: Status is waiting for something from MattS. 16:57:50 AdrianHB: Maybe we should follow up with each of these groups after the meeting. 16:57:59 +1 to that 16:58:07 q- 16:58:24 ACTION: AdrianHB to work with Chairs + Team Contacts to formalize who is responsible for the activities mentioned at the FTF around tokenized card payment method spec, and payment method spec good practices 16:58:25 Created ACTION-24 - Work with chairs + team contacts to formalize who is responsible for the activities mentioned at the ftf around tokenized card payment method spec, and payment method spec good practices [on Adrian Hope-Bailie - due 2016-08-04]. 16:58:40 I have made the request to generate http://www.w3.org/2016/07/28-wpwg-minutes.html Ian 16:59:22 Topic: Next Call 16:59:29 https://lists.w3.org/Archives/Public/public-payments-wg/2016Jul/0147.html 16:59:36 4 Aug same time 16:59:41 but fill out the poll! 17:00:03 I have made the request to generate http://www.w3.org/2016/07/28-wpwg-minutes.html Ian 17:11:58 alyver has joined #wpwg 17:15:28 alyver has left #wpwg 17:19:05 Mike5 has left #wpwg 17:34:34 Adam__ has joined #wpwg 17:45:31 adamlake has joined #wpwg 17:48:28 Adam_ has joined #wpwg 17:58:47 Adam__ has joined #wpwg 18:03:52 sam has joined #wpwg 18:27:43 shepazu_ has joined #wpwg 19:00:33 Zakim has left #wpwg