Proposed OAuth Support

[Nikita Kalashnikov]

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
[nkalas...@myspace-inc.com]

[Teemu Harju]

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 <nikita.kalashni...@gmail.com>
wrote:

> [nkalashni...@myspace-inc.com]

[Paul Kinlan]

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 <teemu...@gmail.com>

[Monica Keller]

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

> 2009/12/14 Teemu Harju <teemu.ha...@gmail.com>

> > > [nkalashni...@myspace-inc.com]- Hide quoted text -
>
> - Show quoted text -

[Nikita Kalashnikov]

I don't think it's the best idea to modify the topic URL. We could
indicate somehow that our hub requires OAuth, but it seems like it
would be more natural to indicate that in some other out of band way,
like feature documentation.

By the way at least in MySpace's case there wouldn't be a oauth token
since we are only interested in identifying the subscriber. A
subscription is not a user specific resource.

Nikita

On Jan 13, 1:48 pm, Monica Keller <monica.kel...@gmail.com> 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 ofhttp://www.myspace.com/ciberch/stream/atom.xml
>
> The subscriber would request topichttp://www.myspace.com/ciberch/stream/atom.xml?oauth_token=ad180jjd73...

[John Panzer]

Awesome!

--
--
John Panzer / Google
jpa...@google.com / abstractioneer.org / @jpanzer