Re: P2P Payments

On 12/8/14 11:00 PM, Manu Sporny wrote:
> On 12/08/2014 06:36 PM, Kingsley Idehen wrote:
>> On 12/8/14 1:16 PM, Melvin Carvalho wrote:
>>> SOP = Same Origin Policy.
>> Who genuinely needs that in a Web of Trust where verifiable identity
>> is intrinsic and policies are driven by logic?
> Everyone. You don't want any random bit of Javascript to be able to
> change any DOM on any page that is loaded in the browser.

Hopefully, I am not indicating that I want that :)


I should be able to use logic to discern trust. Not "hard-coded" pattern 
in code that's eternally fallible or in best case inflexible and flawed.

>   SOP is a very
> good idea for a first defense against attacks.

It isn't. It's a "make do" solution due to the fact that it was created 
at the time when integrating logic into the Web en route to a functional 
Web of Trust was too far on the horizon, that's all.

>   Deny All, then relax just
> the bits you need is a good approach to security.

If driven by logic and relations. Which simply isn't what's happening 
with SOP.


>
> CORS was specifically designed to relax the SOP protections in browsers
> in particular important/common scenarios.

Yes, and we shouldn't really be thinking in terms of CORs or SOP. Both 
are discernible via logic. These are the kinds to things that are 
handled, naturally, in a Semantic Web. A data driven network in which 
Identity, the nature of things, relations, and relations semantics etc.. 
are all web-like.

>
>> These flaky and inflexible "big brother" hacks eternally undermine
>> the Web, especially via browsers (which are clearly now living on
>> borrowed time) :)
> Why is SOP a flaky and inflexible hack?

For all the reasons I mentioned above. It isn't driven by logic, 
relations, and reasoning on the aforementioned relations.

We should be able to basically indicate the following to a machine:

1. only accept data (code) published by some entity, from some location 
-- Client loading data
2. only allow application for the loaded code under specific 
circumstances (combination of events and operations) to the following 
address/url -- Client talking to Server -
3. ditto -- but server, as a double check, applying that (or similar 
logic) to client requests.

Also note, you can you "Link:" relations in HTTP requests, not just HTTP 
responses too [1].

[1] http://bugzilla.usnet.private:7780/bugzilla/show_bug.cgi?id=16433

Kingsley
>
> -- manu
>


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