- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Wed, 28 Sep 2016 18:37:12 +0200
- To: Timothy Holborn <timothy.holborn@gmail.com>, Web Payments CG <public-webpayments@w3.org>
On 2016-09-28 15:05, Timothy Holborn wrote: > I often wonder where the strategic differentiation is in design > philosophy that results in heavy browser reliance vs. 'cloud' > alternatives that leave perhaps different MVP requirements for browsers. https://image-store.slidesharecdn.com/784bf26c-4ea7-4383-b89f-b92777167bb7-large.jpeg > What ever happened to <keygen> why was it bad? This is something I have a stake in since I proposed that it should be removed from HTML5 back in 2009 for the simple reason that a 2-week student hack, missing support for basic stuff like PIN-codes, isn't usable by banks and governments. That proposal didn't make me overly popular :-( When Google much later suggested the same but from another angle, everybody cheered and said "let's squash this dated piece of crap". Replacing <keygen> with something more 201X-ish wasn't on the menu. However, both Microsoft and Google have "enterprise solutions" for the US government et al to keep the (from their perspective) only real market intact. https://developer.chrome.com/extensions/enterprise_platformKeys > Or WebID-TLS UX support - too expensive? The USG have no UX problems since their users only have 0-2 certificates. The problem according to TAG is that client certificates potentially expose static IDs to parties that shouldn't have it. If you rather hand out static IDs through an IdP (Identity Provider) like Google, everything is just fine :-) A > > "Choice of Law California" seems to be a rather expensive problem to fix too... I guess so long as we can rely upon browsers, humanity can rest easy .. > > Tim.h. > > > On Wed., 28 Sep. 2016, 10:58 pm Adrian Hope-Bailie, <adrian@hopebailie.com <mailto:adrian@hopebailie.com>> wrote: > > I agree with 99% of what you have said Melvin but I disagree that the WG has dropped the ball. > > The WG is catching up. Don't mistake prioritization for ignorance or naivete. Before we can start to dive into practical standards development for "Web 3.0" we need to at least fill the huge gap that exists because payments as part of the Web stopped with response code 402 (Reserved for future use). > > What is often ignored from outside the W3C WGs is that the people who are implementing the APIs we design have a cost to doing so. For browser vendors, the actual development work is managed by product managers who must balance a desire to add features with the cost of doing so. > > It's easy to look at the browser vendors and say they are refusing to be innovative but another way to look at the situation is that they take adherence to the W3C standards seriously enough to ensure that the standards don't evolve faster than they can keep up. That is a lot more positive than if they simply didn't care what was in the W3C standards because they did their own thing anyway. > > If you want to accelerate things don't just bemoan the implementors. Consider contributing to their open source browser engines, building polyfills, writing tests etc. > > The HTTP APIs are the ones that will be most influential in the "Web 3.0" world and the WG is committed to focusing on those as soon as we have the browser APIs on track toward REC. Those specs are already published, has everyone in this community reviewed them, tried implementing them, commented on them, logged issues? > > There are a lot of groups looking at Web Payments NEXT, I can think of 3 at W3C off the top of my head: the Interledger Project, your Web Credits project, the Web Payments CG. Those groups are in the idea incubation, POC phase. Unfortunately a W3C WG doesn't operate with the same lack of constraints but with the HTTP APIs we'll have some more latitude because they are not implemented by browsers they are implemented by the wider community. The confluence of all of this work is ahead. > > Don't despair at the politics of standards development, this community is making great progress at doing the most important thing such a community can do. Building, testing, researching, debating issue and getting things done. > > > On 26 September 2016 at 17:31, Steven Rowat <steven_rowat@sunshine.net <mailto:steven_rowat@sunshine.net>> wrote: > > On 9/26/16 6:04 AM, Pindar Wong wrote: > > Well said indeed Melvin. > > > +1 > > > > p. > > > On Mon, Sep 26, 2016 at 8:53 PM, Melvin Carvalho > <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com> <mailto:melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>>> wrote: > > > > On 5 April 2016 at 23:05, Manu Sporny <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com> > <mailto:msporny@digitalbazaar.com <mailto: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 > <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 > <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/ <http://manu.sporny.org/2016/browser-api-incubation-antipattern/> > > > > >
Received on Wednesday, 28 September 2016 16:37:47 UTC