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

[Orie Steele <[e-mail]>]

First time contributing like this, worry if replying like this breaks the
counting mechanism, it seemed nicer than hitting the mailing list
directly...

I done enterprise software development since 2008, including SOA, SOAP,
WSDL, and the newer stuff like Blockchain, GraphQL, Smart Contracts, and
Linked Data Signatures, etc...

I have used HTTP Signatures to configure Oracle Cloud resources
programmatically:

-
https://docs.cloud.oracle.com/iaas/Content/API/Concepts/signingrequests.htm

As well as Authorization Capabilities for Encrypted Data Vaults:

- https://w3c-ccg.github.io/zcap-ld/

Here is a link to the blog post and demo which uses HTTP Signatures from
the client web browser to the edv server (as well as DIDs):
https://medium.com/transmute-techtalk/encrypted-data-vaults-c794055b170e

I have also used HTTP Signatures to implement integrations between DIDs and
activity pub, though those were all tech spikes (unpublished), it was based
on this blog post:
https://hacks.mozilla.org/2018/11/decentralizing-social-interactions-with-activitypub/

My experience with HTTP Signatures has been good.

I'm mostly interested in contributing to defining how HTTP Signatures can
be used with Decentralized Identifiers and Verifiable Credentials, as we
already have implementations of these integrations which we are seeking to
strengthen through contribution to a robust standards development process.

Regards,

OS

ᐧ

On Mon, Jan 20, 2020 at 4:06 PM Henry Story <[e-mail]> wrote:

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


-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>