Same Origin Policy - Re: Agenda: <keygen> being destroyed when we need it

Thanks Alex for your very good summary.  I don't want to go over the good points made by 
Melvin and Anders, but to hightlight this part of your mail:

> On 12 Sep 2015, at 02:20, Alex Russell <slightlyoff@google.com> wrote:
> [snip]
> Developers who want to persistent keys to the local system should acknowledge that this is an operation that lives outside the Same Origin Model. The inability to scope the use of keys added via <keygen> (via addition to the effective keychain) creates a major hole in our one workable security primitive. It's true that this isn't part of the <keygen> spec, but compatibility requirements have caused this to be true in practice. From an architectural perspective, this alone should be enough to cause the TAG to recommend removal of <keygen> and replacement with a better, origin-scoped alternative.
> [snip]

I think this is the core of the discussion. It is this blind application of SOP here that I and others wish to question.

It is quite clear to me that if this principle were not thought to be untouchable then people would long ago have found an answer to all the other problems you and others have mentioned. The Browser vendor Engineers  would have 
 - found a way to improve or replace spkac, 
 - a debate about how to extend the <keygen> tag so that it could enable a better UI, and many other features required would have lead to fruitful results
 - taken the opportunity to work with the IETF on better certificate formats such as JOSE or supported work on non syntactic bound certificate formats by reading up on research done on the semantic web side of things
 - people would have even found ways of taking a leaf from FIDO and find a language to limit certificate usage to certain range of applications
 - there would have been enthusiastic support for improving the user interface of browsers to integrate WebID and make the experience extreemly user friendly and social network aware
 - ....

But of course if you believe that a certificate should only be used for the origin from which you got it, then it makes no sense to continue with <keygen> which allows you to generate a certificate (X509 at present) whose whole purpose is to safely allow you to use it cross origin ( which is why it is used for server authentication in TLS ).
   So client-certificates-usable-across-origin is really what people think SOP argues against. And so from that perspective the anti SOP, anti-linkeability commitments of FIDO [1] makes perfect sense.

But SOP is not a foundational principle of the web, which is primarily about linkeability historically and conceptually. SOP is essentially a JavaScript (JS) limitation introduced because JS introduced agentood into a declarative web. In addition to the agenthood of the User Agent and the User, JS introduced the agenthood of JS fetched from the web. This follows from JS being a procedural/functional language that can act in the browser environment by clicking links, downloading information, POSTing forms, ... SOP is one way of identifying JS agency, and then limiting it.
Note: It is not a particularly good way of identifying JS agency, as it is way too broad. Signed JS attributing it to an author or organisation would be a lot better. ( requiring therefore a certificate ). 

SOP applies to cookies. But the user is never asked by the chrome whether or not a cookie should be set. Cookies are SOP by design. 

So Why is SOP important for certificate usage? It is clear that any privacy enabled browser should

a. on being asked for a certificate by a web site first ask the user which certificate to choose
b. show the user which certificate he is actually using during a session at a site
c. enable a mode where the user is not using that certificate ( Chrome has the Persona UI for example ) [2]

At all these stages the chrome is giving the user control of decisions. There is no JS agency that can take this over. Exactly for this reason SOP does not apply, and it is exactly for this reason that chrome integration of identity is so important.

This is my analysis. Where am I wrong about the non-application of SOP? What Web Architectural Principles do you rely on to justify the application to this case of certificate generation and useage.

Sincerely,

Henry Story


[1] see my previous mail "(un)linkability - Re: Agenda: <keygen> being destroyed when we need it" for references
   https://lists.w3.org/Archives/Public/www-tag/2015Sep/0023.html
[2] I realise now that  logout does not actually make sense because one a user has authenticated a cookie can be set to track him, or information kept in URLs. This should be explained somewhere.

Received on Saturday, 12 September 2015 10:19:49 UTC