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
