W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2015

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

From: Colin Gallagher <colingallagher.rpcv@gmail.com>
Date: Thu, 17 Sep 2015 14:48:56 -0700
Message-ID: <CABghAMi73DrgzQMF9bOV47-Trte2sC6h-YaZDGk+GbaLf+wUfQ@mail.gmail.com>
To: Henry Story <henry.story@co-operating.systems>
Cc: public-web-security@w3.org, Tony Arcieri <bascule@gmail.com>, "Mike O'Neill" <michael.oneill@baycloud.com>, Brad Hill <hillbrad@gmail.com>, public-webappsec@w3.org, Anders Rundgren <anders.rundgren.net@gmail.com>, Rigo Wenning <rigo@w3.org>
Hmm.

I have been watching this thread from afar, and I have a request,

Without use of terms such as "doomed standards" or "impossible to
implement" or "what (browsers) won't use/implement," and also while
avoiding negatory or accusatory language, could someone craft and post at
least several bullet points that sum up what you gained from reading this
thread, and the direction you think you should go based on what you've
learned from it?
On Sep 17, 2015 12:09 PM, "Henry Story" <henry.story@co-operating.systems>
wrote:

>
> > On 17 Sep 2015, at 14:51, Brad Hill <hillbrad@gmail.com> wrote:
> >
> >
> > 3/ Is FIDO excluding all other authentication and security tools
> >
> > No. I believe there is a place for something else that is less dependent
> on
> > large origins for their trust relation... --Rigo
> >
> > Again, with respect, this fundamentally misunderstands what FIDO does.
> >
> > FIDO works directly between end users and the sites they visit.  There
> is no third party dependency, let alone any relationship to "large origins"
> AKA "super-providers".
> >
> > This is exactly the beauty of de-coupling strong authentication from
> Identity,  FIDO makes strong authentication instantly available to every
> web application at every scale, without having to establish *any* trust
> relationships with third parties.  The relationships between users and
> applications are unmediated.
> >
> > How you exchange Identity or AuthZ assertions is an independent
> problem.  Federation is one way (which happens to have a large installed
> base and history of successful deployment) but it's an orthogonal issue.
> FIDO can work with this, but it can work as well with other technologies.
> Whatever shortcomings you may think that federation systems as deployed
> today, they are not shortcomings of FIDO.
> >
> > You can even do an Identity-entangled authentication with a client
> certificate, and then re-authenticate with FIDO over that secure channel.
> >
> > FIDO is just strong authentication, sans identity.  So rather than
> trying to hang the sins (whatever they are) of Federated Identity around
> FIDO's neck, you might instead consider whether perhaps the fact that we've
> failed to deploy strong authentication successfully at scale for so many
> years has anything to do with the fact that so far we've always made it
> dependent on a grand vision of Identity.
> >
> > Maybe we can do better by solving one hard problem at a time and using
> composable solutions.  To me, being able to make independent choices about
> the method and strength of my authentication, and whether and how I share
> information about my identity, seems to be much more respectful of the
> principle of User Choice than any entangled solution can ever be.
>
> I think Rigo was conflating a number of points which when seperated
> clearly I think you can actually agree with:
>
> 1) that FIDO is a good answer to the password problem
>
> 2) that FIDO is a good answer to establishing personhood, removing the
> need for captchas
>
>   because the verificator comes with a cryptographic key, identifying the
> type of device, and the server knows that a some personhood verification
> was made.
>
> 3) that FIDO does not exclude linkability solutions
>
>    it states so in the architectural document that it works with OpenID,
> OAuth and other federation protocols. As such it does not exclude
> certificate based authentication such as that provided by TLS, e-id
> systems, or much simpler cryptographic protocols such as those I mentioned
> earlier that would be compatible with HTTP/2.0
>
>   • Andrei Sambra's first sketch authentication protocol
>      https://github.com/solid/solid-spec#webid-rsa
>   • Manu Sporny's more fully fleshed out HTTP Message signature
>      https://tools.ietf.org/html/draft-cavage-http-signatures-04
>
>  4) that FIDO does not solve all privacy problems
>
>    for example not those that arise by having all information centralised
> on some huge servers. Eg. if in the Soviet Union the only computer system
> one were allowed to connect to were one owned by the party, and one were
> forced to do this with FIDO, one would nevertheless not say that people in
> this hypothetical Soviet Union using this system had any real privacy.
> I am invoking a very exagerated imaginary case just to make the point
> clear.
>
> All the best,
>
>    Henry
>
> >
> > -Brad
> >
> >
> >
> >
> >
> >
>
>
>
Received on Thursday, 17 September 2015 21:52:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:15 UTC