On Tue, Nov 22, 2011 at 4:52 PM, Jay Rossiter <[email protected]> wrote: > I've never, personally, seen the benefit in adding the > content-specific validation to PuSH. Imagine that the "arbitrary content" that I am pushing is an "offer-to-buy" or an "offer-to-sell." (i.e. It is a message whose authenticity is critical to its utility.) You are likely to want to have some reason to believe that I did, in fact, publish these offers. Certainly, it is interesting for you to believe that the hub that sent you these offers is, in fact, the one that you expected, however, you can't really be sure what the chain of delivery was prior to the hub and thus you can't be sure that the offers weren't tampered with prior to being processed by the hub that you trust (Garbage in, Garbage out.). Yes, you could "validate" the authenticity of the offers by actually tracking down the source feeds and reading the data from the original. But, then you'd be using PuSH as a notification service rather than a content delivery service. You would also be requiring me to maintain my feeds on an open, connected server and, because you're using PuSH as a notification service, you would be part of creating precisely the "thundering herd" problem that PuSH is designed to eliminate. An added advantage of having the content signed, rather than just the session link, is that you can then store the data in a form that can easily be validated or re-validated at a later date and you would be able to re-syndicate the data without anyone needing to fear that you had tampered with it.
bob wyman On Tue, Nov 22, 2011 at 4:52 PM, Jay Rossiter <[email protected]> wrote: > > 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 >
