Hi Nikita, I've been thinking about the OAuth support for PubSubHubbub from a bit different perspective than what you describe here. I see it very useful for the hub to get access to private feeds, but I assume you are talking here about the authenticated subscribing and content distribution here. I'm just wondering how the signing really goes in your proposed system? The subscriber has a consumer key/secret pair and its requests are signed using those. Does the hub sign its requests with the same key/secret pair?
In my opinion the authentication in PubSubHubbub should follow the standard HTTP authentication. That is, the server responds with 401 Unauthorized with a WWW-Authenticate header listing the available authentication methods. What you are using (if I've undesrstood it correctly) is not really OAuth though, but only the message signing part. Although, I cannot right now think of a better solution that would follow HTTP spec more closely. Nice to see that MySpace is using PubSubHubbub anyways. :) - Teemu On Dec 10, 12:29 am, Nikita Kalashnikov <[email protected]> wrote: > Hi, > > We are working on PSHB support here at MySpace. We have decided that > authenticating the caller is a key requirement for various legal > reasons, allowing us to hold clients to a terms of service agreement, > as well as allowing us to easily shut down malicious subscribers. > Obviously MySpace users' data is subject to a number of privacy rules, > which depend on who the subscriber is, among other factors. It's also > just useful for a number of other reasons, such as usage tracking. > > The method of authentication we are planning to use is OAuth, since > it's an open standard, and one we already use across the rest of our > APIs. > > Since MySpace is acting both as a hub and a publisher, communication > between the hub and and a set of publishers is not a problem we need > to solve. > > The implementation I have in mind, is a standard OAuth request, where > all parameters (including hub.* ones of course) are signed per OAuth. > > There are 5 ways in which I see this impacting the PSHB spec: > 1. The hub.verify parameter is set to "OAuth" > 2. The hub.verify_token parameter is redundant in this context, and is > ignored, if present > 3. Verification of the intent of the subscriber is redundant, and is > not done > 4. Automatic subscription refresh requests are signed using OAuth, all > PSHB specific parameters remain unchanged. > 5. Outgoing updates to the subscriber are signed using OAuth, and the > X-Hub-Signature header is omitted. In this case I wonder if it's > necessary to identify the signature method to the subscriber so that > he knows not to look for the X-Hub-Signature header and instead look > for OAuth parameters. Perhaps adding a hub.verify parameter with the > outgoing updates is something that could be changed as well. This > parameter may also need to be added to the automatic refresh request. > > We are forging forward with our implementation, and are quite close to > being ready to release this functionality. The only major roadblock at > this point is simply spec compliance. I'm very hopeful we can get some > general agreement over the correct way to do this very soon. > > Any and all thoughts very welcome. > > Nikita > [[email protected]]
