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

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.

On Tue, Sep 29, 2015 at 5:50 AM Henry Story
<henry.story@co-operating.systems> wrote:

> On 29 Sep 2015, at 00:23, Hodges, Jeff <jeff.hodges@paypal.com> wrote:
>
> the claims made in https://www.w3.org/Security/wiki/IG/a_view_on_SOP#FIDO are
> incorrect — perhaps whoever wrote them did not read the spec in question
> carefully.  here's what I just entered in that wiki section:
>
> _THE ABOVE CLAIM IS INCORRECT_ "such as other web origins within the same
> DNS zone of control of the AppID's origin" essentially means that what is
> colloquially known as "domain lowering" (as in what is colloquially known
> as the "cookie same origin policy") is used to determine if a given web
> origin is "within the same DNS zone of control of the AppID's origin". How
> to determine this is specified in <
> https://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-appid-and-facets-v1.0-ps-20141208.html#determining-if-a-caller-s-facetid-is-authorized-for-an-appid>
> Step 14. See also 'HTTP cookie processing algorithm in terms of Same Origin
> Policy and “effective Top Level Domains (eTLDs)” aka “Public Suffixes”' <
> http://identitymeme.org/http-cookie-processing-algorithm-etlds/>. =JeffH
>
> Thanks Jeff for the input.
>
> I think this suggests that we need to look more carefully at the
> definition of SOP.
> I should add a section at the top of the wiki on that.
>
> Tony Arcieri has put forward a strict defintion of Same Origin in his mail
> today [1].
> For him two origins are the same if and only if they have the same scheme,
> domain
> and port. "Anything besides this is not following SOP." he adds. This
> reasoning
> leads him to the conclusion that cookies are broken. "RFC-6265 is in
> effect telling
> us that cookies are broken because a long time ago Netscape made some bad
> decisions."
>
> Tony's definition is what I would call strict Same Origin. [2] In
> opposition to this you want
> to define a weaker notion of Same Origin, following the Cookie Processing
> Algorithm
> you cite, and for which there are some nice examples in the FIDO Facets
> document [3].
>
> It is clear that the weaker notion of same origin has a wider identity
> criterion, that
> aims to be more flexible in its notion of origin, in that a number of
> Origin URIs identify
> the same agent.
>
> But according to Tony Acieri this weaker notion is not a notion of same
> origin at all.
> If so, and if he does not wish to also argue that FIDO is broken, then we
> need to understand
> what enables FIDO to expand from the notion of origin, or put in Alex's
> language how FIDO
> allows trust between origins to work.  There are a number of ways I can
> think of arguing
> this point.
>
>
> Henry
>
> [1]
> https://lists.w3.org/Archives/Public/public-web-security/2015Sep/0118.html
> [2] I made this distinction in the Cookies section, but should move this
> up to a SOP
>    definitions section
>    https://www.w3.org/Security/wiki/IG/a_view_on_SOP#Cookies
> [3]
> https://fidoalliance.org/wp-content/uploads/html/fido-appid-and-facets-v1.0-ps-20141208.html#appid-example-1
>   Mind you I don't quite understand why
>
>     https://www.example.com/appID
>
> can have
>
>    https://register.example.com
>
> as an equivalent weak Same Origin, but
>
>   https://companyA.hosting.example.com/appID
>
> cannot have
>
>   https://companyB.hosting.example.com
>
> as an equivalent same origin. ( The result makes sense, but the rules are
> not easy to follow )
>
>
>
>
>
>
> On 9/28/15, 12:47 PM, "GALINDO Virginie" <Virginie.Galindo@gemalto.com>
> wrote:
>
> Henry,
> I believe that the wiki page should start by  writing use cases, and not
> re-explaning SOP cons and your technical vision. If you want to trigger
> collaborative thinking, thanks for exposing:
> - Use case,
> - What feature in your use cases can't be achieved with today's technical
> rules.
>
> And then we will be able to have technical discussions about potentiel
> solutions.
>
> Regards
> Virginie
>
>
> ---- Henry Story a écrit ----
>
>
> > On 25 Sep 2015, at 15:38, GALINDO Virginie <Virginie.GALINDO@gemalto.com>
> wrote:
> >
> > Thanks for completing your use case on the wiki dedicated to that topic,
> guys !
> > https://www.w3.org/Security/wiki/IG/a_view_on_SOP
> >
> > Regards,
> > Virginie
>
> Thanks Virginie for the great idea of putting up this wiki. Mailing list
> discussions are very educational if one follows them with great care, but
> it is very difficult for people who jump in from the outside in mid
> conversation
> or who are following from the sidelines to understand what if anything has
>
> been gained by the discussion.
>
> I have brought together a lot of what I have learnt about SOP with many
> references to IETF and W3C specs, pointers to new evolutions in the
> webapp(sec)
> groups, and discussion with community members on the wiki
>
>   https://www.w3.org/Security/wiki/IG/a_view_on_SOP
>
> This weekend I re-arranged the wiki into three pieces
>
> 1. Conceptual map : just to give an idea how work from privacy, identity,
> security, logic, and other areas bear on the issue. There are still pieces
> to be filled out here.
>
> 2. Exceptions to SOP:
>
>   the more I look around the more I have found well documented and
> justified
> exceptions to narrow understandings of SOP. This should give us some good
> raw
> material for a later exploration of a theory of SOP.
>
> 3. Implications for Future standards.
>
>   A third section on who SOP is bringing up issues for future requirements
> such as
> WebPayments.
>
> 4. Theory of SOP
>
>   Here I think we'll be able to bring together an extended theory of SOP
> that makes sense of the exceptions, whilst showing how these tie into
> other elements of the conceptual spaces. My feeling is that a bit of work
> in some very initial modal logic of belief contexts would help give a
> secure logical foundation.
>
> I think this is taking shape. Of course there will be errors,
> improvements. It is not
> complete, so feedback is welcome.
>
> Henry
>
> ------------------------------
> This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
>
>