Re: Payments activity - any point to our time and effort?

Hi Web Payments and Credentials CG,

This is my perspective on the last few weeks in the Web Payments WG and my
request for those in the Web Payments CG to continue to participate. I'll
try to address a few specific people in the thread and also give my
over-arching perspective.

This is my personal view of the world, not Ripple's and not the Web Payment
WG's.

@anders:

Your efforts to promote a Web to native bridge are well-known and I realise
you have had little success in getting traction. I believe the reason is
that what you propose is a pandora's box of new security vulnerabilities.

What is being proposed for the payments API is a very specific API that
allows implementors to decide how the bridge from the API to the payment
app will be exposed. Personally, I think the correct approach is for
payment apps to be web apps so there would be no native app communication
anyway.

On the mobile platform this may not be an ideal UX so implementors are
likely to allow a payment request to be passed to another mobile app and
for that app to return a single response back to the browser app. I don't
expect there to be a new inter-app channel created for duplex comms.

i.e. What's being proposed is not as similar to your idea as you think.

@tim/steven: I wouldn't consider the Payments CG's work as wasted effort.
By the time we met in SF the two proposals had converged a great deal,
mostly because the browser vendor proposal had adapted to consider feedback
from the group. More later on the value of the CG's contributions

@melvin: As you, Ian and I have discussed; there was a genuine error that
resulted in your application to join the group being lost until Manu
prompted us to respond. When we did, we came to an agreement (with you
included) that there was no need for you to be an IE as you are able to
participate in the WG lists and GitHub without being an IE and that was all
you intended to do.

I think stating that your application was "rejected behind closed doors" is
not a true reflection of the conversation.

@web payments cg: All of the work of the WG is happening in public lists
and public GitHub repos and your input is highly valued. We plan to take
the browser API to FPWD with a CfC to publish in ONE WEEK. Please review
the specs and provide your comments before 15 March!

https://github.com/w3c/browser-payment-api

Non-members will not be able to make PRs as you are not party to the IPR
commitments but, if you have something to contribute and it's valuable I'm
sure one of the members will be happy to submit a PR on your behalf and you
will be able to join the discussion against the PR when it is made.



To clarify what has happened over the last few weeks:

(And I would recommend reading the full minutes of the afternoon of 23 Feb
not just Manu's additions which are now there on the record:
https://www.w3.org/2016/02/23-wpwg-minutes)

There were two proposals put forward when we met face to face, for a
payments API for the browser. There was not a lot separating the two and
the group was pretty evenly split on which to adopt.

It was pretty clear, and I called this out in the meeting (it's in the
minutes) that the support for the Google/Microsoft proposal was from ALL of
the browser vendors and the support for the Web Payments CG proposal was
from a variety of other members.

For the sake of progress Manu proposed that we simply adopt the browser
vendor spec so we could move on. This was a very selfless act as Manu, Dave
and others had put a great deal of effort into the CG proposals. Ultimately
we were always going to disappoint one group of proposal editors.

Personally I believe the CG proposal was better, more mature and I
preferred the shape of the API. However there was not consensus and by
picking a proposal we were able to spend the next day more productively.

I don't believe the browser vendors dedicated enough (any?) time to looking
at the CG proposals and because of that were nervous to even consider
adopting them even when it became clear there was very little difference
between them. Manu was understandably frustrated at this and I think this
should be addressed at the AC meeting.

What needs to happen now (and this request is also in the minutes) is that
all of the aspects of the CG proposal that are not in the WG spec must be
added via PRs from the group.

Digital Bazaar are currently the representatives of the CG but that
shouldn't mean Shane, Manu and Dave are the only ones doing any work on the
specs if the CG has desires to influence the direction it takes.

I would recommend that the CG fork the WG spec into the CG repo and that CG
members make PR's into that copy. If any WG members want to push those same
PR's into the WG spec they can then do so without needing to do all the
work of writing the spec text.

My point is, it's easy to rant and comment on the lists but getting down
and doing the work is hard and to date it is all being done by Digital
Bazaar. If the CG is going to play an active role then the whole group
should get involved.

I agree with Manu that what went down was an indication that some elements
of the process are broken. Starting a WG with two "competing" proposals is
a bad idea. It helped surface some useful discussions but also split the
group and was destructive.

My suggestion for the future is that if a CG has a proposal and the browser
vendors don't like it that the WG doesn't start until they have either made
the changes to the CG proposal to get it in shape or made an alternative
proposal that the CG agree to adopt. I don't see a good reason to start a
WG until that is resolved.

At the same time we must be pragmatic. Users of the Web use browsers. If
there is anyone that feels the browser vendors are abusing their power they
should offer the Web's users an alternative and be able to make the case as
to why that alternative is better. Until then we must find ways to persuade
the existing browser vendors to accept our input.

Also note that in this instance we are talking about a browser API. The
only implementors of this spec will be browsers so it stands to reason that
their input on the spec carries significant weight.

Consider what would have happened if either Nick or myself had proposed
that the CG proposal be adopted and had used our chair's veto to override
the objections from the browser vendors. Why would they even continue to
participate in the group? They certainly have no obligation to do so. What
value is a W3C spec that has zero implementations?

I will be at the AC meeting this month and I will certainly lend my voice
to any discussion regarding the process of starting WGs and the migration
from a CG which has no browser vendors involved from the outset BUT we must
also appreciate what the CG has achieved. A few years ago payments weren't
even on the W3C's radar now we will likely have a payment API in browsers
this year.

What that API looks like and how it works is still to be decided and that
CAN be influenced by you but not if you simply send mails to the
Credentials CG list bemoaning how hard it is to be heard.

Right now history will say that one proposal was favored over another and
nothing more. If the CG makes the effort to incorporate the many aspects of
it's proposal that fill gaps in the WG spec and can make sound technical
arguments for their inclusion, we may end up with a final WG spec that
looks very similar to the CG proposal. That would be a very inefficient and
round-about way to get there but that is the only way to prove that the
process is broken and that, on technical merit, the CG proposal should have
been adopted from the beginning.

With my WG co-chair hat on:

Please read the specs, comment on them and join the discussion
Please continue to make proposals for the other pieces of work that we are
still chartered to do like the HTTP API
Please be pragmatic and smart in your approach to this work.
Please don't spam the mailing list or issue list. That will be
counter-productive.

Finally, if you believe you have a technically superior proposal that the
editors are fighting against and you believe their reasoning to be driven
by ulterior motives then look for support from the wider WG. If the group
doesn't like your ideas don't be offended. Go and figure out why and come
back with better ones, don't just blame the browser vendors for being
stubborn.

Adrian


On 10 March 2016 at 17:12, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 03/05/2016 05:09 AM, Timothy Holborn wrote:
> > maybe i missed it, but is there a brief on the implications of the
> > recent changes in the payments work.
>
> I'm writing up a blog post that will hopefully put everything in
> perspective. To be clear, there is still a lot that we can do and have
> an impact on, both in Web Payments and in Credentials / Verifiable
> Claims. One of those things is probably not the browser API (without an
> enormous amount of effort).
>
> That said, there are lessons to be learned here wrt. the credentials API.
>
> > we've followed the call to support payments use-cases in creds work.
>
> Yes, and that went a great deal toward getting the Web Payments IG to
> vote in favor of moving the Verifiable Claims work to the next stage.
>
> > What's the situation now?
>
> Will hopefully have the blog post up by next week, before the W3C
> Advisory Committee Meeting at MIT.
>
> -- 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/
>
>