Re: Web Payment PoC for semi-public testing

<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?


> - 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?


> - 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?

</snip>


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
>>
>>
>>
>>
>>
>