Re: WPWG On NOT abandoning the CG specs (was Re: Update on Web Payments Working Group)

A left field Example; If tooling for burning unique ids into products,
perhaps using open badge based solutions were made available to MFG's,
alternatives to traditional currency may end-up being a result. A bit like
barter...

A lot of MFG is based in parts of the world where access to VISA (as an
example) alongside Internet and electricity is relatively low.

So, therein is an opportunity where business models of today still fail to
support basic humanitarian advancement.

This in-turn looks a little more like the credentials methods than the
bitmark related methods, mind, I see a blend of great ideas being the most
useful for vulnerable people...

Finding one person who can supply attribution is likely easier than putting
a card in the hands of every person on the planet. Already buskers are
struggling in a cash-less society, so it's not like the service density is
improving with tech. Advancement at present, IMHO.

On Mon, 26 Sep 2016 at 10:56 PM, Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

> On 5 April 2016 at 23:05, Manu Sporny <msporny@digitalbazaar.com> wrote:
>
>> On 04/04/2016 06:49 AM, Melvin Carvalho wrote:
>> > Lastly, please please please, dont abandon the CG specifications.
>> > They are some of the best work anywhere.  In a sense the CG is in
>> > some ways ahead of the WG at this point.
>>
>> We have no intention of abandoning the concepts in the CG
>> specifications. We will fight for the consensus positions of this group
>> - level playing field, financial inclusion, innovative ecosystem, etc.
>>
>> The recent scuffle in the Web Payments Working Group is not the end. A
>> decision was made to use the Microsoft/Google specification as the base
>> specification for the Web Payments Browser API. We have the ability to
>> change those specifications. One approach is by submitting
>> counter-specifications like this:
>>
>> https://github.com/w3c/webpayments/pull/115
>>
>> Another approach is for people from this community to pick an issue to
>> fight for/against and move that particular item forward:
>>
>> https://github.com/w3c/browser-payment-api/issues
>
>
> Great!
>
> The way I see it there are three webs, and three payments webs:
>
> Roughly speaking:
>
> The Web 1.0 era (c. 1990-2000) is about web sites.  A typical payments
> solution would be a banking site or paypal.  This is a model that's works
> well on the web and can be standardized in a fairly predictable way by
> identifying common pain points, use case and creating uniform APIs.
> Definitely a pls.
>
> The Web 2.0 era (c. 2000-2010) is more about web pages.  Typically this
> allows a page to be a first class citizen of the web and dynamically access
> the network and update itself.  This has lead to patterns (primarily AJAX)
> that allow remote interaction.  Payments now can be done in the browser
> sandbox within a page, but in a very similar fashion to web 1.0, however
> without page reloads.  Similarly it makes sense for the WG to standardize
> this work and create APIs.
>
> The web 3.0 era (c. 2010-2020+) is about data.  Data, and particularly
> linked data, on the web becomes a first class citizen.  This is a
> fundamentally different model, but also one that very few people have yet
> to understand.  It is in a sense a more distributed and decentralized model
> of the web in line with the original vision.  Payments in this paradigm
> new, exciting, and very powerful, and can solve use cases existing and not
> yet imagined to date.  It can also handle all existing use cases via
> bootstrapping.  In this sense it's very similar to technologies like
> bitcoin.  It also covers a lot of the work done with JSON LD which deals
> with first class data primitives on the web.
>
> While it's valuable to try and modernize the work going on in the WG which
> is really revolved around web 1.0/2.0 technologies imho, it seems there is
> a political will do dumb things down to much that independent web
> developers are struggling to have their use cases addressed.
>
> It's common at the IETF to view a specification and have in your mind what
> future versions of that spec will look like.
>
> So Id like to work on essentially W3C Web Payments NEXT, without waiting
> for the modernization of the vendor payments system, shopping cart
> experience, choosing a credit card, and other nice things the WG is doing,
> but have relatively little relevance to the exciting modern internet
> payments phenomena.  I think the WG has dropped the ball, for various
> reasons on this one, but will possibly still have useful deliverables.
> Let's anticipate that, make it the best it can be, and perhaps look toward
> the next version of payments which can bootstrap the old and create a whole
> new era of use cases on the web ...
>
> I've spent a lot of time doing infrastructure and plumbing work for this.
> Im now ready to actually code stuff on top, and integrate it into real
> world payments workflows and live crypto currencies.
>
> I'd really like to take the recommendations here, and in the block chain
> community group to make very exciting payments workflows, in live systems,
> and incorporate existing useful workflows.
>
>>
>>
>>
>> > I think there is a compelling case to be made though interoperable
>> > implementations.  Im hoping to spend the next 3 quarters of this
>> > year working on some.  This can often be a better way of convincing
>> > people than simply a specification ...
>>
>> Agreed. Implementations matter. Digital Bazaar will be doing an
>> implementation of the Web Payments HTTP API and the hope is that
>> provides a counter-weight to some of the Browser API design decisions.
>>
>> -- manu
>>
>> --
>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>> Founder/CEO - Digital Bazaar, Inc.
>> blog: The Web Browser API Incubation Anti-Pattern
>> http://manu.sporny.org/2016/browser-api-incubation-antipattern/
>>
>>