- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Thu, 12 Apr 2018 11:51:23 -0400
- To: public-credentials@w3.org
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