> > HTTP headers are global to the entire message being transmitted. So, if > the message body is aggregated from multiple sources, each of which signed > their originals, how would you match signatures in the header to > subcomponents of the message in a format-independent manner? Or, do you > simply say that aggregation isn't supported?
My immediate thought is to use multipart messages. But maybe that's not as easy to work with. > A hub may wish to sign a message that was signed by its publisher. This > message might then be sent to another hub that also wanted to sign it, > etc... In this case, if the signatures are in the header, who signs what > and how do you keep the signatures distinguished from each other? > Yeah, this is what Salmon and Magic Signatures were designed for, right? My initial reaction is that we should probably rethink the need for hub federation. Maybe Julien can comment, but I don't think it's actually that useful in practice. That said, as a consumer, I can only imagine caring about the hub I subscribed to and maybe the content publisher. But that brings up an interesting point: hub and publisher signatures are not really the same. The publisher is not making HTTP requests, they are providing content. So they would sign at the content level (if at all, it's an edge case right now). The Hub is making HTTP requests, so signing at the HTTP level via Headers makes sense (and doesn't pollute the content). -jeff > > bob wyman > > > On Sun, Nov 20, 2011 at 6:20 PM, Jeff Lindsay <[email protected]> wrote: > >> Alternatively, many people implementing webhooks (PSHB being one example) >> use an HTTP header for signing. So far everybody does it differently. I >> like Magic Signatures, I also like the loosely inspired JWT, but I feel >> like something that lives in the headers is the Right Way to do this. >> >> There is a very rough draft for something that could solve this problem: >> http://tools.ietf.org/html/draft-burke-content-signature-00 >> >> I've been recommending it to people looking at signing their webhook >> payloads. It's not exactly usable yet, but I think it's a good thing to >> think about. Perhaps we can borrow semantics from Magic Signature and put >> them into Content Signature? >> >> -jeff >> >> >> On Sun, Nov 20, 2011 at 1:56 PM, Bob Wyman <[email protected]> wrote: >> >>> Julien suggests that a new mechanism is required to provide secure >>> notification when sending arbitrary content. >>> One useful and simple approach to this problem is provided by the "Magic >>> Signature"<http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-01.html>method >>> of the Salmon >>> Protocol <http://www.salmon-protocol.org/>. >>> If one assumes that the primary concerns for security involve ensuring >>> that data tampering and authorship can be detected, the Magic Signature >>> approach should do the job well. It would not, however, be suitable if the >>> intent is to publish "secret" data. >>> >>> See: >>> http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-01.html >>> >>> bob wyman >>> >>> >> >> >> -- >> Jeff Lindsay >> http://progrium.com >> > > -- Jeff Lindsay http://progrium.com
