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

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

Received on Wednesday, 23 September 2015 18:22:01 UTC