Awesome! On Wednesday, January 13, 2010, Monica Keller <[email protected]> wrote: > Hi Guys > Thanks for your help and feedback. > Nikita has documented a proposal for a very lightweight extension to > this spec after reading your comments and discussing with Brett. > > Succint explanation is here: > http://code.google.com/p/pubsubhubbub/wiki/PSHBAndOAuth > > In our case we care about the subscribers having signed our TOS so > this is how we plan on verifying and we dont have usernames and > passwords, we have consumer keys and secrets so the master plan is to > simply oauth sign the topic url > > Aka instead of > http://www.myspace.com/ciberch/stream/atom.xml > > The subscriber would request topic > http://www.myspace.com/ciberch/stream/atom.xml?oauth_token=ad180jjd733klru7&oauth_signature_method=HMAC-SHA1&oauth_signature=wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D&oauth_timestamp=137131200&oauth_nonce=4572616e48616d6d65724c61686176&oauth_version=1.0 > > I wonder if the initial link rel hub should be modified as well to > specify that oauth signing is required > > > On Dec 14 2009, 3:04 am, Paul Kinlan <[email protected]> wrote: >> 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]]- Hide quoted text - >> >> - Show quoted text - >
-- -- John Panzer / Google [email protected] / abstractioneer.org / @jpanzer
