Re: Update on Web Payments Working Group

On 31 March 2016 at 03:40, Manu Sporny <msporny@digitalbazaar.com> wrote:

> Hi all,
>
> Apologies for the lack of communication as of late. Many of us are
> heads-down in the Web Payments Working Group in an attempt to get the
> First Public Working Draft documents out.
>
> Things are not going well for the Web Payments Community Group
> specifications. I've written up a blog post about what is going well and
> what isn't here:
>
> http://manu.sporny.org/2016/browser-api-incubation-antipattern/
>
> The full-text of the article is included below for those that want to
> respond inline. Sorry for the length of the post - there is a lot going
> on that we're trying to report back to the group.
>
> ---------------------------------------------------------------------
>
> The Web Browser API Incubation Anti-Pattern
>
>    This blog post is about a number of hard lessons learned at the
>    World Wide Web Consortium (W3C) while building new features
>    for the Web with browser vendors and how political and frustrating
>    the process can be.
>
>    The W3C Web Payments Community Group (a 220 person
>    pre-standardization effort around payments on the Web) has been in
>    operation now for a bit more than four years. This effort was
>    instrumental in starting conversations around the payments
>    initiative at W3C and has, over the years, incubated many ideas
>    and pre-standards specifications around Web Payments.
>
>    When the Web Payments Working Group (a different, official
>    standardization group at W3C) was formed, a decision was made to
>    incubate specifications from two Community Groups and then merge
>    them before the Web Payments Browser API First Public Working
>    Draft was released in April 2016.
>
>    The first community group was composed of roughly 220 people from
>    the general public (the Web Payments Community Group). The second
>    community group was composed of a handful of employees from
>    browser vendor companies (fewer than 7 active). When it came time
>    to merge these two specifications, the browser vendors dug in
>    their heels making no compromises and the Web Payments Community
>    Group had no choice but to sacrifice their own specifications in
>    the hope of making progress based on the Microsoft/Google
>    specifications.
>
>    It is currently unclear how much the Web Payments Community Group
>    or the Web Payments Working Group will be able to sway the browser
>    vendors on the Web Payments Browser API specification. I do
>    believe that there is still room for the Web Payments Community
>    Group to influence the work, but we face a grueling uphill slog.
>
>    The rest of this post analyzes a particular W3C standards
>    development anti-pattern that we discovered over the last few
>    years and attempts to advise future groups at W3C so that they may
>    avoid the trap in which we became ensnared.
>
> A Brief History of Web Payments in and Around W3C
>
>    Full disclosure: I'm one of the founders and chairman of several
>    W3C Community Groups (JSON-LD, Permanent Identifiers, Credentials,
>    and Web Payments). A great deal of my company's time, effort, and
>    money (to the tune of hundreds of thousands of dollars) has gone
>    into these groups in an effort to help them create the next
>    generation Web. I am biased, so take this post with a grain of
>    salt. That said, my bias is a well-informed one.
>
>    For a while now, the W3C Community Group process seemed to be
>    working as designed. It took a great deal of effort to get a new
>    activity started at W3C, but a small group of very motivated
>    "outsiders" were able to kick-start the most supported initiative
>    in W3C history. This is what went right:
>
>      * 2010 May - The PaySwarm open payments community launches
>        outside of the W3C with a handful of people, a few
>        specifications, and the goal of standardizing payments, offers
>        of sale, digital receipts, and automated digital contracts on
>        the Web.
>      * 2012 May - W3C staff contact, Doug Schepers, convinces a small
>        handful of us create the Web Payments Community Group at W3C
>        and bring the work into W3C. In parallel, a W3C Headlights
>        process identifies payments as an area to keep an eye on.
>      * 2012 - 2014 - Web Payments Community Group expands to 100
>        people with several experimental specifications under active
>        development. Web Payments Community Group members engage the
>        United Nation's Internet Governance Forum, banking/finance
>        industry, and technology industry to gather large organization
>        support.
>      * 2013 October - W3C TPAC in Shenzen, China - W3C Management is
>        convinced by the Web Payments Community Group and W3C staff
>        contact Dave Raggett to hold a workshop for Web Payments.
>      * 2014 March - W3C Workshop for Web Payments is held in Paris,
>        France. The result is a proposal to start official work at the
>        W3C.
>      * 2014 October - First official Web Payments Activity, the Web
>        Payments Interest Group, is launched to create a vision and
>        strategy for Web Payments. It does so, along with the creation
>        of a Web Payments Working Group charter. A great deal of the
>        Web Payment Community Group's input is taken into account.
>      * 2015 September - Second official Web Payments activity, the
>        Web Payments Working Group, is launched to execute on the Web
>        Payments Interest Group's vision.
>
>    So far, so good. While it took twice as long to start a Working
>    Group as we had hoped, we had far greater support going in than we
>    imagined when we embarked on our journey in 2010. The Web Payments
>    Interest Group was being receptive to input from the Web Payments
>    Community Group. The Working Group was launched and that's when
>    the first set of issues between the Web Payments Community Group,
>    Web Payments Interest Group, and the Web Payments Working Group
>    started.
>
>    The Web Browser API Incubation Anti-Pattern
>
>      * 2015 October - A decision is made to incubate the Web Payments
>        Working Group input specifications in separate Community
>        Groups.
>
>    When W3C Working Groups are created, they are expected to produce
>    technical specifications that expand the capabilities of the Web.
>    Often input is taken from Community Group documents, existing
>    specifications and technology created by corporate organizations,
>    research organizations, and workshops. This input is then merged
>    into one or more Working Group specifications under the control of
>    the Working Group.
>
>    That is how it is supposed to work, anyway. In reality, there are
>    many shenanigans that are employed by some of the largest
>    organizations at W3C that get in the way of how things are
>    supposed to work.
>
>    Here is one such story:
>
>    The Web Payments Community Group has a body of specification work
>    going back 4+ years. When the Web Payments Working Group started,
>    Microsoft and Google did not have a Web Payments specification,
>    and thus put something together in a couple of weeks and incubated
>    it at the Web Incubator Community Group. In an attempt to "play on
>    the same field", some of the editors of the Web Payments Community
>    Group specifications moved that community's specifications to the
>    Web Incubator Community Group and incubated them there as well.
>
>    The explanation that the Microsoft and Google representatives used
>    was that they were just figuring this stuff out and wanted a bit
>    of time to incubate their ideas before merging them into the Web
>    Payments Working Group. At the time I remember it sounding like a
>    reasonable plan and was curious about the Web Incubator Community
>    Group process; it couldn't hurt to incubate the Web Payments
>    Community Group specifications alongside the Microsoft/Google
>    specification. I did raise the point that I thought we should
>    merge as quickly as possible and the idea that we'd have
>    "competing specifications" where one winner would be picked at the
>    end was a very undesirable potential outcome.
>
>    The W3C staff contacts, chairs, and Microsoft/Google assured the
>    group that we wouldn't be picking a winner and would merge the
>    best ideas from each set of specifications in time. I think
>    everyone truly believed that would happen at the time.
>
>    Until...
>
>      * 2016 February - The months old Microsoft/Google specification
>        is picked as the winner over the years old work that went into
>        the Web Payments Community Group specification. Zero features
>        from the Web Payments Community Group specification are merged
>        with a suggestion to perform pull requests if the Web Payments
>        Community Group would like modifications made to the
>        Microsoft/Google specification.
>
> Four Months of Warning Signs
>
>    The thing the Web Payments Working Group did not want to happen,
>    the selection of one specification with absolutely zero content
>    being merged in from the other specification, ended up happening.
>    Let's rewind a bit and analyze how this happened.
>
>      * 2015 October - The Web Payments Working Group has its first
>        face-to-face meeting at W3C TPAC in Sapporo, Japan.
>
> Warning Sign #1: Lack of Good-Faith Review
>
>    At the start of the Working Group, two sets of specification
>    editors agreed to put together proposals for the Web Payments
>    Working Group. The first set of specification editors consisted of
>    members of the Web Payments Community Group. The second set of
>    specification editors consisted of employees from Microsoft and
>    Google. A mutual agreement was made for both sets of specification
>    editors to review each other's specifications and raise issues on
>    them in the hope of eventually hitting a point where a merge was
>    the logical next step.
>
>    The Web Payments Community Group`s editors raised 24+ issues on
>    the Microsoft/Google proposal and compared/contrasted the
>    specifications in order to highlight the differences between both
>    specifications. This took an enormous amount of effort and the
>    work continued for weeks. The Microsoft/Google editors raised zero
>    issues on the counter-proposals. To this day, it's unclear if they
>    actually read through the counter proposals in depth. No issues
>    were raised at all by the Microsoft/Google editors on the Web
>    Payments Community Group's specifications.
>
> Warning Sign #2: Same Problem, Two Factions
>
>    When the Web Payments Working Group agreed to work on their first
>    specification, noting that there were going to be at least two
>    proposals, the idea was raised by the Microsoft/Google
>    representatives that they wanted to work on their specification in
>    the Web Incubator Community Group. Even though the Web Payments
>    Community Group editors chose to incubate their community's
>    specifications in the Web Incubator Community Group, the
>    inevitable structure of that work forced the editor's to split
>    into two factions to make rapid progress on each set of
>    specifications. This lead to a breakdown in the lines of
>    communication between the editors with Microsoft and Google
>    collaborating closely on their specification and the Web Payments
>    Community Group editors focusing on trying to keep their
>    specifications in sync with the Microsoft/Google specification
>    without significant engagement from the Microsoft/Google editors.
>
>    The inevitably led to closed discussion, misunderstanding motives,
>    backchannel discussions, and a variety of other things that are
>    harmful to the standardization process. In hindsight, this was
>    trouble waiting to happen. This sort of system pits the editors
>    and the group against itself and the most likely outcome is a Web
>    Payments Community Group vs. Microsoft/Google gambit. Systems
>    often force a particular outcome and this system forces harmful
>    competition and a winner take all outcome.
>
> Warning Sign #3: One-Sided Compromise
>
>    A few weeks before the Web Payments Working Group face-to-face
>    meeting, the editors of the Web Payments Community Group
>    specifications discovered (through a backchannel discussion) that
>    "the browser vendors are never going to adopt JSON-LD and the Web
>    Payments Community Group specification will never gain traction as
>    a result". The Web Payments Community Group specifications used
>    JSON-LD to meet the extensibility needs of Web Payments. This
>    desire to not use JSON-LD by the browser vendors was never
>    communicated through any public channel nor was it directly
>    communicated by the browser vendors privately. This is
>    particularly bad form in an open standardization initiative as it
>    leaves the editors to guess at what sort of proposal would be
>    attractive to the browser vendors.
>
>    Once again, the Web Payments Community Group editors (in an
>    attempt to propose a workable specification to the browser
>    vendors) reworked the Web Payments Community Group specifications
>    to compromise and remove JSON-LD as the message extensibility
>    mechanism, ensuring it was purely optional and that no browser
>    would have to implement any part of it. We did this not because we
>    thought it was the best solution for the Web, but in an effort to
>    gain some traction with the browser vendors. This modification was
>    met with no substantive response from the browser vendors.
>
> Warning Sign #4: Limited Browser Vendor Cycles
>
>    Two weeks before the Web Payments Working Group face-to-face
>    meeting, the Web Payments Community Group editors personally
>    reached out to the Microsoft/Google editors to see why more
>    collaboration wasn't taking place. Both editors from
>    Microsoft/Google noted that they were just trying to come up to
>    speed, incubate their specifications, and make sure their proposal
>    was solid before the face-to-face meeting. It became clear that
>    they too could be stressed for time and did not have the bandwidth
>    to review or participate in the counter-proposal discussions.
>
>    The Web Payments Community Group specification editors, in a
>    further attempt to compromise, forked the Microsoft/Google
>    specification for the purposes of demonstrating how some aspects
>    of the Web Payments Community Group design could be achieved with
>    the browser vendor's specification and prepared a presentation to
>    outline four compromises that could be made to get to a merged
>    specification. The proposal received no substantive response or
>    questions from the browser vendors.
>
> Warning Sign #5: Insufficient Notice
>
>    Google put forward a registration proposal 12 hours before the Web
>    Payments face-to-face meeting and announced it as a proposal
>    during the face-to-face. This has happened again recently with the
>    Microsoft/Google proposed Web Payments Method Identifiers
>    specification. Instead of adding an issue marker to the
>    specification to add features, like was being done for other pull
>    requests, the editors unilaterally decided to merge one particular
>    pull request that took the specification from three paragraphs to
>    many pages overnight. This happened while discussion was still
>    happening and also the day before a discussion about taking that
>    specification to First Public Working Draft.
>
>    Clearly, less than 24 hours isn't enough time to do a proper
>    review before making a decision and if the Web Payments Community
>    Group editors had attempted to do something of that nature it
>    would have been heavily frowned upon.
>
> Things Finally Fall Apart
>
>      * 2016 February - The Web Payments Working Group Face-to-Face
>        Meeting in San Francisco
>
>    The Web Payments Community Group specification editors went into
>    the meeting believing that there would be a number of hard
>    compromises made during the meeting, but a single merged
>    specification would come out as a result of the process. There
>    were presentations by Microsoft/Google and by the Web Payments
>    Community Group before the decision making process of what to
>    merge started.
>
>    For most of the afternoon, discussion went back and forth with the
>    browser vendors vaguely pushing back on suggestions made by the
>    Web Payments Community Group specifications. Most of the arguments
>    were kept high-level instead of engaging directly with
>    specification text. Many of the newer Web Payments Working Group
>    participants were either unprepared for the discussion or did not
>    know how to engage in the discussion.
>
>    Further, solid research data seemed to have no effect on the
>    position of the browser vendors. When research data covering
>    multiple large studies on shopping cart abandonment was presented
>    to demonstrate how the Microsoft/Google solution could actually
>    make things like shopping cart abandonment worse, the response was
>    that "the data doesn't apply to us, because we (the browser
>    vendors) haven't tried to solve this particular problem".
>
>    After several hours of frustrating discussion, one of the Chairs
>    posed an interesting thought experiment. He asked that if the
>    group flipped a coin and picked a specification, if there were any
>    Web Payments Working Group members that couldn't live with the
>    outcome. The lead editor of the Microsoft/Google specification
>    said he couldn't because he couldn't understand the Web Payments
>    Community Group's proposals. Keep in mind that one of these
>    proposals was a fork of the Microsoft/Google proposal with roughly
>    four design changes.
>
>    At that point, it became clear to me that all of our attempts to
>    engage the browser vendors had been entirely unsuccessful. In the
>    best case, they didn't have the time to review our specifications
>    in detail and thus didn't have a position on them other than they
>    wanted to use what was familiar, which was their proposal. Even if
>    it was purely an issue of time, they made no effort to indicate
>    they saw value in reviewing our specifications. In the worst case,
>    they wanted to ensure that they had control over the specification
>    and the Community Group's technical design didn't matter as much
>    as them being put in charge of the specifications. The Working
>    Group was scheduled to release a First Public Working Draft of the
>    Web Payments Browser API a few weeks after the meeting, so there
>    was a strong time pressure for the group to make a decision.
>
>    In the end, there were only two outcomes that I could see. The
>    first was a weeks-to-months-long protracted fight which had a very
>    high chance of dividing the group further and greatly reducing the
>    momentum we had built. The second was to kill the Web Payments
>    Community Group specifications, give the browser vendors what they
>    wanted (control), and attempt to modify what we saw as the worst
>    parts of the Microsoft/Google proposals to something workable to
>    organizations that aren't the browser vendors.
>
> The Key Things That Went Wrong
>
>    After having some time to reflect on what happened during the
>    meeting, here are the most prominent things that went wrong along
>    the way:
>
>      * Prior to the start of the Working Group, we tried, multiple
>        times, to get the browser vendors involved in the Web Payments
>        Community Group. Every attempt failed due to their concerns
>        over Intellectual Property and patents. Only the creation of
>        the Working Group was able to bring about significant browser
>        vendor involvement.
>      * The Microsoft/Google specification editors were not engaged in
>        the Web Payments Interest Group and thus had very little
>        context on the problems that we are trying to solve. This
>        group discusses the future of payments on the Web at a much
>        higher-level and provides the context for creating Working
>        Groups to address particular problems. Without that context,
>        the overarching goals may be lost.
>      * The Microsoft/Google specification editors were not engaged
>        with the Community Group specifications. It was a mistake to
>        never require them to at least review the Community Group
>        specifications and raise issues on them. They were asked to
>        review them and they agreed to, but the Working Group should
>        have put a stop on other work until those reviews were
>        completed. At a minimum, this may have caused some of the
>        ideas to be incorporated into the Microsoft/Google
>        specification once work resumed.
>      * The Working Group decided to incubate specifications outside
>        of the Working Group, which meant that they had no control
>        over how those specifications were incubated or the timeline
>        around them. In hindsight, it is clear now that this was not
>        just an experiment, but a dereliction of duty.
>      * The Working Group decided to incubate technical specifications
>        between two groups that are grossly unmatched in power: the
>        Web Payments Community Group and the browser vendors. Imagine
>        if we were to throw members of the middle class into the same
>        room as the largest financial companies in the world and ask
>        them to figure out how to extend capital to individuals in the
>        future. Each group would have a different idea on what would
>        be the best approach, but only one of the groups needs to
>        listen to the other.
>
> Two Proposed Solutions to the W3C Browser Incubation Anti-Pattern
>
>    We know that the following patterns hold true at W3C:
>
>      * Attempting to propose a browser API with little to no browser
>        involvement from the beginning, regardless of the technical
>        merit of the specification does not work.
>      * Attempting to propose a browser API where the browser vendors
>        do not feel sufficiently in control of the specification does
>        not work.
>
>    Giving browser vendors significant control over a browser API
>    specification and providing feedback via pull requests is what
>    currently works best at W3C. The downside here, of course, is that
>    no one but the browser vendors can expect to have a significant
>    voice in the creation of new browser APIs.
>
>    There are a few exceptions to the patterns listed above as some
>    specification editors are more benevolent than others. Some put in
>    more due diligence than others. Some standardization initiatives
>    are less politically charged than others. Overall, there has to be
>    a better way at doing specifications for browser APIs than what we
>    have at W3C now.
>
>    The simplest solution to this problem is this:
>
>    As a best practice, a Working Group should never have multiple
>    specifications that are still being incubated when it starts. The
>    Working Group should pick either one specification before it
>    starts or start with a blank specification and build from there.
>    All discussion of that specification and decisions made about it
>    should be done out in the open and with the group's consent.
>
>    Barring what is said above, if the group decides to incubate
>    multiple specifications (which is a terrible idea), here is a
>    simple three-step proposal that could have been used to avoid the
>    horror show that was the first couple of months of the Web
>    Payments Working Group:
>
>     1. Any Working Group that decides to incubate multiple
>        specifications that do more or less the same thing, and will
>        attempt to merge later, will always start out with one blank
>        specification under the control of the Working Group.
>     2. As editors of competing specifications finish up work on their
>        incubated specifications, they make pull requests on the blank
>        specification with concepts from their competing
>        specification. The pull requests should be:
>           + Small in size, integrating one concept at a time
>           + Pulled in alternating between both specifications (with
>             priorities on what to pull and when assigned by the
>             originating editors)
>           + Commented on by all editors in a timely fashion (or
>             merged automatically after 5 business days; it's better
>             to have conflicting material in the spec that needs
>             resolution than to ignore the desires of some of the
>             group)
>     3. The Working Group Chairs merge pull requests in. If there is a
>        conflict, both options are pulled into the specification and
>        an issue marker is created to ensure that the WG discusses
>        both options and eventually picks one or combines them
>        together.
>
>    The proposal is designed to:
>
>      * Ensure that the Working Group is in control of the
>        specification at all times.
>      * Ensure that proper due diligence is carried out by all editors
>        during the merging process.
>      * Ensure that a mix of ideas are integrated into the
>        specification.
>      * Ensure that steady progress can be made on a single
>        specification.
>
>    While I doubt the browser vendors will find the proposal better
>    than the current state of things, I don't think they would find it
>    so unpalatable that they wouldn't join any group using this
>    procedure. This approach does inject some level of fairness to
>    those participants that are not browser vendors and forces due
>    diligence into the process (from all sides). If the Web is
>    supposed to be for everyone, our specification creation process
>    for browser APIs needs to be available to more than just the
>    largest browser vendors.
>

Great post, thanks for the information!

I feel particularly let down by the W3C staff and chairs personally, and I
have made this known.  Having spent several years following and
contributing to the work in the CG, I promptly applied to join the WG
immediately after its inception, having set aside time to contribute.  Over
100 days passed before getting a response, after which Manu kindly sent a
reminder, and passed on some information.  By this time much had happened,
and my application was  compromised, it was less practical to participate.
I went on to clarify whether my application to join the group would be
accepted, or whether I would be required to apply through a W3C member
company (a big undertaking for me) and I was deliberately not given an
answer.  Having spent several years of effort in this area, overall, the
performance of the W3C staff and chairs I felt was not good enough --
something like this would unacceptable in a leading financial institution.
Tied in with the lack of support for the CG work you outline, that simply
exacerbates the situation.

My first question, is what wasnt Manu the chair of the group?  He is
eminently qualified.  I would have had much more confidence in getting a
world class spec to REC with him at the helm.  Recent conversations
indicate to me that, familiarity with W3C technologies such Linked Data,
are not as strong I would like to see from a individuals guiding
specifications.  This I would have thought would be a pre requisite,
especially for guiding specification level decisions.  Is there some
strange politics going on here?  The W3C is supposed to be vendor neutral.
That's like the "prime directive".  If that's not happening so, we should
find out why, and be prepared to change something.

Secondly, it seems that many of the voting stakeholders are not as familiar
with the material as they should be.  In other WG I have seen the concept
of "required reading" proposed before a face to face.  Im concerned that
consensus is being games e.g. by vote stuffing.  What can we do to achieve
more balance?

Thirdly, perhaps we could have seen this coming and presented a greater
front by working more together.  I think the verified claims work and webid
work could and should have come together.  IMHO the hostility shown to you
by Henry Story was a big part of that, and we should perhaps have perhaps
been less tolerant of Henry's periodic outbursts.  The work by digital
bazaar aligns quite closely with the work of the director of the w3c in
Solid, but we are not a united force so can be more easily divided and
conquered.  Is it time to put the technical differences to one side (e.g.
turtle vs json-ld, hash vs slash URIs) and create apps and app eco systems
that work together?

Lastly, please please please, dont abandon the CG specifications.  They are
some of the best work anywhere.  In a sense the CG is in some ways ahead of
the WG at this point.  I think there is a compelling case to be made though
interoperable implementations.  Im hoping to spend the next 3 quarters of
this year working on some.  This can often be a better way of convincing
people than simply a specification ...


>
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Web Payments: The Architect, the Sage, and the Moral Voice
> https://manu.sporny.org/2015/payments-collaboration/
>
>
>