They're not specific in the way that signing for JPEG is somehow different than signing for PDF, but they are specific to XML or JSON, as you've just stated. You can't just send an arbitrary file and have it be "signed" unless it is encapsulated in another format.
I do agree with Martin that there are two separate things being discussed, however. One is content validation, and one is source validation. I've never, personally, seen the benefit in adding the content-specific validation to PuSH. It's really an external issue. Validation that the content actually originated from the correct hub is important, because it's possible for endpoints to be leaked and abused without it. On Nov 22, 12:51 pm, Bob Wyman <[email protected]> wrote: > On Tue, Nov 22, 2011 at 10:47 AM, Martin Atkins > <[email protected]>wrote: > > On 11/20/2011 03:36 PM, Bob Wyman wrote: > > >> 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? > > >> 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? > > > I think two separate needs are being discussed here: > > > * A subscriber needs a way to determine whether an incoming push > > notification did indeed come from the expected hub. In this case it is the > > entire message -- possibly *including* the HTTP headers? -- that needs to > > be authenticated. > > > * A publisher is re-publishing something from another source and the > > subscriber needs a way to verify that it did indeed come from the other > > source. In this case it is the higher-layer messages that need > > authenticating, and Salmon Magic Signatures seems like a fine way to do > > that but that seems out of scope of PubSubHubbub since it's specific to the > > data format being transmitted. > > Salmon Magic Signatures are not, in fact, "specific to the data format > being transmitted." Both an XML and JSON encoding for the signatures is > provided, however, the format of the signed payload is not defined by the > Magic Signature Specification. Anything that can be base64url encoded can > be the signed payload of a magic signature. > > bob wyman
