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

I don't think anyone doubts your use cases or your cognitive ability.  I
doubt your understanding of history. People and organizations have been
trying to do this kind of thing since Chaum's first patents on blind
signatures in 1983.  Organizations as vast and powerful as Microsoft at the
height of its monopoly power have invested hundreds of millions into trying
to make it happen.

But here we are, in 2015, and Identity is still the White Whale of the Web.

The narrative I hear from the anti-SOP camp, that we've arrived at our
current equilibrium solely because of the conspiratorial behavior of a few
"super providers", and we can and should just tear it down and start over
with the user / user agent in control to arrive at a completely different
outcome is, frankly, cartoonish.  It ignores decades of history and
experience in technology, regulation, economics, operations, market forces
and human factors that have taken us through many experiments, and the
moving of the points of mediation back and forth between user agents and
origins, many times before.  I'll even grant that there were conspiracies
to seize power by powerful organizations, and we are where we are, in part,
not because they succeeded, but because so many of them failed, too.

You're trying to give user agents immense power and they're telling you
that they _don't want it_ because they do understand the history.   The
"argument to SOP" is not that it's perfect or captures every use case, but
more like the old joke about democracy - it's the worst system
possible...except for all the others we've tried.

There's really nothing different today in the fundamentals of how user
agents work, the cryptographic techniques at our disposal, or the use cases
of "I'm over 18" and "I'm a citizen" between now and 20 years ago. If you
want to propose walking down that road again, the obligation is on you to
be very convincing about what have you learned from that history that
nobody else did about how do to it differently this time.

-Brad

On Wed, Sep 23, 2015 at 11:21 AM Dave Longley <dlongley@digitalbazaar.com>
wrote:

> On 09/23/2015 12:39 PM, Harry Halpin wrote:
> > David,
> >
> > I simply do not believe that writing a spec for an identity or
> > authentication system and then pushing it to W3C browsers is a good
> > way for the authors of the specs to learn security and privacy
> > basics.
>
> I agree with this.
>
> > It is much better for learning fundamentals like same origin policy
> > for learning to be done in private, rather than in public mailing
> > lists, where these emails are beginning to verge on spam for many
> > people.
>
> I also agree with this. My point was that perhaps there's a greater
> understanding of these subjects than believed and, rather, some
> miscommunication is to blame for some of the disagreement. I didn't mean
> to single you out in my response, but I'm concerned that some of the
> responses in this thread and related ones have been too presumptuous
> about the knowledge level or cognitive agility of the participants. It
> just doesn't seem like a healthy way to have a discussion. I can agree
> that not having your facts straight is also unhealthy, but I think there
> has been too much hostility and condescension in these discussions.
>
> There are real world use cases where people want to express an identity
> that has greater scope than a single relationship. An argument has been
> made that this seems to be incongruent with the SOP. I don't think it
> is, but perhaps my view of the SOP is too traditional.
>
> Can one express the same identity (where identity is defined as one or
> more attributes about an entity) to more than one origin without
> violating the SOP? Can a person present an identity to one origin that
> is attested by another? It's unclear whether or not it is being argued
> that these would constitute violations of the SOP. And, if they do, if
> they should therefore simply never be done.
>
> You may say that this can all be resolved by learning about the SOP, but
> that doesn't seem to be the case. A simple reading on the SOP would
> suggest that it only has to do with the Web browser's restriction of
> scripts on one page accessing data on another page based on the sameness
> of their origin. However, the scope of the SOP seems to be greater than
> that and muddied in these discussions -- and not just by its critics.
>
> Perhaps there isn't consensus on the scope of the SOP. For example,
> whether or not a user chooses to expose the same X.509 certificate to
> more than one website seems to have nothing to do, at least implicitly,
> with the SOP. One way to resolve this would be to just say "this has
> nothing to do with SOP [for these reasons]". Maybe the argument is still
> relevant but about some other principle. I think this thread is about
> more than the SOP.
>
> You've suggested that almost any technology can probably be made to work
> with the SOP. I suspect that just about anyone who wants to help solve
> identity use cases would be happy with a solution that respects the SOP
> but isn't so encumbered by it that it fails to gain sufficient adoption.
>
> >
> > Again, exposing a single X.509 certificate (or public-private
> > keypair) to identify oneself across *all* websites won't make sense.
>
> I agree with this. I also think the fact that, presently, X.509 client
> certificates can be sent in the clear is a big privacy problem.
>
> > In particular "secure golden keys" tend to have operational failures
> >  that, the more they are deployed, tend to effect larger user-bases.
> >  Furthermore, one key-per person is I believe quite totalitarian in
> > any sense of the word - and key sizes and algorithms may be in a
> > state of flux over the coming years.
>
> I don't agree with the use of that word, but I do agree that one key to
> rule them all is a bad idea. There are always interesting privacy
> considerations when enabling new identity use cases or strengthening
> authentication. Just thinking about the new TLS ChannelID spec, we may
> be looking at much greater levels of confidence by law enforcement in
> proving that a particular computer was used or that two individuals were
> in the same room (who perhaps "shouldn't have been") at some point.
> There are always privacy trade offs.
>
> > Furthermore, one identifier per person is a perfect tracking tool.
> > One key to rule them all didn't work for Sauron, I see no reason to
> > see why it would on the Web :)
>
> I agree with this. But I also don't think people are suggesting that we
> move the Web in that direction. Certainly, that scenario is very close
> to the status quo today, at least for many people using federated login
> via super-provider. A lot of people are identified across a wide variety
> of sites using the same identifier -- and there is a lot of tracking
> going on. To some extent, humans want to have a common identity or must
> to accomplish certain societal functions. We need to ensure that we can
> safely enable them to do so when appropriate, while trying our best to
> protect their privacy.
>
> >
> > I understand some people like Henry Story, Anders, and perhaps
> > yourself believe such schemes based on 'one key to rule them all'
> > and violating the same origin policy are good ideas...
>
> I'm not in such a camp. I can't speak for anyone in particular, but I
> also suspect that very few are in such a camp. This sounds like
> miscommunication to me.
>
> I spoke a bit more about miscommunication earlier here:
>
> https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0100.html
>
> > E-mail addresses or other identifiers that are not bound up with
> > cryptographic primitives but can be bound to them as appropriate and
> >  dynamically make much more sense. For a good example of this in
> > action, you may want to look at OAuth and the TLS Token Binding work
> >  at IETF.
>
> I'm aware of that work, but neither directly address the use cases that
> I have primary interest in, which involve user-centric, third-party
> attested, verifiable attributes. Don't get me wrong. I think it's
> fantastic that people are working on ways to create stronger
> authentication of end points and cryptographically binding
> cookies or other tokens to particular channels to help avoid MiTM
> attacks and the like. That is very important work.
>
> However, no amount of cryptographic binding of a self-made assertion to
> a client ID that was generated on the fly is going to prove to another
> party that I'm a US citizen. The assertion must be bound to a trusted
> third party and such assertions, in my view, should then be given over
> to the user to control. This kind of verifiable attribute attestation
> happens at a higher layer (whether or not it gets bound to a lower one).
> As a side note, I also think the service that I use to aggregate such
> assertions shouldn't have to know every site I share them with as a part
> of the protocol. I'd prefer my user agent to blind such interactions.
>
>
> --
> Dave Longley
> CTO
> Digital Bazaar, Inc.
> http://digitalbazaar.com
>