W3C home > Mailing lists > Public > public-webpayments@w3.org > December 2014

Re: P2P Payments

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Mon, 08 Dec 2014 12:56:13 -0500
Message-ID: <5485E63D.2050804@openlinksw.com>
To: public-webpayments@w3.org
On 12/5/14 9:41 AM, Anders Rundgren wrote:
> 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.

I didn't say or imply: "There isn't a spec" . I said: To me you are 
really saying: there isn't a W3C spec for user-agent based cryptography".

I think it should be pretty obvious to you that I know about the W3C 
WebCrypto spec.

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

Contradictory.

A spec != technical implementation i.e., you have a spec and then you 
have technical implementations of said spec.

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

SOP?

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

The Web Browser is but one kind of HTTP User Agent. It isn't the only 
user agent, and it can be darn limiting too! These limitations 
(thankfully!) aren't part of the mobile space.


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


-- 
Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this



Received on Monday, 8 December 2014 17:56:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:37 UTC