Re: Call for Adoption: draft-richanna-http-message-signatures

[Henry Story <[e-mail]>]

Dear editors,

> On 9 Jan 2020, at 05:33, Mark Nottingham <[e-mail]> wrote:
> 
> To that end, this is a Call for Adoption of draft-richanna-http-message-signatures-00. Since there hasn't been extensive discussion yet, we're looking for more confirmation than just absence of objection; we'd like folks to read the document and state explicitly whether they support it as a starting point for a work item.

I support the call for adoption.

I have been active in the decentralised authentication space for
over 10 years. I came to this around 2008 by noticing that one could retrofit TLS Client certificates with a decentralised identity system
initially called foaf+ssl [-1] and later called WebID-TLS [0], to help
build secure decentralized social networks. 

It always was clear that TLS client certificates were not perfect
but the hope was that the TLS community would over time be able 
to improve the client certificate authentication. 

https://www.w3.org/2005/Incubator/webid/spec/tls/

These communities had other priorities. 

Furthermore the problem with client TLS certificates are numerous:
 * they don’t fit well with HTTP/2.0 and break the layering
 * the certificates are in ASN.1, an old pre-web format
 * for the uses of decentralised hyper-apps that need to
 fetch data from many different servers, this posed the risk
 of users being overwhelmed with certificate requests
 (Though this could have been solved by allowing users to
  set policies)
 * …

5 years ago with the JS-Crypto API having gained traction
and having become aware of draft-cavage-http-signatures-05
I implemented it in the prototype Solid server [1]
and wrote a client library that could save the keys
to local storage and authenticate by passing a WebID URL in
the keyId [2] field. The logic is very similar to WebID-TLS 
and just as simple but it fits much better the HTTP-2.0
architecture.

I wrote up a first sketch of a draft of such an authentication
protocol in September 2019, 

https://github.com/solid/authentication-panel/blob/master/HttpSignature.md

Because the client UI is not integrated into the browsers as with TLS,
a lot of the functionality will need to developed as libraries. One 
thing that will be needed is what I initially called a LauncherApp but
that can be thought of as a KeyChain, that could control the credentials 
and keys for all the users apps [3].

I have been less active in the past 3 years programming as I 
somehow ended up doing a PhD on all of this with the aim of 
developing a security logic to ground this.

If you are interested you can see my second year report here
http://co-operating.systems/2019/04/01/PhD_second_year_report.pdf

In summary my early experience with HTTP-Signature was very good.
It is simple and flexible and seems to be a good candidate for a
decentralised authentication framework.

Henry

If I had a suggestion it would be to consider allowing the keyId
field to be a URI, either relative (one could think of it being that
now) or absolute.


[-1] https://bblfish.net/tmp/2009/05/spot2009_submission_15.pdf
[0] https://www.w3.org/2005/Incubator/webid/spec/tls/
[1] https://github.com/read-write-web/rww-play/blob/dev/app/rww/auth/HttpAuthentication.scala
[2] https://github.com/read-write-web/rww-scala-js/blob/akka.js/src/main/scala/rww/store/KeyStore.scala
[3] https://github.com/solid/authorization-and-access-control-panel/blob/master/Proposals/LauncherApp.md