- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Sat, 02 May 2015 17:24:13 +0200
- To: Adrian Hope-Bailie <adrian@hopebailie.com>
- CC: Melvin Carvalho <melvincarvalho@gmail.com>, Joseph Potvin <jpotvin@opman.ca>, Web Payments <public-webpayments@w3.org>
- Message-ID: <5544EC1D.1040902@gmail.com>
On 2015-05-02 13:02, Adrian Hope-Bailie wrote: > Anders, > > While your numerous prophecies of the death of the browser vs the App may prove to be correct I'm not sure that makes W3C standards redundant. Hi Adrian, There's a certain TL:DR-warning here but I will try to answer as good as I can. The _Mobile browser_ is dead with respect to mobile payments, that's not a prophecy, it is a fact. If the W3C wants to change this they should start with researching existing systems like Apple Pay. > I acknowledge that a lot of what is discussed and standardised at the W3C revolves around browsers, but these are not the only Web clients. In fact in most cases mobile Apps are also HTTP clients using technology such as REST (or similar) to communicate with the services they rely on. Yes, and these work fine AND _enable third-party developments_ which makes a huge difference. > I would encourage you to provide some constructive feedback on the proposed architecture from the Web Payments IG and the idea of a payments agent, which may or may not be built-in to a user agent and, which would use the Web and Web technologies to interface with a distributed network of other payments agents. My limited brain doesn't go that far :-) I'm a hand-on-guy so I "simply" try to cast known scenarios (one at a time...) into some kind of architecture and API. OTOH, this proved to be pretty useful, and I think the Web Payment IG should carefully study the _published results_ a bit before carrying on. Furthermore, I do not believe that there ever should be a "Browser Payment API" because this would quickly grow in all directions until it effectively becomes an entry-point to payment-system-specific drivers like we already have for peripherals. Wouldn't the driver-thing be great I guess you wonder? IMO it would stifle innovation since the drivers most certainly would have to be supplied by the browser-vendors because they actually constitute an integral part of the browser. Only agreeing on the UX seems like a horrible task from a standardization point-of-view. > > There is a great deal of work to be done in taking the various phases of a payment (as defined in the use cases document) and defining standard vocabularies, models, messages and protocols that would be executed between one or more payment agents to complete a payment. > > User access to their payment agent will only occasionally be through a browser, it could easily be that the service that is acting as the payment agent is sitting on a web server or is an App on a mobile device.. What I believe we have consensus over is that the communications between these agents will use Web technologies (existing or possibly new) which have been standardized at the W3C. I get that but I have yet to see a concrete example of how that is going to work on a lower level. I suggest taking on a simple example first to get the ball rolling. The WebCrypto.Next folks didn't do this exercise and that proved to be absolutely fatal. > > It is also quite possible that if we are successful in getting widesperead adoption of this architecture and associated protocols that the browser vendors will be forced to incorporate this functionality into the browsers or risk being dis-intermediated as you predict they will. > > Looking forward to progressing on from the browsers are dead, the browser vendors don't care, everyone wants apps so why do we bother discussion :) Everyone (except Microsoft) I have talked to who represent _platforms_ say the following: Bring on the code and we'll see! Nobody seems particularly interested in _other peoples'_ specifications. I'm unfortunately a lousy browser-programmer but I will do a serious effort trying to implement the Web2Native Bridge for empowering third-parties targeting browsers with virtually the same ammunition as Google! Anders > > Adrian > > > > On 1 May 2015 at 18:45, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote: > > On 2015-05-01 18:27, Melvin Carvalho wrote: >> >> >> On 29 April 2015 at 14:46, Joseph Potvin <jpotvin@opman.ca <mailto:jpotvin@opman.ca>> wrote: >> >> RE: [DRaggett] "That would seem to be very different from the personal wallet with multiple payment instruments that the W3C Web Payments IG is chartered to work on." >> >> The W3C Payments IG works on negotiating a common specification for the interface between wallet systems and the payments systems, no? That's to say, the interface only, nothing beyond that. Or do I misunderstand? >> >> Another couple of questions: >> >> Is a bank account a type of digital wallet? >> >> >> A bank account is not a digital wallet, imho, but banks can implement wallet software that uses W3C standards. 15 years ago most banks were web skeptics, but now that they have seen the advantages, most have an on-line presence. When the advantages are seen the market will take it up, with normally a few early adopters creating new businesses. > > AFAICT Banks and Merchants are gearing up for mobile payments which are based on "Apps" rather than on browsers and for the purpose suitable (non-existing) W3C standards. This is similar to authentication where the trend is clear: Leaving the Web for "Apps". > > Anders > > >> >> Does the provider of any e-wallet SaaS come under banking laws & regs? >> >> If the answer to either of these question is "no", what are the boundary criteria between e-wallet systems/services and banking systems/services? >> >> Joseph Potvin >> >> On Wed, Apr 29, 2015 at 8:24 AM, Melvin Carvalho <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> wrote: >> >> >> >> On 29 April 2015 at 13:47, Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>> wrote: >> >> >>> On 29 Apr 2015, at 13:37, Melvin Carvalho <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> wrote: >>> >>> Dave, I've been thinking a lot about sync lately, during my testing phase. >>> >>> I think traditional methods for sync here are not going to meet my needs. I'm thinking more along the lines of UNIX IPC. In particularly, shared memory and messaging. >>> >>> In the case of shared memory, two wallets will have the same URI and then merge when connections allow. >>> >>> In the case of messaging wallets allow information to flow like water in a network. This becomes more spontaneous. I envision a web of wallets, a user may have many wallets all talking to each other and triggering things. Your fridge may order food on your behalf when it gets low. A family may have a shared area for photos and video, with payments triggered as more files are uploaded. A person may track their work locally for analysis, then send a summary to employers and accountants etc. >>> >>> Importantly, I no longer see a distinction between payment processor and wallet. A payment processor to my mind is just a multi user wallet. I like the wallet metaphor in this context. It's not hard to create and destroy wallets spontaneously, to add block chain technology over the web, to deploy smart contracts in javascript and to have personal coinbases (aka currency mints) regulated via a ripple-like web of trust. >> >> As Patrick recently pointed out the W3C Web Payments Activity is seeking to create a level playing field for many payment solutions. I see a distinction between wallets and the things they contain. Joerg Heuer provided a nice list of the different kinds of things that a wallet could contain. When it comes to synchronising a pair of wallets, an object oriented approach seems reasonable, where objects define and own their properties and methods. The wallet can merge its contents, but when it comes to merging payment instruments of the same kind, then this is something that the payment instrument should be responsible for handling, including resolving any conflicts that may occur. >> >> >> I agree the wallet is a container. And it can contain anything. My main distinction is that the wallet software can provide one for one person, many for one person, or many for many people. >> >> Consider the real world, you have a pocket, which may contain notes and change. You have one or more leather wallets, sometimes you'll take money from one and put it into another. You have a bank account which you'll periodically put money into. You may have a digital wallet too. What coins you put in your pocket doesnt matter, in fact you can put anything in your pocket. The wallet software handles these cases (and I think should handle these cases) interchangeably. It's a case of giving the wallet a URI then key value pairs like an object, then what I do is add hooks when a payment is made, or have daemon processes making payments, or triggers when a smart contract is fulfilled the payment is made. >> >> Conflicts are interesting and that's what Im testing now. The most common failure case is to test balance goes below zero. But in the case of agreed overdrafts, that can sometimes be relaxed, in certain cases. >> >> >>> The reason I take the UNIX analogy is because I see the next gen of the web becoming much more like an operating system, than a browsing space. Some of this may probably be suitable for v2.0 of the web payments spec. But I probably will have it all coded up and working in an MVP by the time v1.0 is out. >> >> It sounds like you are implementing a multi-user wallet for a specific payment solution. That would seem to be very different from the personal wallet with multiple payment instruments that the W3C Web Payments IG is chartered to work on. >> >> Best regards, >> — >> Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>> >> >> >> >> >> >> >> >> -- >> Joseph Potvin >> Operations Manager | Gestionnaire des opérations >> The Opman Company | La compagnie Opman >> jpotvin@opman.ca <mailto:jpotvin@opman.ca> >> Mobile: 819-593-5983 <tel:819-593-5983> >> >> > >
Received on Saturday, 2 May 2015 15:24:49 UTC