HttpSig

[bblfish]

Extending the HTTP-Sig authentication IETF HTTPbis work to take into account WebIDs and the Self Sovereign Identity ecosystem with Verifiable Credentials and support for DIDs.

The text is a bit longer than essentially needed in order to help people who are new to Solid understand our use case.

In short it adds the following:

• a WWW-Authenticate: HttpSig method for the server to let the client know it understands HttpSig method of authentication
• An extension of the response to:
  • allow keyIds to be URIs: absolute URIs (https or DIDs) or two types of relative URIs: one linking to the server, and one linking to a document on the client
  • allow a Credential or WebID link to be passed in the response header with the header

A credential can be pointed to by the client passing a cred attribute to the Authorization header like this: Authorization: HttpSig cred="<https://alice.freedom/cred/BAEng>"

Again the URI for the credential can be a https URL, a relative URL pointing to the server or to the client using the P2P extension to HTTP.

A major advantage is that it ties in nicely with the Self Sovereign Identity philosophy of putting the authenticating user at the center of authentication decisions.

It also has a major technical advantage in that optimally it can allow authentication over a single connection, when using the P2P extension to HTTP.

[acoburn]

The protocol allows a client to authenticate by signing any of several HTTP headers with any one of its private keys

How does a client manage these private keys? Presumably the key pairs are not ephemeral (as is the case with DPoP), since the public portion is persisted in a WebID document. Is this protocol principally aimed at clients that are able to securely manage private keys, such as native clients, clients embedded in server-side apps and CLI utilities?

[bblfish]

The way I implemented that 5 years ago in rww-scala-js (see akka-http-signature) was to place the keys in the browser's local storage with the JS Crypto API. Now I guess one can build a Universal Wallet that way, or it could be built into the browser or as a plugin...

The Launcher App I suggested a few years ago is what the Self-Sovereign Identity folks think of as a Universal Wallet + Agent + a way to Confine JS Apps. There are quite a number of Wallets out there, so one should look at how they do things.

Apps that could not do this could go through a proxy on the server to fetch data. I guess android apps may have access to many more security features.

[acoburn]

place the keys in the browser's local storage with the JS Crypto API

One should never place sensitive data in local storage. Negotiating a key exchange with an external server would be moderately better, but you're still then passing keys over an HTTP connection, hoping that the user is using a modern TLS connection and that all the intermediaries are trusted.

[acoburn]

Passing around ephemeral keys over HTTP would be one thing, but I'd be concerned about doing this for long-lived private keys

[bblfish]

One should never place sensitive data in local storage.

The Web Crypto API allows you to save the keys in local storage in an encrypted manner that can only be accessed by JS from the origin that created the key. If you have a problem with the security of it, then we should talk to the Security team that oversaw those specs and the vendors that implemented those in each browser.

I guess whatever issues you have with it now, we will end up with some form of Wallet built into the Browser. We just need to start with something. With the experience gained we can then make a report of needed improvements in the browser, phones, and elsewhere.

[acoburn]

I am very familiar with the Web Crypto API; I use it extensively. The issue here is different and it relates to two particular items:

1. If you are relying on a private key stored in local storage, then any javascript running on that origin can tamper with it or delete it. If that is the key that is used to access your Pod data, now you have no access to that data. Session storage is worse because when the browser is restarted, your key is gone.

2. Assuming that the private key is encrypted, how do you decrypt that key so that it can be used to sign messages? Presumably, you need another private key gotten from somewhere else. Because these keys ultimately point to a public key stored in your WebID document, these can't be ephemeral keys. So again, you're passing long-lived private keys around over HTTP.

I like the idea of message signatures, and it provides some interesting features around tamper-proof messages, but I still need to be convinced that using this for authentication is going to be secure.

[bblfish]

Now we are discussing one particular implementation idea. You found a problem for that, I gave an answer, you can find a problem to that answer and so on for a long time, given that security is subtle, and in many ways non-monotonic, depending hugely on the context (Does striking a match cause it to burn? Usually. Unless the match is wet. If the match is not wet, but it is in a room with no air then it won't, etc. etc..).

And there are many other ways of dealing with this. Another is as I said you build a plugin. One could also have HTTP calls all go through some form of Proxy on your Pod that holds all the keys that does the authentication.

So we need to keep our eye on the architecture: given a secure Wallet on the client, which is where a wallet belongs and good crypto on the device, what is the most efficient way of authenticating, compatible with Solid hyper-Apps? I believe that you can't get more efficient than this HttpSig proposal.

[acoburn]

Let's focus on architecture: this proposal is based on the fact that clients are able to manage private keys securely -- make that clear in the proposal. And make it clear how a client would actually do that in various contexts. If the answer is: "build a plugin", then be clear that this won't work for pure javascript, browser based Solid apps.

A strong proposal will include both a robust, generalizable design and at least one working implementation that demonstrates how the security issues can be addressed.

[bblfish]

If the answer is: "build a plugin", then be clear that this won't work for pure javascript, browser based Solid apps.

I think the contrary is true. A well-designed Wallet plugin would take care of the difficult parts of managing Credentials. That is what the Web Monetization folks are doing. Actually we have a number of groups here funded by the Grant for the Web foundation. These are listed in the WebMonetization Solid repo, so perhaps we can get their input on how this is done. Also we will have a meeting with the Credentials Community Group March 10, 2021, so that would be a good time to ask them too.

I will add an issue to look at the various ways the protocol can be implemented: on the client (JS crypto, plugin, OS features), on the server as a proxy, etc... There are too many angles for that to be developed in this protocol description. That should lead to a different set of documents.

[bblfish]

I have added an Executive Summary section