- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Tue, 1 Sep 2015 06:00:08 +0200
- To: Adrian Hope-Bailie <adrian@hopebailie.com>
- Cc: Web Payments IG <public-webpayments-ig@w3.org>
On 2015-08-31 22:32, Adrian Hope-Bailie wrote: > Hi Anders, Hi Adrian, > What are the advantages of using the web2native bridge versus calling a > native application listening on a non-standard port at 127.0.0.1? That's a very good question! Answer: it depends on your objectives. If your goal is to "just do it" (ship an application), using localhost (127.0.0.1) together with WebSockets is probably your best bet since it works "as is" on most platforms. So why on earth did I spend 6 months full-time on developing the Web2Native Bridge? Well, if your target is rather creating a standard supporting - a defined and documented security model - a simple JavaScript API - a bidirectional channel interface using OS/process level security localhost schemes doesn't really match up. Of course the browser vendors could make a specific "patch" to localhost but it will be equally hard to standardize as the Web2Native Bridge. Probably even more difficult since localhost already is a standard http/web feature. Note: The PoC does NOT support a "defined security model" simply because Google's underlying Native Messaging system doesn't do that either :-) https://github.com/cyberphone/web2native-bridge#security-considerations Anders > > Adrian > > On 31 August 2015 at 16:02, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote: > > Hi Payment-Gurus, > > If you have the possibility installing system software like Java SE on a PC or MAC at your disposal, > you can test an early version [1] of a decentralized [2], wallet-based [3] Web Payment system. I will > later create a short YouTube video that (hopefully) will explain the concept for non-programmers. > > For those of you who are in the process of creating some kind of Web Payment standard, I believe > the fact that the PoC system relies on a single and pretty universal (not "payment flavored"), > method added to the browser [4], should be of some interest. > > Although the scope of this project extends quite a bit beyond security, it may be worth mentioning > that the system uses an enhanced smart card for holding payment credentials (albeit in a software > version to make testing feasible without shipping hardware). > > After installing the Wallet software, you can try out the PoC at: https://test.webpki.org/webpay-merchant > > I'm currently working on a second generation that will contain an equally decentralized scheme for > protecting card data in traditional card networks , which is not based on Tokenization since I have found > out that the EMVCo Tokenization scheme has severe scalability issues. > > The system currently lacks some documentation... > Anyway, I'm always responding quickly to questions if you have some :-) > > Cheers, > Anders > Performing his weekly update > > 1] Getting the PoC software: https://github.com/cyberphone/web2native-bridge#installation > > 2] Decentralized payments: http://webpki.org/papers/decentralized-payments.pdf > > 3] The Wallet: https://github.com/cyberphone/web2native-bridge/blob/release/webpayment.client/src/org/webpki/w2nb/webpayment/client/Wallet.java#L116 > > 4] The added browser method: https://github.com/cyberphone/web2native-bridge#api > > > >
Received on Tuesday, 1 September 2015 04:00:47 UTC