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

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

From: Siva Narendra <siva@tyfone.com>
Date: Wed, 23 Sep 2015 06:47:46 -0700
Message-ID: <CAJhTYQyXK3uubRTqUOM9_GfRZOz+-kDjD7=SU9POJ-vnVjdz5w@mail.gmail.com>
To: Rigo Wenning <rigo@w3.org>
Cc: anders.rundgren.net@gmail.com, Henry Story <henry.story@co-operating.systems>, Brad Hill <hillbrad@gmail.com>, "Mike O'Neill" <michael.oneill@baycloud.com>, Tony Arcieri <bascule@gmail.com>, public-webappsec@w3.org, "public-web-security@w3.org" <public-web-security@w3.org>
Rigo. I think it will be useful to look at the minutes of the last W3C web
crypto workshop and the voting results.

FIDO has its place but it is not the only framework for the web. Web
standards ought to consider more inclusive framework and not just be a FIDO
shop. That was in summary the outcome of the workshop.

Consider this - For NIST Level 4 auth, FIDO applet can run on a smartcard
but so can other applets such as EMV/EMV tokenization or CAC/CAC derived
credentials - these may or most likely may not be FIDO centric.

Smartcard standards (the only globally universal hardware secuirty
standard) doesn't pick a favorite and is generic enough. Web standards
shouldn't either and can be made generic enough.

Siva
On Sep 17, 2015 7:10 AM, "Rigo Wenning" <rigo@w3.org> wrote:

> Brad,
>
> point taken and going back to the desk to learn more about it to find out
> how
> to use the one in making the other happen.
>
>  --Rigo
>
> On Thursday 17 September 2015 13:51:03 Brad Hill 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.
> >
> > -Brad
>
Received on Wednesday, 23 September 2015 13:48:15 UTC

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