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

> On 28 Sep 2015, at 20:47, GALINDO Virginie <Virginie.Galindo@gemalto.com <mailto: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.
> 
There must be a misunderstanding. I am not arguing about SOP cons at all. I take it as a reality, though one that needs to defined more clearly, and whose logic needs to be made explcit.

There is an initial section about how SOP ties into other concepts such as logic, privacy, identity, security ( which I am looking for a better definition for). None of this says anything against SOP at all. ( though it may be that infelicities of language make it seem like this is so: please just send me pointers where you see that )

The second section lists 7 different technologies that explicity or implicitly go beyond SOP - or at least certain interpretations of what SOP may be.  FIDO does this for very understandable pragmatic reasons and I think they have  good logical reasons to justify this.  But because SOP is not clearly enough defined it leads to confusion. It may be that better definition of SOP may actually show that this all works nicely. What these examples do show that the space is just actually more complex than it seems at first. 

For example much depends on wether you have a narrow view of an origin - limited
to protocol:domain:port or a semantic view that that string names an agent that may have more than one name. FIDO it seems allows one to enlarge the notion of the agent to be named by more than one Origin string. Ie. it is more semantic. So do cookies.

All of these are actual use cases of deployed technologies using SOP in one way or another.

Finally there is an initial list of technologies that may need SOP that are in the works. 

1) WebAppSec Credential Management document that makes a clear statement about its need to go beyond SOP. I cite a part of their Working Draf
2) WebPayments  use case

I don't myself yet understand native messaging enough ( talk to Anders), and I think the hardware crypto section needs to be made more coherent.

Perhaps if you can point me to particular passages that are problematic with an explanation, I'll be able to understand what you are getting at more clearly. It was quite a lot of work to get this far and I am sure there 
are infelicities in the language remaining. It's a work in progress as wikis are meant to be.
> And then we will be able to have technical discussions about potentiel solutions.
> 
I think one needs to have a theory of how actual well respected technologies that seem to go beyond
SOP such as FIDO actually are justified in doing that. There are existing technical solutions that 
do this. What we need is to understand them. This theory will then help us understand new use cases as
they come along. Perhaps such a theory already exists. If so I'll be happy to read that up more carefully.

Henry

> Regards 
> Virginie
> 
> 
> 
> ---- Henry Story a écrit ----
> 
> 
> > On 25 Sep 2015, at 15:38, GALINDO Virginie <Virginie.GALINDO@gemalto.com <mailto: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 <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 <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.