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

On Sat, 12 Mar 2016 at 00:29 Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

> On 11 March 2016 at 14:12, Anders Rundgren <anders.rundgren.net@gmail.com>
> wrote:
>
>> On 2016-03-11 12:38, Adrian Hope-Bailie wrote:
>>
>> I disagree.
>>
>> What you are proposing is a generic open pipe between the execution
>> environment in the browser and native applications.
>>
>>
>> Yes, although I prefer calling it an application-neutral scheme for
>> implementing application-specific Web APIs.
>>
>> That's very different to a use case specific browser API that takes a
>> request and returns a response and requires that browsers/platforms that
>> implement the API define a mechanism for these messages to get passed to
>> another app and for the response to be passed back.
>>
>>
>> No.  The only difference is that the Google approach is application- and
>> platform-specific.  In most (other) contexts this would be called "a hack".
>>
>>
>> As has been said in that thread most see this as implementation detail
>> that we won't put in the specs but we do need to consider it as it imposes
>> design constraints.
>>
>> On the desktop I see those apps likely being Web applications that are
>> simply rendered by the browser (IPC already solved - postMessage) and on
>> mobile I doubt the mobile OS vendors will suddenly open up a full duplex
>> tunnel for IPC between apps just because of this use case... But hey, I may
>> be wrong :)
>>
>>
>> There are literally thousands of applications out there that could
>> benefit from COMBINING the power of the Web and App worlds
>>
>
> If that is true then the publishers of those applications are the ones you
> should be approaching to support your proposal. There are two ways to
> develop standards: 1) write what the authors think will be best for
> everyone and hope they all implement it or 2) gather the stakeholders that
> have tried to solve the problem and get them to agree on a standard way of
> doing so. i.e. They each make some changes  to what they are ALREADY doing
> so that eventually they are all doing the same thing - they standardize.
>

Depends on the stakeholder analysis...?

WWW got off the ground because of incompatibility issues from memory.  W3C
started because of Javascript wars [5], how does W3C refactor itself to
consider modern issues? Who are the stakeholders?

>
> One of the greatest risks for any CG is going down the road of number 1.
> When the actual implementors come to the table there is a great risk they
> will simply discard the work done before them for a variety of reasons that
> may be valid (implementation considerations that were missed) or invalid
> ("not invented here" mentality, hidden agendas).
>
> If you want to develop a standard that has, as part of its architecture, a
> browser API the best thing you can do is engage the browser vendors early.
> If that fails because your use case is too broad then you need to apply
> indirect pressure by finding the people who will derive value from your
> solution and get their support in persuading the browser vendors to
> consider your idea.
>
>
Is the suggestion that Manu failed to do so? [6]

> rather than fighting an uneven battle making nobody but a few W3C folks
>> happy.  Yeah, we have this great Web API standardization idea, any takers
>> out there?  No?  Seriously?
>>
>
> Either it's not such a good idea or you're looking for support from the
> wrong people. Creating a standard that has "general" usefulness is VERY
> hard. The use cases are too numerous and therefor the stakeholder group too
> big.
>
> If I was a browser vendor why would I want to implement this standard?
>

This is a good outline for stakeholdership [7], after all, if any person
was excluded for whatever underlying reason for the concept embedded within
the notion of 'payment', how would you survive or indeed, support the
survival of others around you.  What is the differentiator between what you
do as 'good for others' vs. 'nefarious'.  what court/s support discovery?

What happened?  Why did the spec change entirely after so many years work,
and what was the grounds for that change as i've not been able to easily
identify the issue either on the lists or the transcript.


>
>> This model is incompatible with time-to-market, third-party innovation,
>> and in fact with the Open Web itself!
>>
>
>> Anders
>> standing on his soap box
>>
>> Tim.H.
[5] https://www.youtube.com/watch?v=u_2YWiaPJ6A
[6] https://www.youtube.com/watch?v=bjbICcGanIg
[7] https://www.youtube.com/watch?v=rCplocVemjo


>> On 11 March 2016 at 12:53, Anders Rundgren <anders.rundgren.net@gmail.com
>> > wrote:
>>
>>> On 2016-03-11 11:30, Adrian Hope-Bailie 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.
>>>
>>>
>>> Obviously Google have found a (so far undocumented) way to "tame"
>>> Pandora's box:
>>> https://github.com/w3c/webpayments/issues/42#issuecomment-166705416
>>>
>>> What I'm proposing is simply bringing the dragon into the light instead
>>> of hiding it :-)
>>>
>>>
>>>
>>>
>>> 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>
>>> 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/
>>>>
>>>>
>>>
>>>
>>
>>
>