Re: User Control was: SOP - was: Agenda: <keygen> being destroyed when we need it

I made a couple of factual mistakes in my recent post, sorry.

> On 14 Sep 2015, at 15:43, Henry Story <henry.story@co-operating.systems> wrote:
> 
>> 
>> On 14 Sep 2015, at 10:07, Alex Russell <slightlyoff@google.com> wrote:
>> 
>> Going to try to be brief. Response inline.
> 
> Thanks for the response. Your points are well taken. We need a better theoretical
> understanding of SOP. I proposed an initial position, but am open to improvements 
> in it.
> 
> In the mean time it is worth noting that the WebAppSec working group has also been
> discussion SOP recently in the thread
> "Re: A Somewhat Critical View of SOP (Same Origin Policy)"
> https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/thread.html
> 
> I'll note that Rigo Wenning, W3C legal council, has made a point that buttresses
> the one I am trying to make here, in this thread:
> 
> https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0000.html

Wrong link: https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0077.html

> [snip]
> Now it should be possible for the JS from this origin to connect to
> remote origins in JS and use the cryptographic key to do WebID
> authentication over HTTP. There is an initial description of how this
> could work here:
> 
>  https://github.com/social-linkeddata/spec#webid-rsa
> 
> This then means now that all downloads started by a JS agent would need
> to go through JS, including downloads of images, CSS, pdfs, etc, etc. as they may
> be access controlled on remote servers and so would need the cryptographic authentication only enabled by JS agents. Clearly, this capability needs
> to be tied deeper into the browser than the JS layer - which is how the
> current certificate authentication built into the keychain works using
> TLS client auth. ( Hopefully webid-rsa will also help convince you 
> that we are not attached to TLS as the only way forward. )

So I was partially wrong here. What WebID-RSA ( a temprorary name 
while waiting for a better one ) allows one to do with WebCrypto, is to to authenticate across origins by using public key cryptography, which then 
sets a cookie, allowing the browser to download all other types of content.

The problem is that one would perhaps not want to authenticate immediately
to a web site. Imagine that JS from Origin https://bblfish.net/ follows links
to the server https://people.w3.org/ . Let's imagine that the data it reaches
there first is all public, describing the roles of people, and their relations
to blogs, w3c working groups, mailing lists, etc....  Let's imagine that due
to privacy reasons some members of the W3C team don't have pictures posted. 
Those are access controlled. 

Now my JS gets some JSON(-LD) data from the https://people.w3.org 
origin and builds up a DOM tree with inline <img src="/xxx/depiction.jpg"> 
elements. Can the JS intercept the 401 Unauthorized  codes, in order to
enable authentication using WebWorkers? 

Note that without that we do have WebCrypto working across origins, 
which is interesting. 

Henry

Received on Monday, 14 September 2015 17:45:56 UTC