W3C home > Mailing lists > Public > public-credentials@w3.org > April 2018

Re: Signing HTTP Messages: Adding an optional username/principal to the signature

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Thu, 12 Apr 2018 11:51:23 -0400
To: public-credentials@w3.org
Message-ID: <7a045b3c-ae13-4bda-4e24-ce40973297fe@digitalbazaar.com>
On 04/11/2018 08:26 AM, Graham Leggett wrote:
> I am looking for an RFC compliant way of doing this so I can use SSL 
> on this back channel between reverse proxy and server, and have
> found 
> https://tools.ietf.org/html/draft-cavage-http-signatures-09#ref-3.

Hi Graham, I've been the editor of that IETF spec since it's inception.
Happy to answer any questions you may have about it here... more below.

> The missing piece however is that while a request can be signed, it 
> doesn’t seem possible to pass a username/principal along with this 
> request.

Can you express the username/principal in any HTTP Header? If so, you
will be able to support your use case.

Can you express the username/principle using a URI? If so, you can
express this in keyId.

> Sure, this could be hacked by coming up with some non standard way
> of passing the principal in a non standard header, but ideally I’d
> like a module for Apache httpd to be able to sign the reverse
> proxied request and insert the optional principal if necessary, and
> have a filter in tomcat to verify the signatures and optional pass on
> the principal to the calling application, and have this “just work”,
> like AJP does today.
> 
> Is this something that has been considered for Signing HTTP 
> Messages?

Yes, it's been considered and implemented in a variety of ways depending
on the use case.

Can you provide the exact information you want to sign? That would help
to understand your use case in a bit more depth.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches
Received on Thursday, 12 April 2018 15:51:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:26 UTC