See also: IRC log
<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
Question:
<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
<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
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)
https://github.com/w3c/webpayments/wiki/PMI_Notes
<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
+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)
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
https://github.com/w3c/webpayments/wiki/PaymentApp_Notes
https://github.com/w3c/webpayments/wiki/PaymentApp_Notes#data-collection
<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
12 May