15:56:46 <RRSAgent> RRSAgent has joined #wpwg
15:56:46 <RRSAgent> logging to http://www.w3.org/2016/05/05-wpwg-irc
15:56:48 <trackbot> RRSAgent, make logs public
15:56:48 <Zakim> Zakim has joined #wpwg
15:56:50 <trackbot> Zakim, this will be
15:56:50 <Zakim> I don't understand 'this will be', trackbot
15:56:51 <trackbot> Meeting: Web Payments Working Group Teleconference
15:56:51 <trackbot> Date: 05 May 2016
15:57:04 <Ian> agenda: https://github.com/w3c/webpayments/wiki/Agenda-20160505
15:57:16 <Ian> scribe: Ian
15:59:12 <Ian> present+ Ian
15:59:15 <Ian> present+ AdamRoach
15:59:21 <Ian> present+ AdrianBateman
15:59:30 <Ian> present+ BrianSullivan
15:59:51 <zkoch> zkoch has joined #wpwg
16:00:05 <Brian> Brian has joined #wpwg
16:00:37 <zkoch> present+
16:00:47 <Ian> present+ MaheshK
16:00:54 <Ian> present+ Roy
16:01:11 <alyver> alyver has joined #wpwg
16:01:12 <zkoch> WebEx got a facelift (at least on os x). So modern. Much flat. Wow.
16:01:19 <AdrianHB> Present+
16:01:58 <dlongley> present+
16:02:00 <Ian> agenda -> https://github.com/w3c/webpayments/wiki/Agenda-20160505
16:02:27 <manu> present+ manu
16:02:39 <manu> present+ dlongley
16:02:40 <dlongley> present+ dlongley
16:02:44 <manu> present+ zkoch
16:03:01 <zkoch> :(
16:03:02 <ShaneM> present+ ShaneM
16:03:09 <alyver> present+ alyver
16:03:14 <Mike5> present
16:03:20 <AdrianHB> present+ AdrianHB
16:03:22 <Mike5> present+
16:03:46 <nicktr> nicktr has joined #wpwg
16:03:47 <maheshk> maheshk has joined #wpwg
16:03:54 <jnormore> jnormore has joined #wpwg
16:04:04 <Ian> present+ NickTR
16:04:09 <zkoch> Yeah, I don’t think I’ve done that… so… present+ zkoch it is!
16:04:11 <Ian> zakim, who's here?
16:04:11 <Zakim> Present: Ian, AdamRoach, AdrianBateman, BrianSullivan, zkoch, MaheshK, Roy, AdrianHB, dlongley, manu, ShaneM, alyver, Mike, NickTR
16:04:14 <Zakim> On IRC I see jnormore, maheshk, nicktr, alyver, Brian, zkoch, Zakim, RRSAgent, yaso, adamR, shepazu, ShaneM, slightlyoff, mkwst, schuki_, collier-matthew, dlongley, manu, wseltzer,
16:04:14 <Zakim> ... hober, trackbot, dlehn, Mike5, AdrianHB, adrianba, davidillsley, dwim_, Ian
16:04:28 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/05-wpwg-minutes.html Ian
16:04:52 <Ian> present+ JNormore
16:05:15 <roy> roy has joined #wpwg
16:05:28 <Ian> Topic:
16:05:30 <Ian> Topic:
16:05:30 <Ian> July FTF meeting schedule
16:05:37 <Ian> Topic: July FTF meeting schedule
16:05:41 <nicktr> present+ nicktr
16:06:05 <nick_tr> nick_tr has joined #wpwg
16:06:15 <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.
16:06:24 <manu> Ian: We're still trying to stay in London - July 6th-8th.
16:06:41 <Ian> One idea with IG Chairs is to hold 1-day IG meeting in Boston alongside the Blockchain Workshop. Thoughts from the WG?
16:07:08 <Ian> Blockchain Workshop -> https://www.w3.org/2016/04/blockchain-workshop/
16:07:11 <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.
16:07:15 <Ian> 29–30 June 2016, MIT Media Lab, Cambridge, Massachusetts
16:07:16 <Brian> q+
16:07:23 <manu> Ian: That's what David Ezell proposed.
16:07:31 <Ian> ack Brian
16:07:34 <manu> Ian: So, new idea as of an hour ago. Brian is going to share some news.
16:07:51 <Ian> Brian: I spoke with Ian earlier today and am looking to arrange 6-8...looks like 6 and 8 are ok
16:07:55 <Ian> ...hope to have confirmation tomorrow on 7th
16:08:30 <Ian> Questoin:
16:08:37 <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
16:08:46 <Ian> Are you ok with an IG meeting in June next to blockchain workshop?
16:08:51 <AdrianHB> +1
16:08:52 <manu> manu: +1
16:08:54 <rouslan> rouslan has joined #wpwg
16:09:01 <Ian> (+1 => yes! +0 => don't care, -1 => don't want)
16:09:04 <zkoch> +1
16:09:05 <maheshk> +1
16:09:11 <rouslan> present+
16:09:17 <ShaneM> present+ rouslan
16:09:18 <manu> present+ rouslan
16:09:28 <Brian> +0
16:09:43 <roy> +0
16:09:50 <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
16:09:51 <alyver> +0
16:10:01 <adamR> +1
16:10:04 <nicktr_redux> nicktr_redux has joined #wpwg
16:10:07 <nicktr_redux> q?
16:10:15 <Ian> IJ: If we move IG meeting, then WG could be7-8 July
16:10:17 <manu> Ian: (discussing alternatives)
16:10:30 <ShaneM> I feel like people going to IETF are going to have trouble going to both IETF and WPWG
16:10:40 <ShaneM> +0 on IG w/blockchain
16:11:00 <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.
16:12:36 <Ian> ========
16:12:40 <manu> Adrian: I wanted to have it in London in order to make sure we move things around.
16:12:52 <Ian> Preference for Boston (near blockchain workshop) or London following week for WG meeting?
16:12:57 <nicktr_redux> q?
16:12:58 <MattS> MattS has joined #wpwg
16:13:00 <zkoch> Boston
16:13:00 <manu> Boston
16:13:01 <adamR> Boston
16:13:03 <maheshk> Boston
16:13:04 <MattS> present+ MattS
16:13:04 <ShaneM> +1 Boston w/
16:13:05 <Brian> London
16:13:06 <rouslan> London
16:13:08 <nicktr_redux> London
16:13:14 <AdrianHB> London
16:13:18 <manu> Bali?
16:13:24 <zkoch> +1 to Bali
16:13:26 <alyver> +0
16:13:42 <ShaneM> +1 to a WBS poll
16:13:56 <MattS> London
16:14:33 <Ian> topic:
16:14:33 <Ian> Adopt new proposals as editor's drafts of the WG?
16:14:36 <Ian> Topic: Adopt new proposals as editor's drafts of the WG?
16:14:51 <manu> https://lists.w3.org/Archives/Public/public-payments-wg/2016May/0039.html
16:14:59 <Ian> manu: I went back through email people sent about the specs
16:15:27 <Ian> manu: People have had 4 weeks to review the docs. Any questions?
16:15:28 <nicktr_redux> q?
16:15:33 <AdrianHB> q+
16:15:35 <ShaneM> q+ to ask about editors
16:15:42 <ShaneM> q-
16:15:51 <Ian> AdrianHB: Are you looking for co-editors?
16:16:01 <Ian> ...what do you propose?
16:16:02 <brian_> brian_ has joined #wpwg
16:16:11 <Ian> ...we want to resolve who editors will be, which repo etc.
16:16:20 <Ian> manu: Concrete proposal is for dlongley and manu to edit.
16:16:30 <Ian> ...I am hoping Shane also joins us but we've not talked with him about it yet.
16:16:44 <Ian> ...also invitation to others to edit if they are interested
16:16:52 <Ian> nicktr_redux: Anybody else on the call want to edit?
16:16:54 <Ian> [No responses]
16:17:02 <ShaneM> I am willing to serve...
16:17:12 <Ian> PROPOSED: Take up HTTP API and Core Messages into the group
16:17:28 <nicktr_redux> https://lists.w3.org/Archives/Public/public-payments-wg/2016Apr/0229.html
16:17:58 <Ian> 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
16:17:59 <Ryladog> Ryladog has joined #wpwg
16:18:11 <nicktr_redux> +1
16:18:11 <Ryladog> Present+ Katie Haritos-Shea
16:18:13 <MattS> +1
16:18:14 <Ryladog> +1
16:18:16 <rouslan> +0
16:18:17 <AdrianHB> +1 to adopt and priority as stated by nikctr
16:18:18 <zkoch> +0
16:18:20 <dlongley> +1
16:18:21 <manu> +1
16:18:22 <ShaneM> +1
16:18:23 <jnormore> +1
16:18:28 <adamR> +0
16:18:28 <roy> +0
16:18:29 <adrianba> +0
16:18:30 <Ian> +0 with the understanding that these will not be active in our agenda for now as Nick said
16:18:52 <Ian> RESOLVED: Adopt HTTP API and Core messages as deliverables of the WPWG
16:18:56 <AdrianHB> s/nikctr/nicktr/
16:19:06 <nicktr_redux> q?
16:19:11 <nicktr_redux> ack AdrianHB
16:19:12 <Ian> AdrianHB: Editors, please propose (on the list) short names you want to use
16:19:25 <Ian> topic: Payment Method Identifiers
16:19:42 <Ian> adrianhb: This topic went quiet for a while but we need to resolve to advance implementations.
16:19:49 <Ian> ....in the agenda are main questions for us
16:20:04 <Ian> ...see proposal from zach and comments from others -> https://lists.w3.org/Archives/Public/public-payments-wg/2016May/0018.html
16:20:20 <Ian> adrianhb: My sense is that group is happy with (absolute) URLs as identifiers.
16:20:37 <Ian> questions: is there a need for short names or aliases for "commonly used' payment methods?
16:20:46 <Andrew> Andrew has joined #wpwg
16:20:46 <Ian> ...and what's the process for minting identifiers?
16:21:25 <Ian> (see concrete proposed requirements: t must be possible for the Working Group to mint a payment method identifier for any payment method.
16:21:25 <Ian> It must be possible for the anyone to mint a payment method identifier for a payment method under their control.
16:21:25 <Ian> It must be possible for someone minting a non-standard identifier to make it globally unique in a cost-effective manner.
16:21:26 <Ian> It should be possible to use a standard short string to identify common payment methods.
16:21:30 <Ian> )
16:21:35 <Ian> zkoch: I also hear consensus to use absolute URLs.
16:21:45 <Ian> ...they are long and cumbersome, but there are more upsides
16:21:58 <Ian> ...second part of the proposal is that we need to jump-start the ecosystem.
16:22:16 <Ian> ...see zach's list in his proposal https://lists.w3.org/Archives/Public/public-payments-wg/2016May/0018.html
16:22:38 <AdrianHB> q?
16:22:39 <Ian> ...we think we need to start with credit cards
16:22:46 <Ian> ...and this can facilitate that
16:23:03 <Ian> ...the hope is that by Rec we have a goal of card networks minting URLs
16:23:15 <Ian> ...I've heard concerns about undoing adoption of short strings
16:23:21 <manu> q+ to ask if we could do a nonsense URLs for Visa before CR, for example - "https://example.org/methods/visa"?
16:23:22 <AdrianHB> q+ to clarify base of aliased URLs
16:23:24 <Ian> ...I'm open to thoughts on solving this.
16:23:27 <manu> q+ to note that short strings are nice for developers.
16:23:44 <adamR> q+
16:23:50 <brian_> q+
16:23:58 <Ian> ack manu
16:23:58 <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.
16:24:01 <nicktr_redux> q+ to worry about maintainability and granularity of short names
16:24:09 <Ian> manu: +1 to absolute URlos.
16:24:31 <Ian> ..I do have a couple of questions around short strings. Short strings are nice for developers.
16:24:45 <Ian> ...I think we should talk about short strings at some point...but feels like an optimization to me.
16:25:16 <Ian> ...we could use a URL that is "clearly not something meant to stick around" and we want other URLs from card networks
16:25:25 <Ian> ...this avoids the short label debate
16:25:33 <ShaneM> I don't mind using short fake URIs... e.g., https://example.com/visa
16:25:40 <Mike5> q?
16:25:46 <Ian> ..and maybe we can push short string discussion to later
16:25:53 <nicktr_redux> q?
16:25:54 <Ian> ack adrianhb
16:25:56 <Zakim> AdrianHB, you wanted to clarify base of aliased URLs
16:26:25 <Ian> 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.
16:26:49 <Ian> ...but if you define a payment method spec, then the payment method identifiers should use a domain that you control.
16:27:12 <ShaneM> -1 to using a w3.org URI
16:27:27 <Ian> ...there is not supposed to be a tight coupling between payment method spec owner and URL owner
16:27:31 <Mike5> what ShaneM said
16:27:38 <Ian> ...I'm conscious of the "http traffic" issue
16:27:47 <nicktr_redux> q?
16:27:59 <nicktr_redux> ack adamR
16:28:11 <Ian> 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."
16:28:25 <Ian> AdamR: +1 to using temporary URLs v. short strings
16:28:32 <zkoch> q+ to talk about payment methods and ownership
16:28:35 <AdrianHB> +1 - developers should hardly ever do this
16:28:36 <Ian> ...note that developers don't really have much of a burden since they only code once.
16:28:41 <manu> +1 to what AdamR is saying
16:28:46 <dlongley> +1 to AdamR
16:28:48 <Ian> ...the cost of copying URLs v. "visa-debit" seems very small differential
16:28:54 <Ian> ...so I think the value of short names is overstated here.
16:29:14 <Ian> brian_: On Visa and other payment systems assigning URLs...I think that it might require some time.
16:29:25 <Ian> ...people will ask questions about implications
16:29:26 <nicktr_redux> q?
16:29:29 <Ian> ..so just a heads-up on time-to-mint
16:29:31 <nicktr_redux> ack brian_
16:29:33 <manu> q+ to ask how long the process might take at Visa.
16:29:34 <nicktr_redux> ack me
16:29:35 <Zakim> nicktr_redux, you wanted to worry about maintainability and granularity of short names
16:29:51 <Ian> nicktr_redux: I worry about maintainability and granularity of short names
16:29:59 <AdrianHB> q?
16:30:01 <brian_> q+
16:30:17 <Ian> ...there are lots of types associated with "visa" and so I am +1 with absolute URLs
16:30:30 <Ian> ...we will depend on early implementations to lay the path for what the identifiers are
16:30:36 <Ian> ...merchants can also define new PMIs anywya
16:30:45 <nicktr_redux> q?
16:30:48 <Ian> ...that might be a mechanism by which their own payment apps can be invoked
16:30:52 <Ian> ack zkoch
16:30:52 <Zakim> zkoch, you wanted to talk about payment methods and ownership
16:30:52 <AdrianHB> ian: do you anticipate the W3C's basic card payments spec referencing URLs like http://visa.com/credit as PMIs
16:31:09 <Ian> (AHB, I don't know yet, but see no a priori reason not to)
16:31:30 <Ian> zkoch: Many schemes are proprietary, some are not (e.g., bitcoin)....
16:31:37 <AdrianHB> Ian: I do :)
16:31:45 <Ian> ...I think that new payment methods are typically owned by an organization and that org should mint the URL
16:32:00 <AdrianHB> q+ to say that all payment methods are being invented by us
16:32:13 <Ian> ...regarding "temporary bogus URLs" I had not thought about it...I would prefer perhaps a "real URL" but some indication that it's temporary
16:32:25 <nicktr_redux> q?
16:32:29 <manu> ack manu
16:32:29 <Zakim> manu, you wanted to ask how long the process might take at Visa.
16:32:29 <nicktr_redux> ack manu
16:32:34 <Ian> zkoch: I'm ok with bogus URLs if we can't come up with something better
16:32:56 <Ian> manu: How long, Brian, do you think the the process would take? Weeks? Months? Year?
16:33:17 <Ian> ...sounds like consensus on absolute URLs and we should resolve that and get the spec updated
16:33:21 <nicktr_redux> q?
16:33:25 <Ian> ..continue refining other parts of the proposal
16:33:26 <MattS> q+ to ask about partial matching and the links to the basic spec
16:33:27 <nicktr_redux> ack brian_
16:33:33 <Ian> brian_: Months
16:34:18 <nicktr_redux> q+
16:34:40 <Ian> brian_: Also, EMVCo will likely require some consideration and I anticipate "long-ish"
16:34:48 <Ian> ack AdrianHB
16:34:48 <Zakim> AdrianHB, you wanted to say that all payment methods are being invented by us
16:34:49 <nicktr_redux> ack AdrianHB
16:35:32 <Ian> AdrianHB: payment method identifiers are new. The payment method is "owned by" the entity that writes the payment method spec.
16:35:38 <zkoch> I don’t agree with that
16:35:49 <Ian> ..the payment method spec says "put this payment in the request, expect this in the response"
16:35:57 <Ian> ...but the payment method spec is not "owned" by a card network
16:36:14 <Ian> ..the idea of us publishing payment method specs is to bootstrap the process
16:36:27 <manu> q+ 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 conflict.
16:36:27 <Ian> ...I think that other orgs (e.g., EMVco) will take up the idea and write their own specs
16:36:37 <nicktr_redux> q?
16:36:38 <Ian> ....but the card payment method is not owned by the scheme/instrument owner
16:36:49 <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
16:36:55 <Ian> matts: I have a few questions
16:37:13 <Ian> matts: What is the expectation about dereferencing?
16:37:23 <AdrianHB> q?
16:37:25 <Ian> zkoch: Right now we are making no recommendations.
16:37:54 <Ian> 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?
16:38:12 <Ian> zkoch: Not very scientifically; looked at prevalence and drew a line in the sane
16:38:31 <Ian> matts: We have Visa here...we could just shrink the list to those
16:38:32 <ShaneM> +1 to force people to join to get a short name
16:38:51 <Ian> MattS: On pattern matching....I used "/" to imply partial matching
16:38:54 <Ian> q+
16:39:06 <Ian> ..what is your view on pattern matching?
16:39:06 <nicktr_redux> ack MattS
16:39:06 <Zakim> MattS, you wanted to ask about partial matching and the links to the basic spec
16:39:24 <Ian> zkoch: Implicit grouping (visa implies others) and some explicit singletons
16:39:29 <AdrianHB> there is an open question about how we could do some grouping semantics
16:39:59 <manu> Ian: Point of order - grouping semantics are not covered today.
16:40:06 <adrianba> +1
16:40:08 <manu> s/covered today/covered in today's proposal/
16:40:11 <AdrianHB> +1 that grouping is not explicit so we should not address
16:40:19 <AdrianHB> q?
16:40:27 <adrianba> the pattern matching should be absolute not partial
16:41:00 <Ian> IJ: I had understood the equivalence test from the payment method spec to be the equivalence test
16:41:04 <AdrianHB> q+ to suggest we get consensus on URLs as there is no consensus yet on the other issues
16:41:08 <Ian> matts: Should we have a registry?
16:41:12 <Ian> -1 to a registry
16:41:18 <Ian> +1 to the web as registry
16:41:21 <zkoch> -1 as well
16:41:37 <alyver> alyver has joined #wpwg
16:41:48 <alyver> alyver has left #wpwg
16:41:48 <Ian> matts: Proposal feels incomplete to me since there are related issues that are important considerations that are not yet dealt with
16:41:53 <manu> q+ to say we can strike other approaches down at this point - such as reverse domain.
16:42:15 <Ian> 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
16:42:25 <Ian> ...like Brian I think it may take some time
16:42:29 <nicktr_redux> ack me
16:42:29 <manu> q+ to suggest playing hot potato w/ EMVCo
16:42:33 <Ian> ack manu
16:42:33 <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
16:42:34 <manu> ack manu
16:42:36 <Zakim> ... conflict. and to say we can strike other approaches down at this point - such as reverse domain. and to suggest playing hot potato w/ EMVCo
16:42:55 <Ian> Manu: I think we should be careful about "ownership" of PMIs
16:43:10 <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.
16:43:17 <nicktr_redux> zakim, close the queue
16:43:17 <Zakim> ok, nicktr_redux, the speaker queue is closed
16:43:38 <Ian> Manu: It might create confusion if there were two PMIs owned by different parties for the same Payment Method
16:43:42 <manu> ack manu
16:43:50 <AdrianHB> They MAY provide a URL if they want to but there is not a requirement
16:44:14 <Ian> 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
16:44:27 <MattS> q+ to discuss a mapping of PMI to payment issuers
16:44:43 <brian_> q+
16:44:59 <Ian> Manu: To MattS's point, it's an incomplete proposal, but I think it allows us to advance.
16:45:04 <zkoch> +1 to just adopting absolute URLs at this point
16:45:10 <dlongley> +1 to adopting absolute URLs
16:45:17 <MattS> reverse domain identifiers have benfits when you look at pattern matching IMO
16:45:24 <adamR> +1 to “all identefiers are absolute URLs”
16:45:50 <manu> MattS, true - but you can't dereference them (in a standard way)
16:46:03 <Ian> https://github.com/w3c/webpayments/wiki/PMI_Notes
16:46:17 <manu> MattS, as in - there is no spec for translating a reverse domain  to a URL for retrieval (that I know of)
16:46:21 <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#
16:46:23 <AdrianHB> PROPOSAL: Use absolute URLs as payment method identifiers?
16:46:30 <manu> +1
16:46:31 <Ian> +1
16:46:42 <MattS> +0
16:46:43 <zkoch> +1
16:46:46 <adamR> +1
16:46:46 <nicktr_redux> +0
16:46:47 <Andrew> +1
16:47:10 <AdrianHB> +1
16:47:14 <jnormore> +1
16:47:27 <adrianba> +1
16:47:35 <ShaneM> +1 to absuri
16:47:41 <rouslan> +0
16:47:52 <dlongley> +1
16:48:13 <Ian> RESOLVED: Payment Method Identifiers will be absolute URLs
16:48:28 <Ian> (And we'll continue to look at other topics like grouping)
16:48:36 <Ian> Topic: Requesting user data (not just shipping address and options)
16:49:07 <Ian> AdrianHB recaps:
16:49:08 <Ian> ]]
16:49:09 <Ian> [[
16:49:10 <Ian>     PR 174 - Adding support for phone and email
16:49:10 <Ian>     PR 65 - Change the way we request user data (PR withdrawn? - @zkoch)
16:49:10 <Ian>     Issue 1 - Requesting email and phone number
16:49:10 <Ian>     Issue 27 - Should API support billing address capture (for tax computation)?
16:49:12 <Ian> ]]]
16:49:20 <zkoch> I’m happy with Adrianba’s proposal, so happy to drop mine in support of his
16:49:51 <Ian> adrianba: My goal here is to address the narrow idea of phone and email that we discussed at the FTF meeting
16:49:53 <zkoch> My original: https://github.com/w3c/browser-payment-api/pull/65
16:50:04 <zkoch> Adrianba’s counter: https://github.com/w3c/browser-payment-api/pull/174
16:50:25 <Ian> ...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]
16:50:37 <nicktr_redux> zakim, open the queue
16:50:37 <Zakim> ok, nicktr_redux, the speaker queue is open
16:50:57 <Ian> ...my proposal adds flag to collect payer's email address, flag to capture payer phone, flag to capture shipping address phone
16:51:27 <Ian> ...we could have an additional flag to only collect phone(s) when necessary
16:51:41 <Ian> ..I feel like we should start with the simpler proposal and get experience
16:51:56 <adrianba> q+ to talk to issue 27
16:51:57 <Ian> adrianhb: Related issues: #1, #27 (billing address) for tax computation
16:52:29 <Ian> q?
16:52:30 <nicktr_redux> q?
16:52:31 <Ian> q-
16:52:35 <AdrianHB> q-
16:52:36 <manu> q+ 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 payment request API.
16:52:39 <MattS> q+
16:53:05 <Ian> adrianba: Regarding address for tax computation (e.g., Europe)
16:53:10 <Ian> ...I have a proposal for that that I haven't yet written up
16:53:19 <Ian> ..it would cause merge conflicts with pending merges
16:53:28 <Ian> ..once we have done the merge, I will submit a request
16:53:34 <nicktr_redux> ack manu
16:53:34 <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
16:53:37 <Zakim> ... payment request API.
16:53:47 <Ian> manu: I don't want to block progress, but am concerned about collecting customer information
16:53:53 <Ian> ...we are adding more data
16:54:04 <Ian> ...I know that supporters of these proposals want to limit it heavily
16:54:10 <Ian> ...but the list keeps growing
16:54:12 <zkoch> q+ to talk about why
16:54:32 <adrianba> q-
16:54:39 <Ian> manu: I am +1 to adding phone and email, but the more we add the more complex the API
16:54:40 <adamR> q+
16:54:49 <AdrianHB> q+ to talk about counter-proposals
16:54:57 <Ian> ..if we want to address shopping cart abandonment, we should update our charter to address information gathering in a more generalized way
16:55:25 <Ian> ..this is because we are conflating payment request with gathering customer information
16:55:29 <Ian> ...if we do these things, we need defaults
16:55:33 <Ian> zakim, close the queue
16:55:33 <Zakim> ok, Ian, the speaker queue is closed
16:55:34 <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.
16:55:44 <Ian> ack matts
16:56:10 <Ian> matts: Here is why I think this is a bad idea at this stage...email and phone number are linked to specific payment methods
16:56:19 <Ian> ...if I understand this is for mediator capture, right?
16:56:33 <Ian> ...problem is that when we start adding new methods like union pay or paypal
16:56:45 <Ian> ...we are going to get overlapping credentials / pieces of data
16:56:58 <Ian> ..I don't think the the options are the right way, but rather the payment method data
16:57:12 <Ian> ..I think #138 talks about semantics of capturing payment method data
16:57:27 <Ian> ..I suggest we tackle that before we add GLOBAL pieces of data outside of the payment  app
16:57:45 <Ian> zkoch: We want to get the minimal information to get through a checkout flow.
16:57:46 <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.
16:57:59 <Ian> ...I think its's about being pragmatic
16:58:03 <Ian> q?
16:58:03 <nicktr_redux> q?
16:58:06 <Ian> ack z
16:58:06 <Zakim> zkoch, you wanted to talk about why
16:58:08 <Ian> ack ad
16:58:08 <Zakim> AdrianHB, you wanted to talk about counter-proposals
16:58:11 <manu> q+ to say "What is needed to complete the checkout flow?" is the right question to ask, we're debating how to do that in a seamless, well-designed way.
16:58:27 <Ian> adamR: I don't have a strong opinion on adding fields. But every field we add needs to be auto-fillable
16:58:42 <Ian> ...I think free-form proposals are to be avoided
16:58:42 <nicktr_redux> q?
16:58:52 <Ian> ...and things like coupon codes that are transaction specific don't belong here
16:59:25 <Ian> nicktr_redux: Who supports PR #174?
16:59:26 <zkoch> +1
16:59:27 <adrianba> +1
16:59:27 <MattS> -1
16:59:30 <rouslan> +1
16:59:31 <manu> +1
16:59:44 <adamR> +0
16:59:46 <AdrianHB> +0
16:59:49 <dlongley> +0
16:59:51 <ShaneM> +0
16:59:56 <Ian> +1 but I'd like to also address Matt's concern (which I've also raised as an issue)
17:00:00 <brian_> +0
17:00:01 <Mike5> +q
17:00:03 <Mike5> +1
17:00:37 <Mike5> s/+q//
17:01:01 <Ian> IJ: Two ideas for moving forward (1) decide over objection (2) ask Matts and Zach to work on it
17:01:09 <Ian> Nick: +1 to Ian's suggestion #2
17:01:33 <Ian> zakim, open the queue
17:01:33 <Zakim> ok, Ian, the speaker queue is open
17:01:34 <nicktr_redux> I think it's matts and adrianba
17:01:36 <dlongley> bad user experience when you have redundancy.
17:01:36 <Ian> q+
17:01:44 <adamR> q-
17:02:00 <Ian> 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
17:02:25 <Ian> adrianhb: When we accept this proposal we are accepting two things:
17:02:27 <Ian>  - the functionality
17:02:31 <Ian> - the way the functionality is being defined
17:02:42 <Ian> adrianhb: I am hearing consensus on "the functionality" here and not yet consensus on how
17:02:45 <manu> +1 to the functionality, -1 to the way the feature is exposed.
17:03:00 <manu> it's not a solid design, feels hacked together to achieve a very specific purpose.
17:03:02 <Ian> adrianhb: So I'd like to see counter-proposal on how to achieve Zach's stated objective
17:03:08 <dlongley> +1 to functionality, -1 to how it's being done (but admittedly, i think it's really complex)
17:03:39 <Ian> Matts: I was wrong...not issue 138...it's another
17:03:40 <Ian> q?
17:03:57 <Ian> nick: So proposal not carried at this stage. Suggest MattS+Zach chat and come up with counterproposal
17:04:26 <Ian> https://github.com/w3c/webpayments/wiki/PaymentApp_Notes
17:04:35 <Ian> https://github.com/w3c/webpayments/wiki/PaymentApp_Notes#data-collection
17:05:20 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/05-wpwg-minutes.html Ian
17:05:21 <nicktr_redux> thank you everyone
17:05:26 <dlongley> if we're collecting data from the browser in different places, that seems to indicate we should have a separate API for it
17:05:40 <Ian> topic: Next meeting
17:05:40 <MattS> It is issue 143 that covers semantics
17:05:43 <Ian> 12 May
17:05:49 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/05-wpwg-minutes.html Ian
17:05:56 <Ryladog> Present+ Katie Haritos-Shea
17:07:18 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/05-wpwg-minutes.html Ian
17:10:47 <zkoch> zkoch has joined #wpwg
17:59:53 <zkoch> zkoch has joined #wpwg
18:13:08 <zkoch> zkoch has joined #wpwg
18:15:08 <yaso> yaso has joined #wpwg
18:20:55 <zkoch> zkoch has joined #wpwg
18:32:56 <zkoch> zkoch has joined #wpwg
19:09:28 <Zakim> Zakim has left #wpwg
19:19:17 <zkoch> zkoch has joined #wpwg
19:25:12 <zkoch> zkoch has joined #wpwg
20:03:21 <zkoch> zkoch has joined #wpwg
20:44:34 <adamR_> adamR_ has joined #wpwg