Closed bblfish closed 4 years ago
This HTTP Signature protocol for WebID proposal was discussed:
One of the things that's worth noting, about any sort fo HTTP-Sig based proposals, is that it's currently used almost exclusively for secure clients (meaning, traditional server-side applications) and for server-to-server authentication. By itself, it is not appropriate for authentication of public clients (SPA / in-browser Javascript apps).
I wanted to make sure we are all on the same page with regard to the limitation of the HTTP-Sig protocol.
The illustration below depicts a client laptop running an app with Origin app.net
and authenticating on friend.net
, with public key published on the user's pod me.me
.
The argument is the following: since friend.net cannot tell if the authentication is coming from the client laptop, or from app.net
or from anyone app.net
may have given the private key to, all it can tell is that app.net
is logging in as me.me
. It would not therefore feel secure in giving information out that was only meant for the eyes of the owner of the laptop.
Technically, this is because even though correct usage would allow the app
to make the private/public key pair using Web Crypto in a way that does not allow the client App
to even see the private key pair, it would also be possible for the app to make the key with it's own JS library, or even for the server at app.net
to make the key, or even potentially to make the private key in web crypto in a way that gives the JS access to the private key.
Is this the reason @dmitrizagidulin why you say HTTP-Sig is not appropriate for authentication of in browser clients?
Here is a way to make it possible for apps to sign HTTP headers without ever having access to private keys.
me.me
host an authentication JavaScript App. This App will be in charge of keeping keys using JS Crypto's generateKey securely in the end-user's browser, in a way that not even the App can access it. <#me> :authenticationApp </safe/authentication.html> . //which contains the JS.
app.net
could then on finding out the WebID of the user find the authenticationApp page, open that in a new frame.app.net
can communicate with the Authentication Window and request HTTP headers to be signed. One could also go the other way around, and register apps in one's authentication app, and have that open a browser window in which the app occurs.
Regarding the question as to what the problem with HTTP-Signature is felt to be @dmitrizagidulin answered on gitter that it had to do with the problem of the Confused Deputy, which is what is behind the emergence of Capability Systems, and that these arise when 3 or more agents are involved in a secure communication. Here we have the App as the extra agent. This may be resolvable by being able to identify the app.
I'll look into the confused deputy and capabilities vs ACL debate to which Dmitry provided ample pointers.
@bblfish given we have merged #20 I think we can close this issue and follow up with focused issues which can get addressed by focused PRs.
I think it would be useful to detail HTTP-Signatures based authentication for Solid. I wrote an implementation for it a few years ago for the server, and one before that for the client using Web-Crypto.
Not much is needed in addition to the existing spec. I can think of the following: