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

Do use-cases exist that can support refining the problem statement into
standards track work?

if so, what are they...

On Fri, 11 Mar 2016 at 22:41 Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

> I disagree.
>
> What you are proposing is a generic open pipe between the execution
> environment in the browser and native applications. 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.
>
> 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 :)
>
> 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> 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/
>>>
>>>
>>
>>
>