W3C home > Mailing lists > Public > public-webpayments-ig@w3.org > September 2015

Re: Web Payment PoC for semi-public testing

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Tue, 1 Sep 2015 13:52:18 +0200
To: Adrian Hope-Bailie <adrian@hopebailie.com>
Cc: Web Payments IG <public-webpayments-ig@w3.org>
Message-ID: <55E59172.7030601@gmail.com>
On 2015-09-01 12:24, Adrian Hope-Bailie wrote:
> <snip>
>
>
>     Well, if your target is rather creating a standard supporting
>     - a defined and documented security model
>
>
> Can you explain why the security model that already exists for the Web is insufficient?

I was referring to the security model between web-pages and invoked local applications,
an arrangement which according to most Web-gurus isn't a [legitimate] part of the Web.
If applications rather are "listening" shouldn't make a difference, it is the same problem.


Anyway, according to the lot mentioned above, there's no need to do anything of what
you and I are currently discussing which makes this even more "interesting"!!!


>     - a simple JavaScript API
>
>
> I think the existing patterns for communicating with services from client code via
 > HTTP and Websockets is very mature and well understood. I'm not sure that a new API
 > adds any value. What does it offer that can't be achieved using the existing pattern?

How does localhost-based solutions transfer web-contexts including TLS-cert to the native
application except through a direct call to the remote service?  How do you maintain
web-sessions and cookies?  Well, I have done all of that but the code looks like c**p.
In addition, this "handover" from remote to local web has undefined security properties.

IMO, it smells like workaround.

>
>     - a bidirectional channel interface using OS/process level security
>     localhost schemes doesn't really match up.
>
>
> I don't understand what you are saying here. A native application will operate under
 > the policy that is defined for it by the OS. The fact that it exposes an HTTP interface
 > for integrations from code running in a browser on the same machine doesn't change that does it?
>
>
>     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.
>
>
> Using an HTTP service on local host doesn't strike me as requiring any changes to anything.
 > In fact the pattern is already widely used. What do you think needs to be standardised?

I don't know why Google introduced Native Messaging if it redundant, but it *may* have to do with
something of the stuff I'm writing.  That some services like www.dropboxlocalhost.com define public
DNS names as pointing to 127.0.0.1 indicates that the local web-server concept has flaws.

Related:
https://code.google.com/p/chromium/issues/detail?id=378566

Anders

>
> </snip>
>
>
>         On 31 August 2015 at 16:02, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com> <mailto: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 11:52:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:08:44 UTC