Hello Gratzi, The mechanism you described for notification is actually not perfectly accurate. The data is delivered via the callback and it is usually recommended that the subscriber does not go fetch the resource itself, to avoid overloading (thundering herd!) of the publisher. Additionally, caching mechanisms may actually prevent that. This is valid for versions of the spec pre 0.4. On other words, all current implementations do that already.
As for signed content, we always love to see some new ideas! I believe all hubs to currently support the authenticated content delivery. Thanks, On Fri, Sep 7, 2012 at 8:40 AM, rektide <[email protected]> wrote: > Hiya PuSHers: > > It's been a long time since I've checked out PuSH; last time I looked, to > my recall, the > spec was dominantly about sending a notification of reource change that > left the subscriber > to go check the content for themselves. It seems some stuff has changed! I > am, atm, mainly > focusing on the 0.4 spec, and I'd love to some help. > > What kinds of (7) content distribution are in the field these days? I'd > love some usages, as > current I just don't know what gets pushed out! As I say, last I > checked/to my recall PuSH > was just about notifying of a change event, so I really don't know what to > expect here. > > Second, (8) Authenticated Content Distribution seems to be a stand-alone > mini-spec for > authentication. Are there any content distribution mechanisms people have > seen out there > that use alternate authentication mechanisms? I don't see any reason why > PuSH ought > re-invent it's own authentication standards here: surely content could > authenticate itself > via a JSON Web Signature, or Salmon Protocol, MAC Access Authentication or > another means? > Again, has anyone seen alternately authenticated syndication via PuSH > content distribution? > > My biggest fear with (8)'s implementation is that it has to resign the > content for each > distribution endpoint, for each subscriber: the signing and verification > process is > mercifully wonderfully simple compared to the other authenticated content > standards I've run > across, but this simplification seems to be at the cost and weakness of > binding to a shared > secret the subscriber sends. Would love to see a PuSH implementation that > makes different > tradeoffs: does A) that make sense, B) exist anywhere out there already? > > Last, I just want to re-emphasize that I've been away: there's been > X-Hub-Secret/hub.secret > for as long as I can remember, but I'm still under the idea that we've > started actually > sending content in the callback, which is new to me, and might perhaps > make SHA1 signing > computationally expensive if the payload is non-trivial. > > Gratzi, > @rektide >
