Web Payments Working Group Teleconference

<scribe> scribe: Ian

Where are we with publishing HTTP-API and Core messages for FPWD?

Adrian: I think it is premature and I would object to issuing a call for consensus
... 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.
... 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.

Manu: I've sent some comments; no replies yet

AdrianHB: I've been traveling; sorry for the delay

Manu: Great

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.
... I hope to respond by week's end

-> Agenda https://github.com/w3c/webpayments/wiki/Agenda-20160728

Adrian: I have been traveling a lot; sorry for silence; back at home now. Thanks to Ian for carrying the baton
... note that the payment apps task force is sending agendas and minutes to the WG's list

TPAC 2016

https://www.w3.org/2002/09/wbs/35125/TPAC2016/?login

https://github.com/w3c/webpayments/wiki/FTF-Sep2016

<manu> Ian: Please register as soon as possible. The rate goes up after September 2nd

<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.

PLEASE REGISTER!

AdrianHB: We meet for 2 days and want to set some goals. We meet Monday and Tuesday
... also suggest hanging around for the plenary day (Weds) as well as Thursday and Friday (IG meeting)
... in terms of setting the agenda, it would be great for group participants who have specific goals to put them in the wiki

TPAC is in Lisbon

TPAC is 19-23 Sep

WG meeting is 19-20 Sep

PMI Proposal related to matching use cases

PMI proposal was just made available yesterday:

https://github.com/zkoch/zkoch.github.io/blob/master/pmi.md

<AdrianHB> ian: The propsoal includes a few pieces

<manu> Ian: The proposal includes a few pieces

<manu> Ian: The proposal is pretty short, doesn't intend to substitute entirely for entire PMI spec.

<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).

<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.

<ShaneM> "singleton payment method"

<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.

<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.

<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.

<manu> Ian: There are two use cases that we should keep in mind:

===

The merchant accepts both Visa Credit and Visa Debit. Merchant wishes to charge a differential price for specific types, most commonly credit vs debit.

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.

====

<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

<manu> at implement that payment method would also have to implement. Per payment method matching semantics is noted in this specification as well.

<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.

<Zakim> manu, you wanted to ask what happens when there are extra tags that are unknown to the mediator.

Manu: The general approach sounds good. I have some concerns about URNs but that can be pushed off.
... What happens if a mediator doesn't understand extra information?
... Basically you are saying "Basic card + constraints"
... what happens when a mediator does not understand one of the constraints?

IJ: Please register an issue against the document.

<manu> Ian: wrt. URNs, they will be documented in specs.

Manu: How would identifier registry be managed?

MattS: First question - this is in Zach's repository...should we raise issues there or bring into repo?

Adrian: We should pull into proposals folder in the core repo and raise issues in the core repo?

<scribe> ACTION: AdrianHB to work with Zach to get proposal into W3C repo. [recorded in http://www.w3.org/2016/07/28-wpwg-minutes.html#action01]

<trackbot> Error finding 'AdrianHB'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.

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.

<manu> Ian: The actual proposal only includes stuff for the basic card spec

<manu> Ian: Someone else might create another payment method that does something more.

<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.

MattS: It may not have to be the mediator that does matching.

<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.

MattS: it could be that the payment app could do some of the matching

AdrianHB: I have a bunch of comments.
... first comment on URNs: +1
... solves problem of server load issue with dereferencing (as Mike has pointed out)
... I think "don't dereference" is the right thing here.
... I don't think we need a registry, we are creating one implicitly through the specs

(IJ: +1 to not maintaining a SEPARATE registry in the long term; maybe short term for bootstrapping ok)

AdrianHB: In general I like the approach, specifically the idea between distinguishing Open v. Proprietary
... 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
... my biggest concern is that for the generic methods we are putting a lot behind the mediators behind the browsers to make changes
... so if a new generic payment method comes along, browsers are gatekeepers for new matching semantics
... so that's a potential weakness
... we could address his with a generic tag-based matching algorithm
... so simple tag-based matching + simple enhancements
... I don't think we should put data-for-mediators in the data blob
... I think that data should be a separate member of the object
... e.g., payment methods, then filters, then data
... I will raise some of these as issues

<MattS> +1 to seperate filters prop

<Zakim> Laurent, you wanted to mention other standards group should able to define 'open' methods

<manu> +1 to separate tags/filters

Laurent: I think it should be possible for other standards bodies to define open methods.

<MattS> +1 to other groups ability to publish

(Please raise that issue on the spec)

Laurent: I will raise this on the group's issues list

<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

Manu: Regarding URNs, I think it's good practice to register URNs

<manu> Take a look at this RFC: https://tools.ietf.org/html/rfc3406#section-3.3

<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

<scribe> ACTION: AdamR to look into what the right practice is if we use URNs. [recorded in http://www.w3.org/2016/07/28-wpwg-minutes.html#action02]

<trackbot> Created ACTION-23 - Look into what the right practice is if we use urns. [on Adam Roach - due 2016-08-04].

<AdrianHB> +1 to a single URN space and leave it at that

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.

<manu> Ian: We need to decide how other organizations create their own payment methods

<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.

<Zakim> Ian, you wanted to talk about going general

<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

<manu> pattern, we can go generic.

IJ: I suggest we try the pattern out a few times before going generic

ack AdrianHB: My response to that is that if we adopt something like this proposal, we have an opportunity to compromise a bit.

scribe: 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)
... presumably we could make the matching thing a separate piece of payment request
... the filters could be one thing, and data could be its own thing: data is opaque to mediators; filters are not
... if a payment method is developed outside W3C it can leverage simple matching
... 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
... 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

<manu> +1 to pull matching "stuff" out of method-specific data.

<manu> +1 for basic tag-based matching algorithm

<manu> I think there is a good middle-ground here.

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.

<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

<manu> (as in, there is a general approach, but only specific values will work for security reasons.

<Zakim> AdrianHB, you wanted to say this proposal lets us compromise

<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.

(IJ: seems fine to pull filters out of data; I would have to look more closely)

Push payments

https://github.com/w3c/browser-payment-api/pull/223

AdrianHB: I am ok to make a comment here...this came up at the FTF meeting
... when we look at push methods, if a payment app is processing the payment, then there are new communications issues that arise
... e.g., merchant needs to know that they have been paid in order to agree to ship goods
... Roy's proposal is to include an event ... I personally think this proposal won't work, but I agree that we need something
... 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?"
... specifically the risk is that the payment is proceed and the merchant does not receive notice
... I think there are some generic ideas that we can use to get interop, otherwise the space will be fragmented

MattS: +1 to looking at this problem.
... 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

AdrianHB: +1 to taking a step back to look more closely at the problem statement and getting clarity before we propose spec changes

<Zakim> manu, you wanted to mention "push" payments and HTTP API

Manu: This also affects the HTTP API spec.
... +1 to getting people together to look at what happens when the flow breaks at various times

<Zakim> Ian, you wanted to mention something about breakdowns

<manu> Ian: I had done a bit of analysis w/ Alibaba folks about communication breakdown in the flows.

<manu> Ian: Under model and design considerations:

<manu> Ian: The details are somewhere in there, section 8

<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.

<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.

<manu> Ian: From a standardization standpoint, there is only how we mitigate that flaw in both directions between browser and payment app.

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

Adrian: Who is interested in being part of a mini-task force to discuss this?

<MattS> I'd like to join

<MattS> Since it is flows, we could do it as part of the Flows Tasks force?

<manu> Ian: Let's try to make this more low key.

<MattS> Also we've looked at this as part of SEPA which is the same task force

<manu> AdrianHB: We could call this Push Payments analysis - that's all I'm suggesting for now.

FTF review

<manu> Ian: I wanted to point out that we had some actions from the meeting.

<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.

<manu> Ian: We had not gotten together w/ the chairs recently.

<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...

<manu> Ian: Tokenized - laurent, nick, and faraz

<manu> Ian: Does Laurent want to take ownership of that?

<manu> AdrianHB: That was the group that wanted to do a slightly more advanced card spec.

<manu> Laurent: I think we're waiting on Matt for that?

<ShaneM> There was also some interest in producing a generic payment method guidelines document... right?

Laurent: Status is waiting for something from MattS.

<manu> AdrianHB: Maybe we should follow up with each of these groups after the meeting.

<MattS> +1 to that

<scribe> 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 [recorded in http://www.w3.org/2016/07/28-wpwg-minutes.html#action03]

<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].

Next Call

https://lists.w3.org/Archives/Public/public-payments-wg/2016Jul/0147.html

4 Aug same time

but fill out the poll!