IRC log of wpwg on 2016-07-28

Timestamps are in UTC.

15:54:40 [RRSAgent]
RRSAgent has joined #wpwg
15:54:40 [RRSAgent]
logging to http://www.w3.org/2016/07/28-wpwg-irc
15:54:42 [trackbot]
RRSAgent, make logs public
15:54:42 [Zakim]
Zakim has joined #wpwg
15:54:44 [trackbot]
Zakim, this will be
15:54:44 [Zakim]
I don't understand 'this will be', trackbot
15:54:45 [trackbot]
Meeting: Web Payments Working Group Teleconference
15:54:45 [trackbot]
Date: 28 July 2016
15:54:55 [Ian]
Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20160728
15:56:26 [AdrianHB]
Present+ AdrianHB
15:56:41 [Ian]
Chair: AdrianHB
15:56:41 [Ian]
scribe: Ian
15:57:54 [Ian]
present+ Ian
15:57:56 [Ian]
present+ Manu
15:58:47 [Ian]
present+ Laurent
15:59:24 [Laurent]
Laurent has joined #wpwg
16:00:38 [Adam__]
Adam__ has joined #wpwg
16:01:04 [alyver]
alyver has joined #wpwg
16:01:21 [ShaneM]
present+ ShaneM
16:01:54 [Ian]
Topic: Where are we with publishing HTTP-API and Core messages for FPWD?
16:02:17 [Ian]
Adrian: I think it is premature and I would object to issuing a call for consensus
16:02:51 [Ian]
...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 [adamR]
present+ adamR
16:03:13 [Ian]
...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 [Ian]
present+ MaheshK
16:03:36 [Ian]
Manu: I've sent some comments; no replies yet
16:03:43 [Ian]
AdrianHB: I've been traveling; sorry for the delay
16:03:50 [Ian]
present+ MattS
16:04:16 [Ian]
Manu: Great
16:04:20 [MattS]
MattS has joined #wpwg
16:04:56 [Ian]
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 [Ian]
..I hope to respond by week's end
16:05:18 [Ian]
-> Agenda https://github.com/w3c/webpayments/wiki/Agenda-20160728
16:05:46 [MattS]
present+ MattS
16:05:58 [maheshk]
maheshk has joined #wpwg
16:06:04 [Ian]
present+ Shane
16:06:34 [Ian]
Adrian: I have been traveling a lot; sorry for silence; back at home now. Thanks to Ian for carrying the baton
16:07:10 [Ian]
...note that the payment apps task force is sending agendas and minutes to the WG's list
16:07:26 [Ian]
Topic: TPAC 2016
16:07:30 [alyver]
alyver has joined #wpwg
16:07:39 [Ian]
https://www.w3.org/2002/09/wbs/35125/TPAC2016/?login
16:07:51 [Ian]
https://github.com/w3c/webpayments/wiki/FTF-Sep2016
16:07:55 [alyver]
present+ alyver
16:07:56 [manu]
Ian: Please register as soon as possible. The rate goes up after September 2nd
16:08:15 [manu]
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 [Ian]
PLEASE REGISTER!
16:08:25 [Ian]
regrets: NickTR
16:08:54 [Ian]
AdrianHB: We meet for 2 days and want to set some goals. We meet Monday and Tuesday
16:09:12 [Ian]
...also suggest hanging around for the plenary day (Weds) as well as Thursday and Friday (IG meeting)
16:10:03 [AdrianHB]
q?
16:10:10 [Ian]
...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 [Ian]
TPAC is in Lisbon
16:10:29 [Ian]
TPAC is 19-23 Sep
16:10:34 [Ian]
WG meeting is 19-20 Sep
16:10:43 [Ian]
Topic: PMI Proposal related to matching use cases
16:11:03 [Ian]
PMI proposal was just made available yesterday:
16:11:03 [Ian]
https://github.com/zkoch/zkoch.github.io/blob/master/pmi.md
16:11:21 [AdrianHB]
ian: The propsoal includes a few pieces
16:11:22 [manu]
Ian: The proposal includes a few pieces
16:11:47 [manu]
Ian: The proposal is pretty short, doesn't intend to substitute entirely for entire PMI spec.
16:12:26 [dezell]
dezell has joined #wpwg
16:12:34 [manu]
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 [manu]
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 [ShaneM]
"singleton payment method"
16:13:43 [manu]
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 [manu]
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 [manu]
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 [manu]
Ian: There are two use cases that we should keep in mind:
16:15:11 [Ian]
===
16:15:12 [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.
16:15:12 [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.
16:15:12 [Ian]
====
16:17:10 [manu]
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 [manu]
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 [manu]
q+ to ask what happens when there are extra tags that are unknown to the mediator.
16:18:15 [manu]
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 [MattS]
q+
16:18:23 [Ian]
ack manu
16:18:23 [Zakim]
manu, you wanted to ask what happens when there are extra tags that are unknown to the mediator.
16:18:25 [AdrianHB]
q+
16:18:43 [Ian]
Manu: The general approach sounds good. I have some concerns about URNs but that can be pushed off.
16:18:53 [Ian]
...What happens if a mediator doesn't understand extra information?
16:19:04 [Laurent]
q+ to mention other standards group should able to define 'open' methods
16:19:11 [Ian]
...Basically you are saying "Basic card + constraints"
16:19:29 [Ian]
..what happens when a mediator does not understand one of the constraints?
16:19:58 [Ian]
IJ: Please register an issue against the document.
16:20:41 [manu]
Ian: wrt. URNs, they will be documented in specs.
16:20:44 [Ian]
Manu: How would identifier registry be managed?
16:20:54 [Ian]
q?
16:20:56 [Ian]
ack MattS
16:21:17 [Ian]
MattS: First question - this is in Zach's repository...should we raise issues there or bring into repo?
16:21:32 [Ian]
Adrian: We should pull into proposals folder in the core repo and raise issues in the core repo?
16:21:40 [Ian]
ACTION: AdrianHB to work with Zach to get proposal into W3C repo.
16:21:41 [trackbot]
Error finding 'AdrianHB'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.
16:22:08 [Ian]
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 [manu]
Ian: The actual proposal only includes stuff for the basic card spec
16:23:02 [manu]
Ian: Someone else might create another payment method that does something more.
16:24:02 [AdrianHB]
q?
16:24:13 [manu]
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 [adamR]
q+
16:24:46 [Ian]
MattS: It may not have to be the mediator that does matching.
16:24:50 [manu]
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 [Ian]
..it could be that the payment app could do some of the matching
16:24:53 [adamR]
q-
16:25:07 [Ian]
ack Ad
16:25:19 [Ian]
AdrianHB: I have a bunch of comments.
16:25:26 [Ian]
...first comment on URNs: +1
16:25:45 [Ian]
...solves problem of server load issue with dereferencing (as Mike has pointed out)
16:25:59 [Ian]
...I think "don't dereference" is the right thing here.
16:26:18 [Ian]
...I don't think we need a registry, we are creating one implicitly through the specs
16:26:36 [Ian]
(IJ: +1 to not maintaining a SEPARATE registry in the long term; maybe short term for bootstrapping ok)
16:26:54 [Ian]
AdrianHB: In general I like the approach, specifically the idea between distinguishing Open v. Proprietary
16:27:23 [Ian]
..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 [manu]
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 [Ian]
...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 [Ian]
...so if a new generic payment method comes along, browsers are gatekeepers for new matching semantics
16:28:01 [Ian]
...so that's a potential weakness
16:28:32 [Ian]
...we could address his with a generic tag-based matching algorithm
16:28:54 [Ian]
...so simple tag-based matching + simple enhancements
16:29:08 [Ian]
q+ to talk about going general
16:29:20 [Ian]
AdrianHB: I don't think we should put data-for-mediators in the data blob
16:29:27 [Ian]
...I think that data should be a separate member of the object
16:29:32 [adamR]
q+
16:29:33 [Ian]
...e.g., payment methods, then filters, then data
16:29:40 [Ian]
...I will raise some of these as issues
16:29:41 [MattS]
+1 to seperate filters prop
16:29:43 [Ian]
ack Laurent
16:29:43 [Zakim]
Laurent, you wanted to mention other standards group should able to define 'open' methods
16:29:52 [manu]
+1 to separate tags/filters
16:30:53 [Ian]
Laurent: I think it should be possible for other standards bodies to define open methods.
16:31:13 [MattS]
+1 to other groups ability to publish
16:31:15 [Ian]
(Please raise that issue on the spec)
16:31:34 [Ian]
q?
16:31:47 [Ian]
Laurent: I will raise this on the group's issues list
16:31:49 [Ian]
ack Manu
16:31:49 [Zakim]
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 [Ian]
Manu: Regarding URNs, I think it's good practice to register URNs
16:32:21 [manu]
Take a look at this RFC: https://tools.ietf.org/html/rfc3406#section-3.3
16:32:38 [AdrianHB]
+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 [Ian]
ACTION: AdamR to look into what the right practice is if we use URNs.
16:33:25 [trackbot]
Created ACTION-23 - Look into what the right practice is if we use urns. [on Adam Roach - due 2016-08-04].
16:33:30 [Ian]
ack adamR
16:34:15 [AdrianHB]
+1 to a single URN space and leave it at that
16:34:16 [Ian]
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 [manu]
Ian: We need to decide how other organizations create their own payment methods
16:35:39 [manu]
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 [Ian]
q?
16:35:48 [Ian]
ack me
16:35:48 [Zakim]
Ian, you wanted to talk about going general
16:36:32 [AdrianHB]
q+ to say this proposal lets us compromise
16:36:41 [adamR]
q?
16:36:45 [adamR]
q+
16:37:06 [manu]
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 [manu]
pattern, we can go generic.
16:37:11 [Ian]
IJ: I suggest we try the pattern out a few times before going generic
16:37:31 [Ian]
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 [Ian]
...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 [Ian]
...presumably we could make the matching thing a separate piece of payment request
16:38:41 [Ian]
...the filters could be one thing, and data could be its own thing: data is opaque to mediators; filters are not
16:39:29 [Ian]
...if a payment method is developed outside W3C it can leverage simple matching
16:39:54 [Ian]
...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 [Ian]
q?
16:40:30 [Ian]
...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 [manu]
+1 to pull matching "stuff" out of method-specific data.
16:40:41 [manu]
+1 for basic tag-based matching algorithm
16:41:02 [adamR]
q-
16:41:21 [manu]
I think there is a good middle-ground here.
16:41:28 [Ian]
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 [ShaneM]
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 [manu]
(as in, there is a general approach, but only specific values will work for security reasons.
16:42:24 [Ian]
q?
16:42:27 [Ian]
ack AdrianHB
16:42:27 [Zakim]
AdrianHB, you wanted to say this proposal lets us compromise
16:42:28 [manu]
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 [Ian]
(IJ: seems fine to pull filters out of data; I would have to look more closely)
16:43:02 [AdrianHB]
q?
16:43:22 [Ian]
Topic: Push payments
16:43:28 [Ian]
https://github.com/w3c/browser-payment-api/pull/223
16:43:35 [Laurent]
Laurent has joined #wpwg
16:43:40 [MattS]
q+
16:43:46 [Ian]
AdrianHB: I am ok to make a comment here...this came up at the FTF meeting
16:43:51 [manu]
q+ to mention "push" payments and HTTP API
16:44:20 [Ian]
...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 [Ian]
...e.g., merchant needs to know that they have been paid in order to agree to ship goods
16:44:56 [Ian]
...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 [Ian]
...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 [Ian]
...specifically the risk is that the payment is proceed and the merchant does not receive notice
16:45:58 [Ian]
...I think there are some generic ideas that we can use to get interop, otherwise the space will be fragmented
16:46:15 [AdrianHB]
q?
16:46:28 [Ian]
ack MattS
16:46:35 [Ian]
MattS: +1 to looking at this problem.
16:46:58 [Ian]
...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 [ShaneM]
zakim, agenda?
16:47:15 [Zakim]
I see nothing on the agenda
16:47:21 [Ian]
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 [Ian]
q?
16:47:24 [Ian]
ack Manu
16:47:24 [Zakim]
manu, you wanted to mention "push" payments and HTTP API
16:47:44 [Ian]
Manu: This also affects the HTTP API spec.
16:47:50 [dezell]
present+ dezell (in part)
16:47:59 [Ian]
...+1 to getting people together to look at what happens when the flow breaks at various times
16:48:19 [Ian]
q+ to mention something about breakdowns
16:48:26 [Ian]
ack me
16:48:26 [Zakim]
Ian, you wanted to mention something about breakdowns
16:48:26 [AdrianHB]
ack ia
16:48:43 [manu]
Ian: I had done a bit of analysis w/ Alibaba folks about communication breakdown in the flows.
16:48:56 [manu]
Ian: Under model and design considerations:
16:49:14 [manu]
Ian: The details are somewhere in there, section 8
16:50:03 [manu]
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 [manu]
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 [manu]
Ian: From a standardization standpoint, there is only how we mitigate that flaw in both directions between browser and payment app.
16:51:02 [Ian]
q?
16:52:30 [Ian]
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 [Ian]
Adrian: Who is interested in being part of a mini-task force to discuss this?
16:53:00 [Ian]
q+
16:53:02 [MattS]
I'd like to join
16:53:37 [MattS]
Since it is flows, we could do it as part of the Flows Tasks force?
16:53:43 [manu]
Ian: Let's try to make this more low key.
16:54:32 [MattS]
Also we've looked at this as part of SEPA which is the same task force
16:54:47 [manu]
AdrianHB: We could call this Push Payments analysis - that's all I'm suggesting for now.
16:54:58 [Ian]
Topic: FTF review
16:55:15 [rouslan]
rouslan has joined #wpwg
16:55:15 [manu]
Ian: I wanted to point out that we had some actions from the meeting.
16:55:44 [manu]
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 [manu]
Ian: We had not gotten together w/ the chairs recently.
16:56:14 [MattS]
q+
16:56:27 [manu]
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 [manu]
Ian: Tokenized - laurent, nick, and faraz
16:56:46 [manu]
Ian: Does Laurent want to take ownership of that?
16:57:02 [manu]
AdrianHB: That was the group that wanted to do a slightly more advanced card spec.
16:57:25 [manu]
Laurent: I think we're waiting on Matt for that?
16:57:27 [ShaneM]
There was also some interest in producing a generic payment method guidelines document... right?
16:57:28 [Ian]
Laurent: Status is waiting for something from MattS.
16:57:50 [manu]
AdrianHB: Maybe we should follow up with each of these groups after the meeting.
16:57:59 [MattS]
+1 to that
16:58:07 [MattS]
q-
16:58:24 [Ian]
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 [trackbot]
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 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/28-wpwg-minutes.html Ian
16:59:22 [Ian]
Topic: Next Call
16:59:29 [Ian]
https://lists.w3.org/Archives/Public/public-payments-wg/2016Jul/0147.html
16:59:36 [Ian]
4 Aug same time
16:59:41 [Ian]
but fill out the poll!
17:00:03 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/07/28-wpwg-minutes.html Ian
17:11:58 [alyver]
alyver has joined #wpwg
17:15:28 [alyver]
alyver has left #wpwg
17:19:05 [Mike5]
Mike5 has left #wpwg
17:34:34 [Adam__]
Adam__ has joined #wpwg
17:45:31 [adamlake]
adamlake has joined #wpwg
17:48:28 [Adam_]
Adam_ has joined #wpwg
17:58:47 [Adam__]
Adam__ has joined #wpwg
18:03:52 [sam]
sam has joined #wpwg
18:27:43 [shepazu_]
shepazu_ has joined #wpwg
19:00:33 [Zakim]
Zakim has left #wpwg