- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Wed, 28 Sep 2016 19:33:23 +0200
- To: Anders Rundgren <anders.rundgren.net@gmail.com>
- Cc: Timothy Holborn <timothy.holborn@gmail.com>, Web Payments CG <public-webpayments@w3.org>
- Message-ID: <CAKaEYhJ9bmdi4xLUDLD-_kiLywd1sCm0PSkw6MAc0XDQPcomQg@mail.gmail.com>
On 28 September 2016 at 18:37, Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > 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 :-) > But in this scenario, it also provides google with a back door into your system, as well as tracking each time you log in. Im not saying that's necessarily a bad trade off, in all cases, but removal of choice is clearly bad for end users. > > 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/br >> owser-api-incubation-antipattern/ <http://manu.sporny.org/2016/b >> rowser-api-incubation-antipattern/> >> >> >> >> >> >> > >
Received on Wednesday, 28 September 2016 17:33:55 UTC