Re: SOP wiki was: A Somewhat Critical View of SOP (Same Origin Policy)

On 29 Sep 2015, at 23:01, Tony Arcieri <bascule@gmail.com> wrote:
> On Tue, Sep 29, 2015 at 2:24 PM, Hodges, Jeff <jeff.hodges@paypal.com> wrote:
>> On 9/29/15, 9:45 AM, "Tony Arcieri" <bascule@gmail.com> wrote:
>>> On Tue, Sep 29, 2015 at 11:40 AM, Brad Hill <hillbrad@gmail.com> wrote:
>>>> Within the context of Web Origins, FIDO uses approximately the same scoping rules as cookies. That is to say, key scope must stay within a delegated label or its children and not cross delegation points identified by the public suffix list.  "www.example.com" and "register.example.com" can each set a cookie for "example.com" which the other can see, but subdomains of "hosting.example.com" cannot set cookies at or beyond that label if it is designated as a public suffix.  This provides some limited usability affordances within the existing information flow boundaries of the web security model while mostly that keys are scoped to a single logical organization as defined by domain registrars.
>>> 
>>> Huh, interesting, I wasn't aware of that.
>> 
>> that is what is explained in 
>> http://identitymeme.org/http-cookie-processing-algorithm-etlds/
> 
> In the case of FIDO though, I am guessing these are just rules for scoping App IDs, and both parties must "agree" (via JS running and contained via SOP) on the common App ID to use, unlike cookies where the cookie recipient has no power, only the cookie setter... 

Thanks Brad and Jeff for filling that in. Looks like we are all learning here.

So there are a number of ways to analyse the situation here as regards the 
definition of Same Origin ( SO )

1. Strict/Syntactic SO (SSO)
----------------------------

One could start with a strict notion of same origin. Here we limit membership of 
elements to a group that are tied to a syntactically defined notion of an origin
which constist of exactly a protocol, a domain and a port.

JS agents in the browser give CORS access rights based on such SSO groups. 
An example could help. We could write out a CORS group like this:

[] a cors:Group;
   cors:so "https://example.com"^^xsd:anyURI;
   sso:contains <https://example.com/js/mySinglePageApp.js>,
                <https://cdnjs.cloudflare.com/ajax/libs/d3/3.5.6/d3.min.js> .
 
I think that JS can be grouped by the same origin, if it was pulled in by a document from the original document's origin.

2. Wider SO (WSO)
-----------------

FIDO and cookies here are defining a wider notion of Same Origin that allows a number of origins to be grouped within syntactic restrictions set by domain lowering. We can think of this as a group or collection of SSOs. 

<https://www.example.com/appID#> a wso:Group;
   wso:contains "https://example.com"^^xsd:anyURI, 
                "https://register.example.com"^^xsd:anyURI .

This group is then used to specify where FIDO public keys identifiers can be sent to.
This allows the server to be both explicit and more precise about how the identifier 
should be used when compared to cookies.

Access Control
--------------

In both cases this group membership is used to specify access control rules as to what can be done in certain areas. 

• In the case of JS running in a page the cors group limits how that JS can communicate with other origins.
• In the case of FIDO this limits the application as to where it can send a key (? did I get that right )

Because cors ties JS from an origin tighter than FIDO, it will happen that a user can authenticate on a number of Origins with a key, but the JS from that origin will on the other hand not be able to communicate, being under different access control rules.

Is that on the right track?

Henry

Received on Wednesday, 30 September 2015 14:06:11 UTC