Detailing HTTP-Signature based authentication for Solid

[bblfish]

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:

1. A definititon of a Web-Key: a URL that names a public key, that can be either
   a) located in the WebID doc
   b) located elsewhere in case there is a desire to not tie a key to a webid.
2. A verification procedure where the server fetches the public WebKey to check the client
   a) if the wACL identifies that Agent via that WebKey that that is all that is needed
   b) if the wACL identifies the Agent via a WebID then the client needs to send the WebId in the request. If the situation is 1a above, then that is all that is needed. If 1b above then there needs to be a proof tying the WebId to the WebKey.

[bblfish]

This HTTP Signature protocol for WebID proposal was discussed:

• 11 Sept 2019 at App Authorization panel with @elf-pavlik and @zenomt. notes left on hackmd.io. Will try to distill some of the thoughts here.
• 16 Sept 2019 at the end of the meeting, with notes left on hackmd.io

[dmitrizagidulin]

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).

[bblfish]

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?

[bblfish]

Here is a way to make it possible for apps to sign HTTP headers without ever having access to private keys.

1. We can give the user pod 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.
2. the WebID Profile can link to this authorization app perhaps with something like

   <#me> :authenticationApp </safe/authentication.html> . //which contains the JS.

3. An App from app.net could then on finding out the WebID of the user find the authenticationApp page, open that in a new frame.
4. Using Window.postMessage, 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.

[bblfish]

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.

[elf-pavlik]

@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.