Hey Brett, Indeed one of the major requirements for my proposal was to be able to use PubSubHubbub for APIs. With the experience coming from real time at MySpace and Facebook and I believe it also made sense for the Buzz team as well. I think that telling Service Providers that they can keep their response format will really help with adoption as seen with what GitHub Concerns for Option1 here http://code.google.com/p/pubsubhubbub/wiki/ArbitraryContentTypes were -Signing of headers which HTTPS would help with -Putting burden on subscribers to handle the different HTTP methods (DELETE, PUT) -- Not a huge concern
Would we know be asking all subscribers to have SSL certs ? That is a fairly big requirement. OAuth 2 burdens the service providers with this so I have concers about burdening the subscribers with it. My other question would be whether web hooks is a better fit today for APIs since there really isn't a need for a hub to fan out. As much as I love PubSubHubbub I think we should answer the question of how many service providers would want to push their response to another hub. MySpace and FB didn't really need an external hub. At Socialcast its the same thing we are going to add PuSH but its a private response for which you need to authenticate My experience leads me to believe there is a serious need to support a publisher who is its own hub. On Wed, Oct 6, 2010 at 11:32 PM, Brett Slatkin <[email protected]> wrote: > Hey all, > > Today one of the GitHub guys released a new Node.js library for PuSH. > His call for JSON support in the protocol is clear: > > http://techno-weenie.net/2010/10/5/nub-nub/ > > We've been wanting to add JSON support for quite a while, with notable > contributions from Mart > (http://martin.atkins.me.uk/specs/pubsubhubbub-json) and others. A > while ago Monica wrote up this proposal about how to support arbitrary > content types in PubSubHubbub: > > http://code.google.com/p/pubsubhubbub/wiki/ArbitraryContentTypes > > I worry about option 2, translation to JSON, because I think it > dictates what format the JSON payload needs to be in when served by > publishers. A big benefit of JSON is making things easier to use and > more ad hoc. Dictating the packaging format would harm that. I also > don't see Facebook changing their JSON API > (http://developers.facebook.com/docs/api/realtime) to match and they > shouldn't have to. > > The core issue with option 1, the REST approach, is security (replay > attacks). But I believe I've finally cracked the nut! > > > To explain: Feeds are good formats because they are self describing. > Update times and IDs are part of the feed body and individual entries, > enabling idempotent synchronization and race-condition tie-breaks. > This also means the 'X-Hub-Signature' on the body of PuSH new content > notifications is sufficient for security/verification because we can > ignore everything besides the body (the other headers are ignored). > > With the REST approach to arbitrary content types, we *need* to > represent the HTTP headers in the new content notifications or else > we'll have no idea what order the messages came in (Date), etc. And > that's the security problem. If we rely on the headers, then we also > need to verify them (to prevent replay attacks). But X-Hub-Signature > only signs the body, so we're stuck. Some folks have discussed signing > headers too, similar to OAuth1.0, but that lead to a lot of pain > nobody wants to repeat. Others have talked about putting headers into > the body (using mime multipart), but that's just another world of > hurt-- the so-called Turduckin problem (thanks jsmarr for the name). > > > The solution is to borrow from the OAuth2 playbook: Treat the > X-Hub-Signature like a password/bearer token and require HTTPS for > callbacks. That means for security we have these components: > > 1. hub.secret used by subscriber to verify the hub is authorized to > post content (after delivery) > 2. Subscriber's SSL cert used by Hub to verify authenticity of > subscriber endpoint (before delivery) > 3. SSL connection between Hub and Subscriber is encrypted, protecting > the header values and preventing replay attacks (during delivery) > > Thus, Monica's proposal as-is does the trick. All that's left to work > out are details around verbs and Link headers. I hope to bring > everyone back together to build out a spec around this proposal now > that I think the security issue has been solved. Hopefully we can > convince GitHub to be the first implementors of it. > > Let me know what you think! > > -Brett >
