Re: WebID-RSA. Re: google proposing to deprecate KEYGEN

Imho. For a PC or TV The TLS/cert would be better if, on a client side, it
denotes group, being the machine account (which is the auth. Point for the
machine itself.). Equally, on a phone, it might denote the user.

IMHO server to server auth. Kinda important, even if the server is running
on a phone. Therein, the concept of dataspaces vs. machine auth to the
dataspace.

Perhaps therein are other considerations of localStorage, sync,
logout/flush.?

Tim.h.
On Wed, 5 Aug 2015 at 12:13 am, Andrei Sambra <andrei@w3.org> wrote:

>
> > On Aug 4, 2015, at 5:18 AM, Henry Story <henry.story@co-operating.systems>
> wrote:
> >
> >>
> >> 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)
>
> These are really important questions. Until W3C or FIDO come up with a
> standard API around accessing the secure element on smart cards, the
> solution is to use localStorage. There are several ways this can be done:
>
> a) Client-side apps use a shared library loaded from a secure origin,
> which acts like a keychain. This solution, however, involves centralizing
> the service into a handful of keychain providers (maybe).
>
> b) Users run their own keychain app on top of their LDP server, and link
> to the app from their WebID profiles. Then using an app for the first time
> simply involves disclosing the user’s WebID. (the app can then use
> localStorage to store the WebID value for subsequent usage)
>
>
> > 2) How does the browser use that key to authenticate to another domain,
> since SOP restrictions are in place?
>
> This is the million $$ question. My current answer is to have the app
> request a bearer token from the keychain app. Here is a tentative workflow,
> the user went through the a) and b) steps above:
>
> a) App requires authentication to access a protected resource on ServerA.
> (ServerA responded with a 401 and a nonce N)
> b) App requests a signature over N from keychain app, using cross-window
> messaging with postMessage [0].
> c) Keychain app signs N and passes it back to App using postMessage.
> d) App retries the request by sending the signed credential.
>
>
> There’s also an improvement that can be made to the workflow. For
> instance, the keychain app may display a message asking the user to
> validate the request for a signature coming from App. The keychain app
> should then cache these requests (both locally in localStorage and on the
> user’s LDP server for sync purposes across the user’s devices/browsers).
>
> —Andrei
>
> [0] https://w3c.github.io/webmessaging/
>
> >
> > 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>
>
>