Re: P2P Payments

On 2014-12-05 15:22, Kingsley Idehen wrote:
> On 12/5/14 8:50 AM, Anders Rundgren wrote:
>> On 2014-12-05 14:29, Kingsley Idehen wrote:
>>> On 12/4/14 2:48 AM, Anders Rundgren wrote:
>>>>
>>>> P2P payments are established in many places in the world.  My guess is
>>>> that none of these are based on standard web technology because this
>>>> technology simply isn't up to such tasks; it will take many years to
>>>> get on par with "Apps", if even possible.
>>>>
>>>> It is sad but the web is lagging and the lag is increasing due to the
>>>> success of Android and iOS.
>>>>
>>>> Anders (on Android)
>>>>
>>>
>>> What does "Standard Web Technology" mean?
>>
>> To simplify the discussion a bit: The web does not support client-based
>> cryptographic keys (except through HTTPS CCA which doesn't not sign
>> data).
>
> To me you are really saying: there isn't a W3C spec for user-agent-based
> cryptography.

There is a spec and it is called WebCrypto.  See next section.

>
>>
>> Well, the web actually *did* support signatures but the browser-vendors
>> (and W3C...) sitting in their ivory towers simply declared browser
>> plugins
>> as a bad thing without coming up with any kind of "replacement scheme".
>>
>> WebCrypto does *not* match up with the browser-plugins.
>
> Why not? You can now store data in storage associated with a browser
> that's local, since HTML5.

There are two issues which currently are not addressed.

1. This storage is usually not comparable in robustness to the
HW-based solutions. Or to be fully correct this is outside of
the WebCrypto spec which is a problem in itself.

However, the biggest hurdle is that such data is governed by SOP
which of course is fine from a security and privacy point of view
but is at odds with payment systems.  Well, the WebPayment CG has
a method for "neutralizing" SOP but I feel uneasy about it since
it appears to be very complex.  Somebody ought to spend a bit more
time on this spec.

>
>>
>> Seen from that perspective the web is effectively going *backwards* while
>> the App-environment is security-wise getting stronger and stronger, with
>> Apple Pay as a recent example.
>
> Apple Pay treats the device as the user-agent. Apple understands the
> importance of the host operating system i.e., that browser based
> user-agents != only kind of user agent.
>
> The Web is not about one kind of user agent, far from it, as mobile
> platforms continue to demonstrate.

Sure.

>>
>> In theory the WebCrypto.Next project could address this "deficit" but
>> I have
>> to date not seen anything that has even the slightest chance of
>> getting adoption.
>
> There is more than one kind of user-agent that can operate on the World
> Wide Web or any other HTTP based network. Web Browser are overrated, if
> you ask me :)

If you take out the browser from the equation life gets much simpler but I
don't want to do that unless I have to.

Anders


>
>
> Kingsley
>>
>> Anders
>>
>>>
>>> I do know of the Architecture of the World Wide Web (AWWW) which covers
>>> the key components for building a Web-like abstraction atop the
>>> Internet, comprised of:
>>>
>>> 1. URIs -- for denotation
>>> 2. HTTP URIs -- for implicit denotation and identification (courtesy of
>>> implicit Name->Address indirection for URI meaning interpretation)
>>> 3. HTML - language and notation combo for describing and representing
>>> documents
>>> 4. RDF - language for representing entity relations using a variety of
>>> loosely-coupled notations.
>>>
>>> 1-4 are the basis of the Web as we know it.
>>>
>>> #4 in regards to the "RDF" moniker is just a formalization (by the W3C)
>>> of what was always intrinsic to the Web's original design [1][2].
>>>
>>> Being "Standard Web Technology" based (as I understand it) is a little
>>> different from you continue frame this matter.
>>>
>>> Links:
>>>
>>> [1]
>>> http://bit.ly/evidence-that-the-world-wide-web-was-based-on-linked-data-from-inception
>>>
>>> [2] http://bit.ly/world-wide-web-25-years-later
>>> [3] http://www.openlinksw.com/data/turtle/general/GlossaryOfTerms.ttl --
>>> Glossary of Terms
>>>
>>
>>
>>
>
>

Received on Friday, 5 December 2014 14:42:15 UTC