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




On 9/28/15, 12:47 PM, "GALINDO Virginie" 
<virginie.gali...@gemalto.com<mailto:virginie.gali...@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.gali...@gemalto.com<mailto:virginie.gali...@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.

Reply via email to