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

> On 15 Sep 2015, at 23:19, Henry Story <henry.story@co-operating.systems> wrote:
> 
> 
>> On 15 Sep 2015, at 22:48, Alex Russell <slightlyoff@google.com> wrote:
>> 
>> 
>> On 15 Sep 2015 5:29 pm, "Henry Story" <henry.story@co-operating.systems> wrote:
>>> [snip]
>>> 
>>> ( They could have also have added WebID to the mix http://webid.info/ 
>>> but that is anoyingly simple, which is why I like it :-)
>>> 
>>> Now WebID is not tied logically to TLS [1]. We have some interesting
>>> prototypes that show how WebID could work with pure HTTP.
>>>  • Andrei Sambra's first sketch with 
>>>      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
>>> these two could be improved and merged.
>>> 
>>> This would allow a move to use strong identity in  HTTP/2.0 ( SPDY ) ,
>>> which could then be supported by the browsers who could build User
>>> Interfaces that give the users control of their identity with user
>>> interfaces described by your Credentials Management document developed here
>>>  https://w3c.github.io/webappsec/specs/credentialmanagement/#user-mediated-selection
>>> 
>>> Funnily enough one should already be able to try Andrei or Manu's
>>> protocol in the Browser with JS, WebCrypto, and ServiceWorkers [2].
>>> There are many things to explore here [3] and the technology is still
>>> very new. [4]
>>> 
>>> But this shows that WebCrypto actually allows one to do authentication
>>> across origins. ( And how could it not, since it is a set of  low
>>> level crypto primitives? ). A Single Page application from one site
>>> can publish a public key and authenticate to any other site with that key. 
>>> 
>>> So its a bit weird that SOP is invoked to remove functionality that
>>> puts the user in control in the browser, 
>> 
>> This assessment is patently false. What's being proposed for removal
>> is silent, automatic installation of keys without user consent. To
>> treat that as removal of user control is perverse bordering on prevarication.
> 
> We have 5 years of experience using keygen, and that is our experience of it
> on all the browsers for certificate creation and selection.

My presentation at the W3C Identity in the Browser Workshop 
in 2011 shows all of the following in action.

   http://bblfish.net/blog/2011/05/25/ <http://bblfish.net/blog/2011/05/25/>

The second video on that page shows how one can put the user even
more in control by tying the certificate creation to hardware token with
the privacy foundations open hardware crypto stick. That could of course
work even better with the facilities provided by FIDO hardware as it would
avoid having to carry around an extra device.

I can put other videos online if people have doubts
.
Btw, I already had 4 years of experience at that point with this, 
as my first blog on the subject was 

https://blogs.oracle.com/bblfish/entry/foaf_ssl_creating_a_global <https://blogs.oracle.com/bblfish/entry/foaf_ssl_creating_a_global>
> 
> A certificate creation
> 
> The <keygen> is an html element that is placed in a form and adds
> a menu item allowing the user to choose key strenght. The user has
> to 
>  1) click the form in order for the browser's keystore to create
>   a public/private key pair, and send the public key with the rest
>   of the form elements to the server. Here the user is in control.
>  2) when the server receives the public key it can create a certificate
>   and send that back to the browser with the mime type application/x-x509-user-cert
>   as you can see in the code here
>     https://github.com/read-write-web/rww-play/blob/dev/app/controllers/ClientCertificateApp.scala#L236
>   3) the user agent on receiving that certificate checks that the public 
>  key of the certificate has a corresponding private key in its keystore. 
>  If it has it can ask the user to add it to the keystore. Firefox did that. 
>  Chrome just alerts the user. If Chrome whishes to give the user more choice 
>  it could do the same too.
> 
>  The user chooses to submit the form, and the user can UI depending, choose
> to add it. Where is the user not put in control?
> 
> B. Certificate selection
> 
>   When a site asks the user for a certificte using TLS's simple mechanism
> for that, the browser pops up a certificate selection box to do this. The
> user can choose to select one or not to send any. ( Not all browsers are as
> good at this as Chrome or IE is, but I don't want to name names here )
> Where is the user not in control?
> 
>  This is not unlike Basic Auth. And it is not unlike what is proposed
> in the credential management document
>  https://w3c.github.io/webappsec/specs/credentialmanagement/#user-mediated-selection
> 
> I don't see how it can be provocative to point out the facts here.
> 
>> 
>>> and that WebCrypto is then touted simultaneously as the answer,
>>> when in fact WebCrypto allows Single Page Applications (SPA) to do
>>> authenticate across Origins, and do what the browser will no longer
>>> be able to do.
>>> Lets make sure the browser can also have an identity. It's an
>>> application after all!
>>> 
>>> Let's stop using SOP as a way to shut down intelligent conversation.
>>> Let's think about user control as the aim.
>>> 
>>> Henry
>>> 
>>> 
>>> [1] as it may seem from the TLS-spec which we developed first because it actually worked.
>>> http://www.w3.org/2005/Incubator/webid/spec/
>>> [2] http://www.html5rocks.com/en/tutorials/service-worker/introduction/
>>> [3] https://lists.w3.org/Archives/Public/www-tag/2015Sep/0051.html
>>> [4] which is why it is wrong to remove 15 year old <keygen> technology on which a lot of people depend 
>>> around the world as explained so well by Dirk Willem Van Gulik on the blink thread before a
>>> successor is actually verified to be working. 
>>> See Dirk's messages here:
>>>    https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/GnxmmtxSAgAJ 
>>>    https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/4kKNMVCdAgAJ
>