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

I've cc'd creds who may be unaware of the thread[3].

An array of benefits exist when local runtime enables further validation of
a local agent; and IMHO, that's quite known.  Additional issues exist
around the PKI chains and their implications for broader privacy / 'rule of
law' related use-cases / ideological position statements.  Whilst this may
be troubling for some, the calculation of 'net benefit' is a consideration
I'm yet to find a web-reference to refer to.

Perhaps part of the issues statement that may be addressed, is transparency
in a multitude of languages for the definitions made 'standards track'
pursuant to the requirements analysis relating to programme and scope of
work. at times it seems to be exclusively communicated in english, turtle,
or JSON-LD, which IMHO, seems to complicate matters unnecessarily at times.

Economics or 'payments' (the web alternative to transacting 'gold' couldn't
be less political, other than perhaps the notion of identity (notation
relating to facts of existence, and the 'trust' and accessibility criteria
relating to such 'facts' as is accessibly made available to a court of law).

indeed in many circumstances harm may be done but unless that can be
associated to the concept of 'damages' then, whilst it may be accepted it
was 'wrong' the economic and legal concepts relating to whether an actor
should do it anyway, remains/becomes unclear in a manner that seemingly
diminishes the capacity for a vulnerable legal entity to make a claim that
is binding in nature upon a persecutor[4]. As such, IMHO, diminishes
progress and threatens to enable the existence of a business system that
diminishes human progress rather than acting as an agent for its
advancement for political purpose.  Therein i reflect upon the
considerations made by another [5] and consider the implications of my
authoring this email, inclusive of the consideration indeed, that any
considerations should be made at all.

Tim.H.

[3] https://lists.w3.org/Archives/Public/public-webpayments/2016Mar/
[4] https://en.wikipedia.org/wiki/Karpman_drama_triangle
[5]
https://lists.w3.org/Archives/Public/public-credentials/2016Mar/0105.html

On Sat, 12 Mar 2016 at 00:18 Timothy Holborn <timothy.holborn@gmail.com>
wrote:

> On Fri, 11 Mar 2016 at 23:16 Anders Rundgren <
> anders.rundgren.net@gmail.com> wrote:
>
>> On 2016-03-11 12:38, Adrian Hope-Bailie wrote:
>>
> snip  "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
>>
>> I think, given this is beyond my field of expertise, IMHO, the claim
> should be validated, considered and/or responded to, by the AC as part of
> its considerations.
>
> considerations include, but are not exclusive to the statements by TimBl
> on Net neutrality[1] as the consideration may be extended to ASP's[2] and
> beyond, to the degree of other broader considerations.
>
> I spent a great deal of time considering ASP's[2] in the early naughties
> (2000 - 02), given the changes overtime, and whilst I failed to take-up the
> silo related opportunities then, I consider my involvement in this group to
> be a result of that learning experience and indeed, the magnificant work
> done in defining royalty free solutions as opposed to the alternatives of
> the time.
>
> IMHO, some issues change in their nature over time and as such, I believe
> we have different concerns that have been highlighted again by an
> international expert, with very different skills to my own, and as such
> deserve consideration as a constituent of the WIP (work in progress)...
>
> Tim .H.
> [1]
> http://webfoundation.org/2015/10/net-neutrality-in-europe-a-statement-from-sir-tim-berners-lee/
> [2] https://en.wikipedia.org/wiki/Application_service_provider
>
>
>> 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/
>>>>
>>>>
>>>
>>>
>>
>>