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

On 11 March 2016 at 11:30, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:

> 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.
>

@adrian, since I wrote that we've discussed this further (amicably), I
suppose I could retract the comment, or expand upon it.  Closed doors
refers to a non public process.  My application was rejected by mutual
agreement, as I can participate to a great extend not being an IE.  It was
unclear whether a future application would be accepted or rejected.  You
said you would "welcome my participation" but when I questioned what
exactly that meant, I was told it was intended to be neutral.  I do think
it was a judgment call (tho I dont know the full details), I do think it
was the wrong call, but it's one I can live with.  I appreciate a mistake
was made with my application, I appreciate efforts were made to correct it,
and I am happy with the current situation.


>
> 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/
>>
>>
>