Hi, Bearing in mind, that my understanding of PubSubHubbub is that it is a server to server technology and OAuth is mainly a end-user mechanism to grant applications access to a users data. I don't see why plain old basic auth (or digest) wouldn't work so that you can authenticate and/or track subscribers.
I can see that you could sign your requests on the hub.* methods and not have a problem with the spec and you still get to ensure that the subscription request is authenticated, I don't see why the subscriber needs any sort of indication of oauth. It appears to me that you are looking to do a reverse oauth. I will comment inline with my thoughts 1. The hub.verify parameter is set to "OAuth" -- it should remain sync, aync, all subscribers should get a ping back to their chosen endpoint to confirm the hub has "got it". adding oauth in to the mix does nothing, because at no point would a subscriber know that they have subscribed, after all it my understanding that the verification phase returns no data (6.1.2). 2. The hub.verify_token parameter is redundant in this context, and is ignored, if present -- See above, the verify token is used on the clients endpoint so I think it is needed to ensure that the request coming from hubs are correct. 3. Verification of the intent of the subscriber is redundant, and is not done -- Why? 4. Automatic subscription refresh requests are signed using OAuth, all PSHB specific parameters remain unchanged. -- Sounds normal, as the client (subscriber) is calling the server (hub) 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. -- This was my point about reverse oauth. I honestly think that people won't bother with verifying the request because of the relative complexity of the solution. Regardless of that though, do you really need to indicate that you are using oauth, if all the request parameters are there clients can relatively easily detect that oauth is being used on the request. I also think that keeping the spec as is you can still have a hub.secret parameter AND still support OAuth. It appears to me, and I really don't mean any offence, is that parts of this implementation are significantly outside the spec and adds a lot more complexity to any potential client solution. I do have a feeling that oauth could be used without modifying any of the spec though. I personally don't see all the benefits of this over Superfeeds authenticated implementation ( http://superfeedr.com/documentation#pubsubhubbub). P 2009/12/14 Teemu Harju <[email protected]> > 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]] >
