See also: IRC log
AdrianHB: There has been quite a
bit of discussion on the list, lots of discussion to try and
get ourselves aligned a bit in terms of priorities.
... We have a bunch of influencing factors on priority -
lengthy discussion w/ chairs and staff and our proposal is to
focus as described in the agenda.
... we're very concious that there is a strong demand from the
group wrt. extensibility of the ecosystem - the ability to have
independent 3rd party payment apps as a part of the
ecosystem.
... How would that work in terms of UA interfacing w/ payment
apps. That's from a browser perspective, but there is
non-browser perspectives as well.
... With the browser specs doing experimental implementations,
we are going to prioritize this over next few weeks. Provide
guidance on that, we expect that to become priority.
... Next is moving browser API forward
<ShaneM> I am concerned that we end up with deployment that we feel we can't change as our work matures.
<zkoch> Just a quick clarification: The PRs are from us as individual participants, not in our capacity as editors
AdrianHB: The vendors would like
to start implement this API - how many parameters, where do
parameters fit, how do specific things work - we'll try to
address some of those things today. Issues on the list -
address those issues diretly.
... We're going to try to move that stuff to the mailing list
as possible.
... There is a proposal from the Web Payments CG around Core
Messaging and HTTP API - there is also payment methods - while
we would like those things to happen in parallel, the next few
weeks will drive what we spend time on.
... Focus very much on issue resolution
Nick: I don't have much to add. Adrian and I are trying hard to balance priorities of the group - appreciate everyone's contributions on helping stay focused - arch and extensibility, moving browser specs moving forward, open and excited on other proposals but would like to focus call time over next few weeks on 3 priorities.
AdrianHB: Various hats that people working in the group - contributors/editors/chairs - I'm certainly going to continue to contribute as a contributor - as a developer I'm intending to contribute. It should be accepted that contributions to PRs and issues are, unless stated otherwise, contributions from members of the group.
Nick: I'm fine w/ that position.
Nick: Unfortunately dates conflict w/ Blockchain... we've put other dates up
Wednesday 13th July and Thursday 14th July
Monday 18th July and Tuesday 19th July
Tuesday 19th July and Wednesday 20th July
<nick_tr> https://www.w3.org/2002/09/wbs/83744/F2F_London/
Nick: Please do fill in the questionnaire - we'll try to fill in the dates that are most helpful - want to see if people would like WPIG / ILP meeting at same time - any questions/comments on that?
ChristopherA: The IETF thing starts on the 17th, SUnday - if there was something that was 14th and 15th I'd go to London and fly out to berlin.
Nick: Logistically, I can't host on the 15ht, but Wed/Thu works.
AdrianHB: The IG would like to co-host if they can - we might be able to do IG - venues for that are different - Nick can only do Wed/Thu.
dezell: Yes, we're actively thinking about having the face-to-face WPIG meeting w/ you around there -
Nick: I can't host Friday,
AdrianHB: We might be able to host
Brian: I might be able to host on Friday.
dezell: Yes we care and yes we're thinking about a WPIG meeting.
Nick: The questionnaire is open, we'll give you an update at the next meeting.
Nick: Doubt we'll get through all of this today, but let's get started.
Subtopic: paymentrequest.complete()
AdrianHB: The intent was to pass
information via complete - originally we asked about passing
something to payment app - drop parameter all together?
... Push back on that to change parameter form boolean to enum
- AdrianB updated - happy to drop my proposal w/ Adrian's
counter-proposal.
<adrianba> https://github.com/w3c/browser-payment-api/pull/161
adrianba: A little bit more
discussion in https://github.com/w3c/browser-payment-api/pull/161
today
... I'm open to a question about whether we want to talk about
those proposals today or accept this PR or think about those
more.
<zkoch> I think there is another proposal to do complete({status: “success”});
<zkoch> +1 to accepting this as is, and then refining later with enums if we want
AdrianHB: We could accept PR as it is to accept new messaging as it is - additional PR to accept a newer proposal.
adrianba: happy to accept as-is and then refine it.
manu: Happy to accept as is and then do different PR.
dlongley: Yes, fine w/ that.
AdrianHB: proposal to accept PR 161 as is.
<zkoch> +1
<AdrianHB> +1
Nick: Any objections?
+1 to accept PR161` as=is
<adrianba> \o/
<dlongley> +1
RESOLUTION: Adopt PR #161 as is.
AdrianHB: I put forward PR 133 that has a bunch of stuff in it - trying to do too much in a single PR - as a relative newbie to this process - there is a proposal to address total amount / merging of parameters - PR #158 is a counter-proposal to part of that.
<adrianba> https://github.com/w3c/browser-payment-api/pull/158
AdrianHB: In the current spec, we
give special meaning to items in the final position in list.
The total should stand on its own.
... AdrianHB uses a PaymentItem object, whereas I used an array
of currency items. I was trying to support multiple currency
amounts. AdrianB's moved total out of items array, but keeps it
on same object. In my proposal, I've moved it onto separate
parameter - probably a good contrast of two proposals.
adrianba: I was trying to have discussion of multiple currency amounts and price and discuss those separately
AdrianHB: I'm happy to do that, if we address these things incrementally, we'll make more progress.
adrianba: Manu asked the question about why "label"
AdrianHB: It does make sense to
have some kind of label that we can have there. Rather than
comparing the two, let's consider adrianba's and like that
approach.
... There seem to be general consensus around it.
Manu: What happens if a UA doesn't display?
<Zakim> manu, you wanted to ask if that is a MUST be displayed... hard to do that.
<dlongley> maybe if the UA is going to display the list of items, they have to use all the labels
adrianba: Right now, it's a MAY show it.
Manu: My concern is that developers may be surprised if it's not displayed.
<dlongley> (or ... the UA may not pick and choose which labels to show)
Roy: Just wanted to say that I'm in favor of the PR - we may want to push other things like taxes.
AdrianHB: The proposal separates
the total from display items.
... The UA may display that stuff - there is no MUST there -
taxes, discounts, whatever other line items the merchant
considers important.
<ShaneM> Since we don't have UI in our scope, MAY is appropriate here
AdrianHB: Are you saying we should have specific tax amount in there...
Roy: It's interesting that you
say that display items don't have to be displayed.
... Going simply off of a string-based title on the items is
error prone.
adamR: I don't want to go too far afield - do you mean that we have some messages that are going to impact the payment request? Or is this just for display purposes right now?
AdrianHB: Purely for display
right now.
... Display items are for the UA to use in displaying the UA -
pass request onto payment app.
Roy: I think it's important to call out to the user what's going on - you need display items for that purpose - but there are other item types, inclusive vs. exclusive taxes - important line items, but affect total in different ways - we may want to call other items out.
AdrianHB: We need to clarify that and submit a new PR to add additional items outside displayItems list. Right now what we have is a step in right direction.
Nick: That sounds like consensus
AdrianHB: Any objections to that PR?
<ShaneM> I think it could be interesting to extend displayItems with an optional 'type' parameter and a dictionary of semantically meaningful types (to address Roy's concern)
<zkoch> +1
<nick_tr> +1
PROPOSAL: Adopt PR158 as is.
<AdrianHB> +1
+1
<dlongley> +1
<zkoch> :)
<rouslan> +1
<Roy> +1
<ShaneM> +ian
RESOLUTION: Adopt PR #158 as is.
<dezell> +1
<zkoch> @adamR: Yep
Subtopic: Separation of payment parameters - PR #162
AdrianHB: Merge list of payment
methods with payment method data - major difference is total is
still details object - total and items list in details and then
supported methods parameter and custom data for those - 2nd
parameter which contains total and list of items - 3rd
parameter that has options like "requestShipping"
... The difference is that middle parameter - total w/
supported method stuff - display items w/ options - biggest
difference between the two.
... Since adrianba's is a step toward that - may submit another
PR to get rid of details object and debate that separately -
gist is to address a request w/ the TAG review and then issue
raised before proposal was brought into WG - whether PMI should
be passed as array of identifiers - or more complex
objects.
... Looking at the thread, most people are agreed that this
will work and it's a step in the right direction - any
objections?
adrianba: One quick comment - role of this change was to remove antipattern of having two optional arguments .
PROPOSAL: Adopt PR #162 as is.
<AdrianHB> +1
+1
<dlongley> +1
<zkoch> +1
<nick_tr> +1
RESOLUTION: Adopt PR #162 as is.
<dezell> +1
<zkoch> oop, q-
Subtopic: Change the way we request user data - PR #65
AdrianHB: This one is
contentious... it has to do w/ how we pull in user data.
... There have been multiple counter proposals - AdrianB - you
had an argument against getting too generic. Can you explain
why this is a bad idea?
<Zakim> zkoch, you wanted to say modifications are coming
zkoch: I don't think there is consensus around that PR - some good feedback - trying to make modification to it - probably not quite ready yet to be merged in yet. So, hoping we could punt it to the next call.
manu: Agree to punt to next call - no clear consensus yet.
AdrianHB: Let's talk about this PR, though.
adrianba: Agree w/ Zach - was
going to work w/ Zach on working on this PR - didn't anticipate
that we'd make fast progress on previous 3 issues.
... Counter proposal is to add request to options dictionary,
specifically for email and phone number, but I don't like
Zach's original proposal because it assumes that these are
always boolean requests, merges them into a list.
... I think we should esign the API so we could protentially
have things be required or optional
... we've had discussions - feasible around UI - is it
something we need now? plan was to propose that we keep it
simple to begin with - we have booleans in the same way we have
requestShipping, requestEmail, requestPhone and show how that
could be etensible and decide if we want to add required vs.
optional.
AdrianHB: I get the sense that
folks haven't followed this thread closely. From my
perspective, what we have is effectively this spectrum of
flexibility on one side where websites can ask UA to gather
anything for them, what is gathered through UA - what it is
they can ask for it.
... The other end of the spectrum is something fairly
rigid.
... I'd prefer something flexible
<Zakim> manu, you wanted to ask that we design something generic/extensible - because that's where we're going.
<dlongley> manu: My concern is that we shoot for something fairly narrow and rigid and over time we're going to keep expanding the types of information that orgs will want from the UA and we'll end up in a position where this is a general customer data collection API.
<dlongley> manu: My preference is that we make it generic and generalized which is what AdrianHB is proposing because we'll end up in a situation where we have 10-15 things that we support over the last 5 years. To be clear, I wish this wasn't happening in the payment API and instead in another one, but I think we're setting ourselves up to collect email and coupon, and so on and so forth.
zkoch: I don't like generic - I
think that part of what we're doing here is an opinionated
streamlined flow. I don't think we're trying to recreate the
entire buy form experience.
... We can only accommodate a certain set of use cases - if we
have 15 different things you can request - we need to stop and
reflect. The bar is limited to information you absolutely have
to have for checkout flow... email and phone may be the
bar.
<nick_tr> q
zkoch: We want to avoid massive expansion.
AdrianHB: If there are no other comments, we can move onto other issues.
<zkoch> We already have generic, it’s called a <form> :)
AdrianHB: If you want to submit
an alternative proposal - please do.
... We need to understand why not to do generic. We went
through this on shipping address - made checkout experience
better, if anything else makes checkout experience more
efficient, we need to consider it. We need to think about
privacy - how easy is it to farm user data?
... What about other countries required stuff - like
country-specific shipping information?
... Maybe we should dive into one or two of the other issues
that impact the shape of the API - stimulate proposals to come
forward.
AdrianHB: There are four other issues that we may want to talk about - happy to do them in that order or one in particular that anyone wants to discuss.
<Zakim> manu, you wanted to ask about how this will be deployed and how that affects how much handwringing may be done.
<dlongley> manu: There's been talking about this API and implementing it in the browser, is the expectation that when this gets published (soon), will it be behind a flag?
<dlongley> manu: If collecting this information is behind a flag at first as an experiment, then I think people in the WG are much more likely to get behind it. Because if tons of people start using it then we have to keep it around.
<ShaneM> +1 to a general concern about exposing experimental features to the public
<dlongley> manu: Do you guys know how you'll do this first round of implementation, will it be behind a flag?
zkoch: We have two conflicting ideology - we want to get features out to get feedback, but we don't want to launch something that's unfinished. We have a couple of different things that we're looking to do.
<dlongley> +1 to behind a flag
zkoch: You will probably see this behind a flag at first - problem with that is that it's difficult for a developer to use - what's the impact of this on conversion - so all users should enable flag. So another thing we're looking at as well that should solve this problem - how we can solve this problem from a Chrome perspective - origin trials - send out more details - way to launch experimental features, but expire them w/ use of tokens - there is a way for us
to turn this stuff off
zkoch: If we had an experimental thing, we can always put stuff behind another flag. Don't want to lock ourselves into an API that we're unhappy with, we will work hard to avoid that.
adrianba: To echo what Zach said, we will implement this first behind a flag for the payments api - in Edge - not ready for people to experiment w/ people outside our team now. With every new feature, we have to figure out balance between stability of parts of spec and whether it's ready for people to use / experiment with - we'll definitely start behind a flag.
<zkoch> I have to run to make another meeting, but happy to chat on this topic further if there are more questions
<zkoch> Thanks, all!
adrianba: One of the things we're
going to look at wrt. changes in the API - if there is
something where we see a potential change or something that we
might implement incrementally, if you have this whole
capability - lots of different aspects to it, we may only have
resources to implement one of those things... how could web
developer check to see if one capability exists, but others
don't.
... That's a core part of our philosophy for all APIs, want to
focus on that - we don't want to lock the group to feel
something is being decided w/o them.
... or break core API spec.
adamR: I don't have a position from a Mozilla perspective yet.
AdrianHB: I think that's a good perspective - I think that answered Manu's question.
<dlongley> manu: Yes, thanks
Nick: I think we made good progress this week on browser API - would like to focus on extensibility next week - please read proposals.
<nicktr> https://github.com/w3c/webpayments/tree/gh-pages/proposals
AdrianHB: The key ones we will
focus on next week are Core Messages, HTTP API, and Payment
Apps.
... It may be just parts of it that we propose are
browser-specific as opposed to generic payment apps thing -
don't only read them, but comment on them - if you don't like
them, submit a counter-proposal.
... I would love to see counter-proposals w/ differnt
approaches to what's been put forward to date - There are 4
issues that are left not specific to particular PRs. Those
issues impact the shape of the API some more than others.
... At least 3 of them were picked up during the TAG review -
look at them, propose solutions to them, and close them out as
soon as possible.
... we dont' want shape of API to change down the line. If
impleemnters are happy and this is feasible, the sooner we get
ther the beter.
... If people aren't happy w/ priority or labels - change them
yourself or let me know.
<nicktr> please look at issues #2, #16, #19, 119
AdrianHB: Let me know what you
think the priorities should be.
... I used a milestone for this week and will create milestones
for next weeks calls. I would like if we have proposals to
address these issues or any that affect the API.
Nick: Read those proposals before
next week or comment on them. The more comments there are, the
easier the discussion goes. I hope that by picking up some of
the other proposals next week, we'll make the group more
broadly inclusive.
... Speak with everyone next week.