Hello everyone, I've been following this PubSubHubbub thing for a while now and thought that it could be a good time finally to start contributing to this work since I find it very interesting. I've noticed that there has been some activity in the area of OAuth on this list before, but not too much activity on that lately. What I'm asking is that is someone already working on it and could I help somehow?
I've implemented a "hackish" OAuth support for the reference hub implementation and here are some of my ideas for commenting. Feel free to shoot them down. ;) 1) Hub acts as a consumer and holds a access token for every subscription i.e., topic + callback. Problem here is naturally how to get the required consumer information to the hub (consumer key+secret and the needed URLs). Maybe OAuth Discovery (http://oauth.net/ discovery/1.0) could help here. Or inserting the information manually to the hub (this is what I did). 2) Subscriptions would be created the same way as is now described in 0.2 spec. Maybe the verification process should be changed a bit so that the subscription is not verified until the hub has a valid access token for that subscription. When the hub for the first time processes the feed and gets back a 401 Unauthorized response it uses the Www- Authenticate header to see which authentication methods are supported. Unfortunately e.g., Twitter or Brightktite didn't seem to advertise OAuth support in the Www-Authenticate header (which kinda sucks big time). Anyways, in a perfect world the OAuth method should be in place. 3) Hub checks if it has the required consumer information for the service in question and fetches the unauthorized request token from the service. If it does not have the needed information it could use the OAuth Discovery here. However, I guess there are not that many services supporting it. Maybe there has not been a real need for it before. I would say that now there is. 4) The request token should be authorized by the subscriber. The hub generates the URL to which the subscriber should go to. We cannot really redirect the subscriber to the URL so the hub should send the URL to the callback URL of the subscription in question. Maybe a HTTP GET with query string arguments like hub.mode="authorize", hub.topic="http://topic.com/feed.xml";, hub.auth_method="oauth", hub.auth_realm="some realm", hub.oauth_authorize_url="http:// service.com?oauth_token=sometoken" etc... 5) The user authorizes the request token and the service provider redirects the request to the oauth callback URL on the hub and the hub exchanges the authorized request token to an access token. 6) Then the hub can fetch the private feed when it uses the access token. In this case there would not be need to authenticate the user to the hub anymore (which would make using the hub more difficult since user accounts would have to be created to the hub) since the subscription should not be made unless the hub has a valid access token. Maybe HTTPS should be used for the content distribution. Thoughts on this? :) Anyways, this should follow relatively well the design principles of PubSubHubbub. That is, keep the complexity in the hub. The subscription would work pretty much the same way as it is now. Also, it should be relatively well bootstrappable. Altghough, there are definitely issues in getting the consumer info to the hub. Br, Teemu
