- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Fri, 26 Jun 2015 15:18:02 +0200
- To: UniDyne <unidyne@gmail.com>
- Cc: W3C Credentials Community Group <public-credentials@w3.org>, Web Payments CG <public-webpayments@w3.org>
On 2015-06-26 13:55, UniDyne wrote: > This is very interesting. Thanx! > I assume the proxy itself would be provided by the browser manufacturer. > Assuming the security / vetting infrastructure could be built around the > native bits, who provides them? Is it payment processors? The vetting would (IMO) build on existing schemes like Apple's for AppStore. The vetting process would only "guarantee" (within limits) that applications do not violate platform integrity and user privacy as well as conforming to the store's policy regarding content etc. It should preferably NOT be possible publishing an application without some kind of proof of ownership to the exposed name of the application ("com.mybank.pay.v1"). > User's banks? Both? The native applications would be supplied to the applicable store's distribution center in (almost) the same way as today but this is really up to each vendor to decide. A core idea is enabling third-parties creating powerful extensions to browsers as an alternative to lengthy Web API standardization processes for applications that the platform/browser vendors may neither be interested nor competent in. Yes, this scheme would allow closed source web applications. Although not exactly my cup of tea, some people have indeed expressed such interests...and it is vital listening to the market :-) > Does the user have a choice of native extension like they have a choice of search provider? Technically possible, implementation-wise less likely. Apple, Google or Microsoft do not offer any alternative AppStore's. However, a possibility would be that the invocation could target multiple applications like navigator.nativeConnect(["com.mybank.pay.v1","org.freebank.pay"]).then(function(port)... and then the system/user could offer a choice. If these application have identical Web-level interface everything is OK. If not, the actual application would have to be returned through the "port" object. This part obviously requires a bit more work/thinking/testing. Anders > > > On Wed, Jun 24, 2015 at 11:24 PM, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote: > > For those who (like me) do not regard browser vendors as the most logical > implementers of Web Payment systems (and Credential Management schemes...), > here is an alternative that can be tested on Windows, Ubuntu and Mac: > https://github.com/cyberphone/web2native-bridge > > I'm in the process of writing a Wallet but that's non-trivial, so you have to live with > a simple chat-like application which though shows the technology in its purest form. > > Comments are very welcome! > > Cheers, > Anders > >
Received on Friday, 26 June 2015 13:18:36 UTC