Web Payments Working Group Teleconference

<dwim_> Hi, manu, I'm Dongwoo Joshua Im, from Samsung

<nick_tr> Welcome, Dongwoo

<dwim_> nick_tr: thanks.

<scribe> scribe: Ian

<nick_tr> https://github.com/w3c/webpayments/wiki/Agenda-20160317

Regarding Call fo Consensus to FPWD

nick_tr: Today is the day we said we would issue the CFC
... but there has been discussion about the nature of FPWD
... Ian, would you be willing to describe the purpose of FPWD?

https://www.w3.org/2016/03/15-wpwg-blog.txt

IJ: FPWD is a signal we will be looking for review on this early work

<AdrianHB> is trying to track on IRC

IJ: blog post is a piece of framing that story

doug: In addition, we may want to do something like a report to people (e.g., a PDF) to help frame the status
... so that people understand the context in which we are publishing the documents.

nick_tr: I wanted the staff contacts to give perspective because, speaking as someone new to w3c but longtime in financial services, I think it would be unusual to publish a draft specification in this state of maturity.
... that's caused some angst in my own organization.
... it would be good to hear from others as well.
... I get a strong impression that people who come from regulatory specifications or card scheme specs, which only break cover into public status at a good degree of maturity, that there is a gap between our expectation of how mature it should be, and its current state.

MattS: Question - this group is a public group...anyone can review, etc.
... how does it get out to people ?
... what communication are we expecting to do?
... how will we handle it?
... we seem to be opening more issues than closing them.
... how will we marshall the feedback?

<manu> Ian: We have multiple ways to do outreach - email newsletters, social web, etc.

<manu> Ian: We've been asked not to do broad outreach by WG.

<manu> Ian: We will most likely have a webinar for folks like MAG - open to other suggestions for getting word out in a scalable fashion - talking to associations seems like a good idea. Debit network alliance. ETA, NRF, etc.

<manu> Ian: I welcome all help in doing that.

<manu> Ian: How do we handle feedback? It is true that W3C process includes accountability requirements that we be responsive to feedback - Chairs play role in that so it doesn't become a DoS attack - pointing to issues that have been raised/closed. There is some chair training to do.

<manu> Ian: We have set the expectation that we are expecting to publish before we publish these issues. We spend time resolving issues to mature spec, we don't want to do that, we publish updates along the way. (Much of this happens in parallel)

<manu> Ian: The mechanics of handling input - mailing list, github PRs, not /everyone/ can contribute due to IPR restrictions, but everyone can comment (including the general public).

<manu> MattS: Good coverage, thanks - my impression - anyone can raise issue on public github repo - they can't do PRs unless they pass IPR, but anyone can raise an issue?

<manu> NickTR: Yes, that's the case but also can be done via public mailing list.

Q. Can anyone raise an issue?

A. Yes

Q. Can anyone raise an issue via email?

A. Yes

Q. Can anyone raise an issue on GitHub

A. Ian doesn't know mechanically, but in theory yes

<manu> as long as they have a Github account, I think the answer is "Yes", Ian.

<Zakim> ShaneM, you wanted to ask nick_tr about concerns

[Thanks Manu]

<manu> shepazu: Anyone can publicly comment on the spec.

ShaneM: Nick, you raised some concerns about the immaturity of the document
... and the perception by some...my folllow-up question is: would that level of maturity cause people to look at it askance?

nick_tr: Great question...the question is "yes"..I think that is direct cause for concern.
... there was some conversation at the SFO meeting on this
... my concern is definitely that, because many of the people we will reach out to review to (or others who become aware) may look at it and see a lot of questions
... and say "this is not the kind of spec I expect to see"
... so gap in expectations between how w3c works and how financial services industry works

CyrilV: I understand what you said about concern about maturity of document
... but sometimes we have to wait a lot longer to get a mature document.
... I want to clarify that the call for consensus does not assume that the issues are resolved.
... bpce can cope with the level of maturity.
... and could deal with publication as long as later we can say "we don't agree with the content"

<manu> Ian: The call for consensus is only about publishing a first public working draft, there are still issues open, people can object to technical content as document evolves. The document will state clearly that content hasn't been agreed to.

<shepazu> (Ian, you could emphasize this in your blog post… that we are still building consensus)

<manu> Ian: We are just asking to publish it w/ open issues.

nick_tr: I think I have come to the same conclusion that it's really important to communicate that the FPWD is an invitation for wider review, more discussion, and more issues potentially
... our charter sets expectation that there are many more months of work
... in response to a question from MattS....he observed that right now we are opening more issues than we are closing
... and as a group we have not spent a lot of time discussing a lot of the issues in detail.
... it can be challenging to stay on top of the issues list, but (as Chairs) that's our job
... as part of FPWD, then we will return to weekly (or bi-weekly depending on group's will) to really tackle specific issues

+1 to that

<dlongley> +1 for tackling issues on the call

scribe: the quid-pro-quo is that members in the WG help us resolve them (e.g., by people writing concrete proposals to discuss)

rouslan: I think that publishing a WD is a good way to invite feedback from the broader audience, and even to start testing early implementations
... the early review is good to reveal blind spots

<manu> +1 to what Rouslan is saying.

<dlongley> +1 as well

rouslan: if we think that the industry will be put off by the "rare" state of the specs, I think we can alleviate issues through clear status comms

<zkoch> +1 from me as well

rouslan: I think we need to keep up momentum, but thoughtfully.

<Zakim> Ian, you wanted to add that publication shows momentum

<manu> We may want to point out in the "Status of the Document" section - language specifically for regulators.

<manu> Ian: There is no bright line to what "good progress and work ethic" and what is "reckless". The fact that we have materials to look at is valuable - Samsung joined the WG last night - Facebook's participation in face-to-face is a good... all because they see the stuff is moving.

<manu> Ian: We are saying "We need you to pay attention and start moving" now - as comms person, would love to make sure we frame this properly, but this is ordinary stuff in W3C - this is normal.

<manu> Ian: We want to communicate the ordinary-ness of this situation to those that are not used to it.

<shepazu> (I wonder if we should link to examples of a FPWD that changed dramatically before becoming a Recommendation)

<Zakim> manu, you wanted to ask that we get around to talking about what we're going to publish before we run out of time.

<manu> Ian: I want to hear really concrete suggestions - how can we do that? How do we reveal blind spots, we can assuage some of this concerns.

manu: I think that the discussion so far has been good...as Ian pointed out, this is a regular thing that goes on at W3C...a specific comment is that in the status of the doc we call these things out ...we might want to address regulators and financial industry in the status industry.
... we might want to say something like "we are releasing these specs sooner than one might see in the financial services industry to get feedback"

<dlongley> maybe we can say: we've done work from our perspectives -- and now we want feedback from *your* perspectives, so we can incorporate it all and build something good

<shepazu> dlongley++

Which specs

nick_tr: Four candidates

<nick_tr> https://w3c.github.io/browser-payment-api/specs/paymentrequest.html

<nick_tr> https://w3c.github.io/browser-payment-api/specs/architecture.html

* Payment request API

* Archtiecture

<nick_tr> https://w3c.github.io/browser-payment-api/specs/method-identifiers.html

* Payment Method Identifiers

* Basic Card Specs

<nick_tr> https://w3c.github.io/browser-payment-api/specs/basic-card-payment.html

<Zakim> manu, you wanted to suggesting an order and not bunch them together. and to suggest we handle payment request API first - as I think everyone wants to publish that one - take them

Manu: I think we should take them 1 at a time.

<manu> +1 to what Nick said.

<manu> Ian: Our charter says we can do calls for consensus - people not on the call should participate in the decision - call for consensus will go out.

<manu> Ian: We shouldn't use the time to pre-determine which specs will be published or not - we should use the time to get a sense of where people are and what could be done over the next week for call for consensus to make it more likely we'll have more consensus to publish.

<manu> Ian: Here it might be more useful to hear from people what would make them most comfortable.

https://github.com/w3c/webpayments/wiki/Agenda-20160317

<manu> Ian: People will be asked to comment on each of the documents, chairs will gather the data.

<manu> Ian: What can we do to get to consensus to publish?

<Zakim> manu, you wanted to note that I don't want to put us in a situation where there are a bunch of -1s, when the editor's could have done something to prevent that.

<Zakim> rouslan, you wanted to indicate my support and concerns.

rouslan: I think Manu is right that payment request API should be published as FPWD

<manu> NickTR: I think Manu is concerned that we get to the end of the CfC and find a bunch of objections that we could have prevented.

rouslan: for basic card payment and PMIs, I think they help to bootstrap the ecosystem and work well with the API spec...so I would +1 those
... regarding architecture, I am more lukewarm...if people feel it's important, I'm ok as well

MattS: My view on the specs is that I'm pretty comfortable with them if the blog post is specific about what we want people to comment.
... I want we want to call out more vocally security and privacy
... it would be good if we could groom the issues list and list them in the post
... I would like to agree on our priorities by looking at the issues list
... as a group we've got 50 or so, and a good proportion are in security and privacy
... happy to work with IJ on revision
... one other thing regarding statements about flows...let's invite assistance

<manu> Ian: I'll give an example of the sort of thing that would be helpful to hear from people - everyone should come to the queue to say stuff like this

<manu> Ian: I think we should publish the four specs that led to changes, some changes were made, empty payment method spec to two proposals, one is URI-based one is not, I liked the state of that one - great branching point. For architecture, I integrated a bunch of what was in the wiki is in the spec, more comfortable with that, with wiki - keep it as spearate document", should not be part of API spec - basic card spec

<manu> Ian: We haven't talked to card companies yet - we should put a stake in the ground, I recognize there is a lot of work to do - resolve issues - we should publish all four of them.

CyrilV: My view is...if we publish 1 we should publish 4 since they are a system that go together
... it would be difficult to review them if treated independently.
... do we also publish the issues list?

nick_tr: Majority of the issues are now included in the text of the docs

CyrilV: Ok, fine for me

<Zakim> manu, you wanted to focus on one spec at a time, PaymentRequest API and what it would take to get it to FPWD.

Manu: I request that we publish payment request API as a FPWD, but only after that issues have been integrated.
... I would be -1 to publishing them unless it pulls in the pull requests.
... the rest of the docs I don't feel we have enough review on
... to meet the bare minimum of what the group agrees on
... e.g., the PMI spec just pulled in a pull request 12 hours ago that vastly changed the spec.
... I'm concerned that people haven't read the spec.
... we are saying "just publish it anyway"

<ShaneM> +1 - I didn't see that had happened

(That material was available already)

manu: Re architecture, discussions happening
... so I don't think we should publish that one...should be integrated into front matter of payment api spec
... regarding basic card ...it's only for legacy pull cards
... we've had no input from major card brands....I think we should ask them for feedback before we push it out there
... I would be fine for publishing the arch materials into the payment request API

shepazu: I am fine with publishing docs as they stand
... am sensitive to need for people to understand how they work together
... and see publishing all four as helpful

<manu> I'd like far more review on the "new" specs before we publish them; Architecture, Payment Method Identifiers, and Basic Card Payment.

<manu> +1 to shepazu - publish one, wait on the other three.

zkoch: I support publishing all the specs...for momentum and feedback
... for the payment request ... it's not clear to me that all the issues need to be in the spec
... we are starting to go through and comment on them
... I'm not sure all are merge-worthy at this point
... we have a concrete proposal in the spec
... we don't need an issue to say "there could be other ways"...we need concrete proposals.
... for PMI...the changes are two concrete proposals
... for basic card payments, we need a story to tell people how it will work, I see this as a way to motivate them to come to the table. They are aware of the specs
... they have seen them and have not commented yet, so this could be a useful signal to bring them into the conversation.

dlongley: If it's a good idea to put the proposals in the draft specs, it's good to have all the issue markers in the spec.
... the status of the document should be very clear that it's incomplete and we are asking for other perspectives
... regarding PMI, I didn't see the new text yet

<dlongley> https://github.com/w3c/browser-payment-api/issues/42#issuecomment-197540319

dlongley: I feel like if we have an arch document, it should have a wider scope.

(But that's not the purpose of this doc.)

dlongley: I think we are going to have more than one API that works with payment apps

<shepazu> +1

(IJ mentioned on that topic that the docs can continue to evolve)

dlongley: The arch doc can tie various pieces together

<manu> We shouldn't publish something that's going to be integrated into another document

dlongley: if we want an overview of how payment request API works that should be in that doc itself

<Zakim> manu, you wanted to note he said "pull requests that are issues" and to not that he'd rather reference as an Editor's Draft than FPWD. and to make sure we aren't being desperate

<zkoch> Yes, that’s what I was referring to as well

manu: To clarilfy a comment on Zach's comment...I want to ensure all issue markers
... minimum bar is to have issue markers
... before FPWD
... I am concerned about the "we need to show forward progress"
... if we are not making forward progress
... it is true we have made progress on the API if we have concerns registered
... I don't feel it's true for the other documents

<zkoch> I don’t think I’m in agreement that all of those issues as PRs need to be merged in. Some of them, yes, happy to. But others (e.g., 61, 73) don’t need to be

<dlongley> but we don't need agreement

manu: we are not actually demonstrating forward progress...we are doing the opposite..

<dlongley> there isn't agreement on the options in the payment method identifier spec

<dlongley> but we're putting those in there ... so let's do the same thing for the other issues.

<dlongley> and get feedback on everything.

manu: I have a strong feeling that some people who are saying let's publish all four have not done a thorough review...minimum bar is to read these specs.

IJ: We have invited feedback for weeks. People have been invited to review them for weeks.
... and the specs have changed during this time.

Manu: If people are not reviewing the docs, we need to find out why it's not happening.

<dlongley> notes that issues have been raised (as PRs) and they are not yet in the specs

(People can use the week to review during the call for consensus)

nick_tr: I am hearing mostly consensus for the API, and softer support for the other three.
... The formal CFC will list all 4 specs and people can comment on each one
... I urge Manu and Zach to work together to address the pull request question
... I'll send a formal mail later tonight my time

Next meeting

(NO MEETING 24 March)

Next meeting: 31 March

<MattS> Can we request specific feedback to the Blog too if this is the framing for the specs we release

<zkoch> SGTM, thanks!

(Yes, please send comments on blog post to me!)