pubsubhubbub evolution

[Andrea Messina]

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.

[Julien Genestoux]

Agreed!

[Charl van Niekerk]

I think a standardised way of pushing to consumers who are not
accessible directly (behind a NAT router/firewall/etc) would be awesome
at this stage.

[Julien Genestoux]

Charl,

I agree that this will have to come at some point too, but I think it would probably too different from the current PubSubHubbub spec, because it would probably not be able to sit on HTTP.

I think however that support for private resources and (in the spec!) any kind of resource would be a good first step.

Thanks,

[Charl van Niekerk]

On Tue, 2011-02-01 at 17:12 +0100, Julien Genestoux wrote:
> I agree that this will have to come at some point too, but I think it
> would probably too different from the current PubSubHubbub spec,
> because it would probably not be able to sit on HTTP.
> I think however that support for private resources and (in the spec!)
> any kind of resource would be a good first step.

Good point, maybe this should be a separate related standard altogether.
I'm thinking about something like the various mobile notification
implementations or even the PuSH bot.

[Glen Campbell]

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.

[Julien Genestoux]

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...

[John Panzer]

Check out this doc for ACL'd PubSubHubbub (a little old, but solid and still valid): https://docs.google.com/a/google.com/document/pub?id=1HrVmSCQM2r5bCnQk5uZPbhH0sGVHHFOGhxJ0thoKEO8

I've been doing a bit of coding work towards this here at Google w/Brett for Buzz as I have time.  It's fairly straightforward to do, and I encourage others to try it out on their sites as well.

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

[Darren Bounds]

Charlie and I put together a working flow that leverages his magic-sig
OAuth2 assertion flow combined with JRD (JSON XRD) and JSON Activity
Streams. It's very easily implemented and works quite well for our
usecase and I would assume most others. We've also been purposeful in
using JSON exclusively.

The flow is as follows:

1) Feed request with 200 or 401 response. Response includes
WWW-Authenticate and OAuth2-Discovery headers (OAuth2-Discovery
includes supported grant types and OAuth2 endpoints. See below).
2) OAuth2 assertion initiated with magicsig identity assertion.
Success results in a valid access token response. (See below for
details)
3) Access token is included in feed request as qs param and made
again. Response now includes the hub link.
3) PSHB subscription is initiated as per the spec with the topic URL
as included in step 3. (e.g.
http://ooava.com/dbounds?format=json&oauth_token=12345)
4) During subscription verification the oauth_token included in the
topic is verified and used to validate the response.

Working PoC here:

http://ooava.com/dbounds (profile page)
http://ooava.com/dbounds?format=json (protected JSON AS feed)
http://ooava.com/.well-known/host-meta?format=json (host-meta JRD)
http://ooava.com/etc/webfinger?format=json&q=acct:dbo...@ooava.com
(webfinger JRD)

One interesting aspect what we've introduced here is the
OAuth2-Discovery header in the protected feed response. The value is a
JSON resource specifying the supported grant types and associated
OAuth2 resource endpoints.

Example:

GET /dbounds?format=json HTTP/1.1
Host: ooava.com

HTTP/1.1 200 OK
Date: Tue, 01 Feb 2011 20:21:10 GMT
WWW-Authenticate: OAuth2
OAuth2-Discovery:
{"grant_types":["urn:magic-sig:identity:assertion"],"token_endpoint":"http://ooava.com/api/v1/oauth/server/access_token"}
Content-Type: application/stream+json
Content-Length: 0

MagicSig Assertion:

We use the OAuth2 Assertion flow to post an assertion with a
grant-type of: urn:magic-sig:identity:assertion

The assertion is a Magic Envelope in the Compact Serialization form
with a payload of the JSON structure below. With a data-type of
"application/magic-identity-assertion+json"
{
identity_uri:"acct:cha...@reticulateme.appspot.com",
create_date:"Jan 17, 2011 11:48:36 PM",
destination_url:"http://ooava.com/api/v1/oauth/server/access_token"
}

So basically we are signing the uri, the date, and the URL we are
posting to (follow the same URL normalization rules as Oauth signing).

The receiver can validate by following the process in the magic-sig
spec. http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-01.html

--

Thank you,
Darren Bounds

[Andrea Messina]

"During subscription verification the oauth_token included in the
topic is verified and used to validate the response. "

So, the hub checks if the token provided in the subscription_request
matches that sent before in the OAuth2 assertion?
What about when you say: ...and used to validate the response??..


I have noticed that the endpoint is not protected.....but OAuth2
requires TLS protected ones.

According to which conditions, are you issuing access tokens?? I
suppose, that, in your case, it is sufficient to validate the
salmon(assertion).
In principle, you could automatically ACL'ed the identity_uri.
I wonder, what kind of flow, you would use, to personally check the
request and approve it asynchronously. How would you send the access
token??
In my opinion you could send it, to some kind of callback indicated in
the assertion, maybe ciphered with the recipient publick key(XRD
discovery). WHat's your opinion?

thanks a lot.

On Feb 1, 9:42 pm, Darren Bounds <dbou...@gmail.com> wrote:
> Charlie and I put together a working flow that leverages his magic-sig
> OAuth2 assertion flow combined with JRD (JSON XRD) and JSON Activity
> Streams. It's very easily implemented and works quite well for our
> usecase and I would assume most others. We've also been purposeful in
> using JSON exclusively.
>
> The flow is as follows:
>
> 1) Feed request with 200 or 401 response. Response includes
> WWW-Authenticate and OAuth2-Discovery headers (OAuth2-Discovery
> includes supported grant types and OAuth2 endpoints. See below).
> 2) OAuth2 assertion initiated with magicsig identity assertion.
> Success results in a valid access token response. (See below for
> details)
> 3) Access token is included in feed request as qs param and made
> again. Response now includes the hub link.
> 3) PSHB subscription is initiated as per the spec with the topic URL

> as included in step 3. (e.g.http://ooava.com/dbounds?format=json&oauth_token=12345)

> 4) During subscription verification the oauth_token included in the
> topic is verified and used to validate the response.
>
> Working PoC here:
>
> http://ooava.com/dbounds(profile page)http://ooava.com/dbounds?format=json(protected JSON AS feed)http://ooava.com/.well-known/host-meta?format=json(host-meta JRD)

> http://ooava.com/etc/webfinger?format=json&q=acct:dbou...@ooava.com

> (webfinger JRD)
>
> One interesting aspect what we've introduced here is the
> OAuth2-Discovery header in the protected feed response. The value is a
> JSON resource specifying the supported grant types and associated
> OAuth2 resource endpoints.
>
> Example:
>
> GET /dbounds?format=json HTTP/1.1
> Host: ooava.com
>
> HTTP/1.1 200 OK
> Date: Tue, 01 Feb 2011 20:21:10 GMT
> WWW-Authenticate: OAuth2
> OAuth2-Discovery:
> {"grant_types":["urn:magic-sig:identity:assertion"],"token_endpoint":"http://ooava.com/api/v1/oauth/server/access_token"}
> Content-Type: application/stream+json
> Content-Length: 0
>
> MagicSig Assertion:
>
> We use the OAuth2 Assertion flow to post an assertion with a
> grant-type of: urn:magic-sig:identity:assertion
>
> The assertion is a Magic Envelope in the Compact Serialization form
> with a payload of the JSON structure below.  With a data-type of
> "application/magic-identity-assertion+json"
> {

>    identity_uri:"acct:char...@reticulateme.appspot.com",

>    create_date:"Jan 17, 2011 11:48:36 PM",
>    destination_url:"http://ooava.com/api/v1/oauth/server/access_token"
>
> }
>
> So basically we are signing the uri, the date, and the URL we are
> posting to (follow the same URL normalization rules as Oauth signing).
>
> The receiver can validate by following the process in the magic-sig

> spec.http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig...

>
>
>
>
>
>
>
>
>
> On Tue, Feb 1, 2011 at 2:54 PM, John Panzer <jpan...@google.com> wrote:
> > Check out this doc for ACL'd PubSubHubbub (a little old, but solid and still

> > valid): https://docs.google.com/a/google.com/document/pub?id=1HrVmSCQM2r5bCnQ...

> > I've been doing a bit of coding work towards this here at Google w/Brett for
> > Buzz as I have time.  It's fairly straightforward to do, and I encourage
> > others to try it out on their sites as well.
> > --
> > John Panzer / Google

> > jpan...@google.com / abstractioneer.org / @jpanzer
>
> > On Tue, Feb 1, 2011 at 7:00 AM, Andrea Messina <messinand...@gmail.com>

[Darren Bounds]

On Tue, Feb 1, 2011 at 5:51 PM, Andrea Messina <messin...@gmail.com> wrote:
> "During subscription verification the oauth_token included in the
> topic is verified and used to validate the response. "
>
> So, the hub checks if the token provided in the subscription_request
> matches that sent before in the OAuth2 assertion?
> What about when you say: ...and used to validate the response??..

The hub is blissfully unaware of any of this. The validation I was
referring to was handled by the subscriber verifying the token is
received in step 2. Something we've chosen to do.

> I have noticed that the endpoint is not protected.....but OAuth2
> requires TLS protected ones.

TLS wasn't implemented for the PoC but wouldn't affect the flow.

> According to which conditions, are you issuing access tokens?? I
> suppose, that, in your case, it is sufficient to validate the
> salmon(assertion).

The token is being issued in response to a follow request. The token
would also provide access to other protected resources owned by the
same user (e.g. poco).

> In principle, you could automatically ACL'ed the identity_uri.
> I wonder, what kind of flow, you would use, to personally check the
> request and approve it asynchronously. How would you send the access
> token??

This wasn't something we put a lot of thought into for our
implementation as it wasn't a requirement. Our goal was to provide a
simple way to know who's subscribing/following before providing access
to the feed/pshb subscription.

It may be reasonable to provide an access token on the assertion even
if the approval is async and then possibly respond with an HTTP 412
(Precondition Failed) at the feed and allowing the hub to retry at
some period of time (fixed or exponential backoff).