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

Firstly,

Thankyou for your comprehensive response.

On Fri, 11 Mar 2016 at 21:32 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.
>
> I think stating that your application was "rejected behind closed doors"
> is not a true reflection of the conversation.
>
> Melvin has contributed significant works, which i know about due to having
spent vast amount of hours on subject matter that was delivered
@webpayments.  Some of his decentralised, linked-data related block-chain
work I still find incredible, without even considering his additional works
in figuring out how to append sufficient entropy to print it on a T-Shirt.

Whilst it is certain, we do not always agree, his skills within a very
particular domain are IMHO world-class, like, frickn amazing. So
opportunity lost perhaps.  Mind, i know he would contribute where he can,
where he can.  Et.al.


> @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.
>
> I'm far more interested in the credential work, yet, to suggest it's all
broken without granting the browser company access which is amongst my
biggest fears; well.  (I'll look into it more.)  and the documents as
they've been submitted seemingly fail to consider the background and
related authors,  which from a credentials perspective fails upon the basis
for provenance support.  As such, particular referable actors may be
effectively implicated in a 'timeline' UI should the means of credentials
and indeed graph technology, succeed in not producing particular forms of
silo methodologies which may well be considered near-sighted.

I am furthermore concerned about how anysuch considerations and
implications may impact and/or influence the progress of this work and the
ideological considerations therein.

importantly, some individuals (human centric) involved are not paid a wage
by their 'actor' and others are paid a 'wage', presumably by way of
contract with particular references therein.

Open Standards works, should support both, IMHO.



>
> 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.
>
> So, what hooks exist to the OS/Hardware layer without the browser vendors?


> 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.
>
> At what cost?


> 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.
>
> yet accept the outcome?


> 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.
>
> any?  consideration of the few actors in the room on a standard that will
impact humanity and the means in which things get economic attribution is
successfully based upon a tactical situation of which denotes these types
of considerations?

IMHO, What needs to be addressed at the AC meeting indeed includes whether
Manu is 'understandably Frustrated' and the implications, broadly...

Most important, is the consideration made on behalf of humanity as these
technologies reach maturity and as we all hope, benefit humanity via
utility of an 'open standard'.  Furthermore, what are the implications upon
the work being carried out by the Credential Community Group, who at some
stage is envisaged to be required to go through a similar process with
potentially similar outcomes...?


> 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've heard ideas that the development of technology is solely the domain of
Coders, which i reject.  A great many participants got involved and the
skillset delivered, works done on this common and/or shared interest, is
significant, now involving many very substantive organisations, perhaps
reasonably; only some of whom directly participate as a W3C Member.

It's been commented that the web is transitioning from a land of documents,
to one of data.  I suggest in that transition we do not exclude
consideration for particular forms of documents and/or the utility of
particular forms of languages embodied within any-such documents, encrypted
or otherwise.

Most of humanity does not code.  Yet, the hope is all of humanity will be
participating in the use of the payments standard via WWW.

Credentials is a means in which to support more effective notation of human
cycles.  It's important we do not discriminate, yet, much science is
involved in figuring out what that means...

the best code produces what may be said in many documents, in a couple of
lines.  This is similar to other languages.


> 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.
>
>
The nature of the parties involved produces even more concern for those who
may speculate.


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

The works carried out to get to the point of that meeting and its outcome,
is significant.  Yet, Manu or other relevant parties seemingly do not
appear on the document.  Perhaps in-turn this is part of the credentials
specification requirements?


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

We all get red-flags when security technology is not bundled by the browser
vendor.  Can you remind me, which is the 'choice of law' related
considerations for the majority of web-browser vendors?

How should that relate to economy/payments?


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

I look forward to the considerations made by the AC and indeed suggest a
press-release be made given the substantive nature of the properties
involved in these web-standards works, the appreciation of its potential
impacts over the next decade or so, and the good-faith we all invest,
whether as subject matter participants or indeed users; as to the
considerations made by those humans in the room.

The world admires those who will be in that room.  We're talking about they
way in which people are able to trade for survival and the supported
functionality made available to protect the (human) rights of those
involved overtime.


> 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
>
> Thankyou.    I do not profess to be the 'smartest person in the room', at
all.  Yet it is my hope that my considerations and indeed contributions
have had more meaningful contributory benefit, than if i had not
participated at all.  I imagine this may be considered by others also, as
it stands in document format today.

I can understand this is a very complicated matter, and I wish you the very
best with obtaining the best possible outcome for all stakeholders (humans)
as the work progresses.

Timothy Holborn
skype: sailing_digital


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