Web Payments Working Group Teleconference

05 May 2016


See also: IRC log


Ian, AdamRoach, AdrianBateman, BrianSullivan, zkoch, MaheshK, Roy, AdrianHB, dlongley, manu, ShaneM, alyver, Mike, NickTR, JNormore, nicktr, rouslan, MattS, Katie, Haritos-Shea


July FTF meeting schedule

<manu> Ian: We had been looking to organize a meeting around the 13th 14th and 15th of July in London, but unfortunately there are no W3C team members that can attend then. Management asked us to look for other dates.

<manu> Ian: We're still trying to stay in London - July 6th-8th.

One idea with IG Chairs is to hold 1-day IG meeting in Boston alongside the Blockchain Workshop. Thoughts from the WG?

Blockchain Workshop -> https://www.w3.org/2016/04/blockchain-workshop/

<manu> Ian: Currently chatting w/ Brian at Visa Europe for that meeting. Just chatting w/ IG chairs earlier today. Both folks had challenges... 1 day interest group meeting beside blockchain workshop.

29–30 June 2016, MIT Media Lab, Cambridge, Massachusetts

<manu> Ian: That's what David Ezell proposed.

<manu> Ian: So, new idea as of an hour ago. Brian is going to share some news.

Brian: I spoke with Ian earlier today and am looking to arrange 6-8...looks like 6 and 8 are ok
... hope to have confirmation tomorrow on 7th


<manu> Ian: For the IG meeting, we should check with them. Let's get some feedback from WG on IG co-locating w/ W3C Blockchain workshop

Are you ok with an IG meeting in June next to blockchain workshop?

(+1 => yes! +0 => don't care, -1 => don't want)

<AdrianHB> +1

<manu> manu: +1

<zkoch> +1

<maheshk> +1

<Brian> +0

<roy> +0

<zkoch> Note: 6th is hard for me to get to London, as 4th and 5th are both holidays. So I would fly out morning of the 6th potentially

<alyver> +0

<adamR> +1

IJ: If we move IG meeting, then WG could be7-8 July

<manu> Ian: (discussing alternatives)

<ShaneM> I feel like people going to IETF are going to have trouble going to both IETF and WPWG

<ShaneM> +0 on IG w/blockchain

<manu> Options are: Either W3C Blockchain Workshop + Web Payments IG meeting at end of June... or Web Payments WG + Web Payments IG in early July.


<manu> Adrian: I wanted to have it in London in order to make sure we move things around.

Preference for Boston (near blockchain workshop) or London following week for WG meeting?

<zkoch> Boston

<manu> Boston

<adamR> Boston

<maheshk> Boston

<ShaneM> +1 Boston w/

<Brian> London

<rouslan> London

<nicktr_redux> London

<AdrianHB> London

<manu> Bali?

<zkoch> +1 to Bali

<alyver> +0

<ShaneM> +1 to a WBS poll

<MattS> London

Adopt new proposals as editor's drafts of the WG?

<manu> https://lists.w3.org/Archives/Public/public-payments-wg/2016May/0039.html

manu: I went back through email people sent about the specs
... People have had 4 weeks to review the docs. Any questions?

AdrianHB: Are you looking for co-editors?
... what do you propose?
... we want to resolve who editors will be, which repo etc.

manu: Concrete proposal is for dlongley and manu to edit.
... I am hoping Shane also joins us but we've not talked with him about it yet.
... also invitation to others to edit if they are interested

nicktr_redux: Anybody else on the call want to edit?

[No responses]

<ShaneM> I am willing to serve...

PROPOSED: Take up HTTP API and Core Messages into the group

<nicktr_redux> https://lists.w3.org/Archives/Public/public-payments-wg/2016Apr/0229.html

nicktr_redux: As chair I want to emphasize that while I support the work entering the WG, we agreed would prioritize browser API and payment apps...this would be in the third tier of priorities for now unless the group changes that priority

<nicktr_redux> +1

<MattS> +1

<Ryladog> +1

<rouslan> +0

<AdrianHB> +1 to adopt and priority as stated by nicktr

<zkoch> +0

<dlongley> +1

<manu> +1

<ShaneM> +1

<jnormore> +1

<adamR> +0

<roy> +0

<adrianba> +0

+0 with the understanding that these will not be active in our agenda for now as Nick said

RESOLUTION: Adopt HTTP API and Core messages as deliverables of the WPWG

AdrianHB: Editors, please propose (on the list) short names you want to use

Payment Method Identifiers

adrianhb: This topic went quiet for a while but we need to resolve to advance implementations.
... in the agenda are main questions for us
... see proposal from zach and comments from others -> https://lists.w3.org/Archives/Public/public-payments-wg/2016May/0018.html
... My sense is that group is happy with (absolute) URLs as identifiers.

questions: is there a need for short names or aliases for "commonly used' payment methods?
... and what's the process for minting identifiers?

(see concrete proposed requirements: t must be possible for the Working Group to mint a payment method identifier for any payment method.

It must be possible for the anyone to mint a payment method identifier for a payment method under their control.

It must be possible for someone minting a non-standard identifier to make it globally unique in a cost-effective manner.

It should be possible to use a standard short string to identify common payment methods.


zkoch: I also hear consensus to use absolute URLs.
... they are long and cumbersome, but there are more upsides
... second part of the proposal is that we need to jump-start the ecosystem.
... see zach's list in his proposal https://lists.w3.org/Archives/Public/public-payments-wg/2016May/0018.html
... we think we need to start with credit cards
... and this can facilitate that
... the hope is that by Rec we have a goal of card networks minting URLs
... I've heard concerns about undoing adoption of short strings
... I'm open to thoughts on solving this.

<Zakim> manu, you wanted to ask if we could do a nonsense URLs for Visa before CR, for example - "https://example.org/methods/visa"? and to note that short strings are nice for developers.

manu: +1 to absolute URlos.
... I do have a couple of questions around short strings. Short strings are nice for developers.
... I think we should talk about short strings at some point...but feels like an optimization to me.
... we could use a URL that is "clearly not something meant to stick around" and we want other URLs from card networks
... this avoids the short label debate

<ShaneM> I don't mind using short fake URIs... e.g., https://example.com/visa

manu: and maybe we can push short string discussion to later

<Zakim> AdrianHB, you wanted to clarify base of aliased URLs

adrianhb: I have a question about having a short name alias for something temporarily and later there's an absolute URL from an entity like Amex/Visa.
... but if you define a payment method spec, then the payment method identifiers should use a domain that you control.

<ShaneM> -1 to using a w3.org URI

adrianhb: there is not supposed to be a tight coupling between payment method spec owner and URL owner

<Mike5> what ShaneM said

adrianhb: I'm conscious of the "http traffic" issue

IJ agrees with "It must be possible for the anyone to mint a payment method identifier for a payment method under their control." but does not agree with "If you create a payment method spec, you must also use a payment method identifier that uses the same domain name."

AdamR: +1 to using temporary URLs v. short strings

<AdrianHB> +1 - developers should hardly ever do this

AdamR: note that developers don't really have much of a burden since they only code once.

<manu> +1 to what AdamR is saying

<dlongley> +1 to AdamR

AdamR: the cost of copying URLs v. "visa-debit" seems very small differential
... so I think the value of short names is overstated here.

brian_: On Visa and other payment systems assigning URLs...I think that it might require some time.
... people will ask questions about implications
... so just a heads-up on time-to-mint

<Zakim> nicktr_redux, you wanted to worry about maintainability and granularity of short names

nicktr_redux: I worry about maintainability and granularity of short names
... there are lots of types associated with "visa" and so I am +1 with absolute URLs
... we will depend on early implementations to lay the path for what the identifiers are
... merchants can also define new PMIs anywya
... that might be a mechanism by which their own payment apps can be invoked

<Zakim> zkoch, you wanted to talk about payment methods and ownership

<AdrianHB> ian: do you anticipate the W3C's basic card payments spec referencing URLs like http://visa.com/credit as PMIs

(AHB, I don't know yet, but see no a priori reason not to)

zkoch: Many schemes are proprietary, some are not (e.g., bitcoin)....

<AdrianHB> Ian: I do :)

zkoch: I think that new payment methods are typically owned by an organization and that org should mint the URL
... regarding "temporary bogus URLs" I had not thought about it...I would prefer perhaps a "real URL" but some indication that it's temporary

<Zakim> manu, you wanted to ask how long the process might take at Visa.

zkoch: I'm ok with bogus URLs if we can't come up with something better

manu: How long, Brian, do you think the the process would take? Weeks? Months? Year?
... sounds like consensus on absolute URLs and we should resolve that and get the spec updated
... continue refining other parts of the proposal

brian_: Months
... Also, EMVCo will likely require some consideration and I anticipate "long-ish"

<Zakim> AdrianHB, you wanted to say that all payment methods are being invented by us

AdrianHB: payment method identifiers are new. The payment method is "owned by" the entity that writes the payment method spec.

<zkoch> I don’t agree with that

AdrianHB: the payment method spec says "put this payment in the request, expect this in the response"
... but the payment method spec is not "owned" by a card network
... the idea of us publishing payment method specs is to bootstrap the process
... I think that other orgs (e.g., EMVco) will take up the idea and write their own specs
... but the card payment method is not owned by the scheme/instrument owner

<dlongley> whole point of having extensibility w/respect to payment methods is that waiting for them to arise shouldn't get in the way of the rest of the API

matts: I have a few questions
... What is the expectation about dereferencing?

zkoch: Right now we are making no recommendations.

matts: The list you proposed in your short list does not include some strings that are in the payment method spec....how did you come up with your list?

zkoch: Not very scientifically; looked at prevalence and drew a line in the sane

matts: We have Visa here...we could just shrink the list to those

<ShaneM> +1 to force people to join to get a short name

MattS: On pattern matching....I used "/" to imply partial matching
... what is your view on pattern matching?

<Zakim> MattS, you wanted to ask about partial matching and the links to the basic spec

zkoch: Implicit grouping (visa implies others) and some explicit singletons

<AdrianHB> there is an open question about how we could do some grouping semantics

<manu> Ian: Point of order - grouping semantics are not covered in today's proposal.

<adrianba> +1

<AdrianHB> +1 that grouping is not explicit so we should not address

<adrianba> the pattern matching should be absolute not partial

IJ: I had understood the equivalence test from the payment method spec to be the equivalence test

matts: Should we have a registry?

-1 to a registry

+1 to the web as registry

<zkoch> -1 as well

matts: Proposal feels incomplete to me since there are related issues that are important considerations that are not yet dealt with

nicktr_redux: I was on the queue to address EMVCo point...we have reached out to EMVCo to review the specs...in principle that would be a great place for these URLs to live
... like Brian I think it may take some time

<Zakim> manu, you wanted to disagree w/ AdrianHB - I think Visa would have a problem w/ not "owning" the PMI and the data served from that URL. We don't want to unnecessarily create

Manu: I think we should be careful about "ownership" of PMIs

<adrianba> my proposal: sounds like we can update the spec to use URLs, remove short names, and keep pending issues on partial matching, short names, registry, etc.

Manu: It might create confusion if there were two PMIs owned by different parties for the same Payment Method

<AdrianHB> They MAY provide a URL if they want to but there is not a requirement

Manu: If we think emvco is the right place, we could push it at them and ask them to confirm it's the right URL
... To MattS's point, it's an incomplete proposal, but I think it allows us to advance.

<zkoch> +1 to just adopting absolute URLs at this point

<dlongley> +1 to adopting absolute URLs

<MattS> reverse domain identifiers have benfits when you look at pattern matching IMO

<adamR> +1 to “all identefiers are absolute URLs”

<manu> MattS, true - but you can't dereference them (in a standard way)


<manu> MattS, as in - there is no spec for translating a reverse domain to a URL for retrieval (that I know of)

<MattS> true, I just say this that without looking at all the items, it is difficult to rule any out, I do feel that URLs is the way to go on balance#

<AdrianHB> PROPOSAL: Use absolute URLs as payment method identifiers?

<manu> +1


<MattS> +0

<zkoch> +1

<adamR> +1

<nicktr_redux> +0

<Andrew> +1

<AdrianHB> +1

<jnormore> +1

<adrianba> +1

<ShaneM> +1 to absuri

<rouslan> +0

<dlongley> +1

RESOLUTION: Payment Method Identifiers will be absolute URLs

(And we'll continue to look at other topics like grouping)

Requesting user data (not just shipping address and options)

AdrianHB recaps:


PR 174 - Adding support for phone and email

PR 65 - Change the way we request user data (PR withdrawn? - @zkoch)

Issue 1 - Requesting email and phone number

Issue 27 - Should API support billing address capture (for tax computation)?


<zkoch> I’m happy with Adrianba’s proposal, so happy to drop mine in support of his

adrianba: My goal here is to address the narrow idea of phone and email that we discussed at the FTF meeting

<zkoch> My original: https://github.com/w3c/browser-payment-api/pull/65

<zkoch> Adrianba’s counter: https://github.com/w3c/browser-payment-api/pull/174

adrianba: there are two phone numbers typically used -- payer phone [e.g., for billing enquiries], shipping phone [e.g., for fedex or UPS that require it often]
... my proposal adds flag to collect payer's email address, flag to capture payer phone, flag to capture shipping address phone
... we could have an additional flag to only collect phone(s) when necessary
... I feel like we should start with the simpler proposal and get experience

adrianhb: Related issues: #1, #27 (billing address) for tax computation

adrianba: Regarding address for tax computation (e.g., Europe)
... I have a proposal for that that I haven't yet written up
... it would cause merge conflicts with pending merges
... once we have done the merge, I will submit a request

<Zakim> manu, you wanted to note that he doesn't want to block progress, but the whole gather customer info seems like it should be a separate API and it's muddying the discussion around

manu: I don't want to block progress, but am concerned about collecting customer information
... we are adding more data
... I know that supporters of these proposals want to limit it heavily
... but the list keeps growing
... I am +1 to adding phone and email, but the more we add the more complex the API
... if we want to address shopping cart abandonment, we should update our charter to address information gathering in a more generalized way
... this is because we are conflating payment request with gathering customer information
... if we do these things, we need defaults

<dlongley> +1 to this feeling like we're hacking little bits together in a slow painful way and I worry we're going to build this piecemeal thing that keeps needing more hacks added over time.

matts: Here is why I think this is a bad idea at this stage...email and phone number are linked to specific payment methods
... if I understand this is for mediator capture, right?
... problem is that when we start adding new methods like union pay or paypal
... we are going to get overlapping credentials / pieces of data
... I don't think the the options are the right way, but rather the payment method data
... Issue 143 talks about semantics of capturing payment method data
... I suggest we tackle that before we add GLOBAL pieces of data outside of the payment app

zkoch: We want to get the minimal information to get through a checkout flow.

<dlongley> +1 to letting Payment Apps collect this data as payment method data and provide an API that Web-based Payment Apps can call to get this data from the browser.

zkoch: I think its's about being pragmatic

<Zakim> zkoch, you wanted to talk about why

<Zakim> AdrianHB, you wanted to talk about counter-proposals

adamR: I don't have a strong opinion on adding fields. But every field we add needs to be auto-fillable
... I think free-form proposals are to be avoided
... and things like coupon codes that are transaction specific don't belong here

nicktr_redux: Who supports PR #174?

<zkoch> +1

<adrianba> +1

<MattS> -1

<rouslan> +1

<manu> +1

<adamR> +0

<AdrianHB> +0

<dlongley> +0

<ShaneM> +0

+1 but I'd like to also address Matt's concern (which I've also raised as an issue)

<brian_> +0

<Mike5> +1

IJ: Two ideas for moving forward (1) decide over objection (2) ask Matts and Zach to work on it

Nick: +1 to Ian's suggestion #2

<nicktr_redux> I think it's matts and adrianba

<dlongley> bad user experience when you have redundancy.

matts: I am not saying the API should NOT capture it...just want to consider it as part of payment data ...I would support that

adrianhb: When we accept this proposal we are accepting two things:

- the functionality

- the way the functionality is being defined

adrianhb: I am hearing consensus on "the functionality" here and not yet consensus on how

<manu> +1 to the functionality, -1 to the way the feature is exposed.

<manu> it's not a solid design, feels hacked together to achieve a very specific purpose.

adrianhb: So I'd like to see counter-proposal on how to achieve Zach's stated objective

<dlongley> +1 to functionality, -1 to how it's being done (but admittedly, i think it's really complex)

nick: So proposal not carried at this stage. Suggest MattS+Zach chat and come up with counterproposal



<nicktr_redux> thank you everyone

<dlongley> if we're collecting data from the browser in different places, that seems to indicate we should have a separate API for it

Next meeting

12 May

Summary of Action Items

Summary of Resolutions

  1. Adopt HTTP API and Core messages as deliverables of the WPWG
  2. Payment Method Identifiers will be absolute URLs
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/05/05 17:13:06 $