The second case (rogue hubs) is already dealt with using signed requests from the Hub - see the specification section 7.4. Yes, it does mean handling secret keys, but the entire system already requires the management of subscription data anyway.
The main case, that of the hub authenticating itself to the publisher is outside the scope of the spec, and for good reason. It's hard to specify one single solution when in the wild there are so many. In that case though, you only have a single authentication round with the Hub. So outside of implementing/running your own controller Hub, there's not a lot of options. If I did have the scope to run my own Hub and apply custom changes to it, I'd probably go with an OAuth style system, but you could very easily drive that down to something simpler especially if the Hub ran locally. So, at the end of the day, the Publisher->Hub interaction is the tricky part. In the short term, I expect most will follow the strategy you outline though. Paddy Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com OpenID Europe Foundation Irish Representative ________________________________ From: Sachin Shenoy <[email protected]> To: [email protected] Sent: Thu, October 8, 2009 10:02:23 AM Subject: [pubsubhubbub] How to extend PSHB for authenticated content. Hi, We have an authenticated content that is presently being polled by our clients in order to get updates. We would like to move to a pubsub based model, and was looking at the feasibility of extending PSHB to support that. Has anyone thought of this in PSHB, or have experience using any other system? My initial thoughts were to use PSHB as a pinging service, by which a subscriber will come to know when a new content is available. The content itself will be directly fetched by the subscriber from the publisher, instead of from an intermediate hub. The reason for this is, the hubs won't have authentication required for fetching the content, and the subscriber might not want to give its authentication credentials to an intermediate hub (for privacy sake). The above scheme avoids polling. But during fetch phase all the load hits the publisher rather than being distributed across the PSHB network. This opens an DDoS attack opportunity for "rogue" hubs. A compromised or rogue hub could send out false update pings, causing all downstream subscribers to issue a fetch request to the publisher. To avoid this each update ping from a hub will have to be authenticated (by signature) by the subscriber before accepting it as a valid ping. For signing we could use shared secret and a secure hash function, but this approach soon runs into some trouble with the shared secret management. Easier might be to use PGP styled signing to authenticate the source of the update as the publisher. Any inputs? Is there any other/simpler way to do this? Regards, Sachin
