- From: Henry Story <henry.story@co-operating.systems>
- Date: Tue, 4 Aug 2015 11:18:25 +0200
- To: Anders Rundgren <anders.rundgren.net@gmail.com>
- Cc: Andrei Sambra <andrei@w3.org>, public-webid@w3.org
> On 4 Aug 2015, at 09:05, Anders Rundgren <anders.rundgren.net@gmail.com> wrote: > > On 2015-08-04 08:12, Henry Story wrote: >> >>> On 31 Jul 2015, at 17:25, Anders Rundgren <anders.rundgren.net@gmail.com> wrote: >>> >>> On 2015-07-31 15:47, Andrei Sambra wrote: >>>> I’ve already started work (this spring) on an alternative auth >>>> protocol based on WebID, which uses the new WebCrypto API. You can read about it here [0]. >>> >>> Pardon my ignorance but I don't understand how WebID-RSA works since >>> WebCrypto is SOP-crippled. That you can generate a key on the fly >>> is true but exactly what does that buy? >> >> What does SOP-cripled mean? > > HTTPS CCA (Client Certificate Authentication) allows you to share a certificate > with any number of sites (domains). This is huge drawback according to the folks > working with core Web security- and privacy-technology in W3C. > > WebCrypto as well as FIDO/U2F only allows the domain who generated a particular > key to "see" it following SOP (Same Origin Policy). > > If you need to generate a new key for each site you are visiting, I don't see how you > could maintain the binding to a particular WebID without running something like an e-mail > verification round-trip which IMO would make such a system much less attractive. yes, that indeed seeems to be the situation. As you pointed out in another e-mail this does not help increase the security and privacy of the web because all it does is allow the emergence of cerntralised Identity Services such as Facebook or Google+ that replace this feature with a distributed authentication service allowing the centralised provider to track all that the user is doing. Now for server to server communication WebID-RSA poses no problems, just as it poses no problems to WebID-TLS that keygen and the x509 certificate mime types are removed from the browsers. But in the client side though the question to Andrei with WebID-RSA are: 1) How does the browser store the key? (I suppose in the browser local storage) 2) How does the browser use that key to authenticate to another domain, since SOP restrictions are in place? Also on the document I read: [[ One important advantage of WebID-RSA over WebID-TLS is that keys can be generated on the fly to sign and encrypt data. The way client certificate management is currently implemented in browsers, it does not offer the means to access keys inside certificates, for purposes other than authentication. ]] But given that there is no chrome support for WebID-RSA how does the user know that the JS is indeed signing what it tells the user it is signing? The JS has full access to the private key so can sign whatever it wants. The major security problem of same origin policy is that same origin policy is very broad and difficult to supervise. Any JS served by the origin needs to be verified and understood. This opens up a whole set of security problems for SoLiD concerning the upload of JS on the origin, which I don't think have been considered yet. Henry > > Anders > >> >> >>> >>> Anders >>> >>>> >>>> It’s currently implemented in gold [1], one of the SoLiD servers. >>>> >>>> —Andrei >>>> >>>> [0] https://github.com/linkeddata/SoLiD#webid-rsa >>>> [1] https://github.com/linkeddata/gold >>>> >>>>> On Jul 31, 2015, at 8:51 AM, Cory Sabol <cssabol@uncg.edu <mailto:cssabol@uncg.edu>> wrote: >>>>> >>>>> It would be interesting to conduct some work on that. WebID with some alternative crypto APIs. >>>>> >>>>> On Fri, Jul 31, 2015 at 6:42 AM, Andreas Kuckartz <a.kuckartz@ping.de <mailto:a.kuckartz@ping.de>> wrote: >>>>> >>>>> Kingsley Idehen wrote: >>>>> > Keygen doesn't define existence of WebID-TLS. It just offered a >>>>> > perceived convenience. >>>>> >>>>> Can WebID-TLS be based on the Web Cryptography API instead? >>>>> >>>>> What would be the advantages and disadvantages? >>>>> >>>>> Cheers, >>>>> Andreas >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> -Cory Sabol >>>>> cssabol@uncg.edu <mailto:cssabol@uncg.edu> >>>>> >>>> >>> >>> >> >
Received on Tuesday, 4 August 2015 09:19:00 UTC