The way we deal with this at superfeedr is using the "publisher callback". Basically, when anyone uses superfeedr as their hub, they can define a callback url on which subscription requests will be "proxied". The publisher can then decide to allow or refuse subscriptions. The publisher can also provide a message that will be sent back to the subscriber, asking for an API key, or any additional params. The hub also proxies these additional params to the publisher callback.
You can read more about this : http://blog.superfeedr.com/PubSubHubbub/Spec/Extension/publisher-callback-extension/ If you want to see it in actiion, for example try to subscribe to http://www.etsy.com/api/push/listings/latest.atom I will try to write this as a spec if some people wants it. I believe this wouldn't change the "default" behavior of the protocol, but is also rich enough to allow for several use cases. However, I'm not sure how "compatible" this is with the OAuth2.0 spec, which I would have to study more thoroughly... On Tue, Feb 1, 2011 at 4:06 PM, Glen Campbell <[email protected]> wrote: > I'm really interested in that, too. We had thought of putting some auth > restrictions on the hub to determine who could see which data. > > On Feb 1, 2011, at 9:00 AM, Andrea Messina <[email protected]> wrote: > > > Is there any attempt to evolve the current specs? > > Having a pubsubhubbub protocol which takes account of private feeds > > (in general non public information source) would be worth. Embedding > > OAuth behaviour or other authorization mechanisms could significantly > > improve the whole. >
