Re: Dialback in PubSubHubbub

Sorry for the late response.

Evan, your proposal is already covered (I think!) in the 0.4 draft we
released a couple weeks ago.
The differences are that we just use the From HTTP header, instead of using
a hub.from query param.
Also, rather than asking the hub to keep some 'logic' in it as to whom
should things be distributed or not (problem raised by Markus),
we'd rather use 'redirects' to the actual resource on the publisher's side.

For example, I have a 'main' public feed at http://ouvre-boite.com/feed/main,
which points to my hub.
If you want to subscribe to it, you provide the hub with the regular
subscription request, including a From header.

My publisher endpoint will ask me whether I allow you to subscribe to my
feed... (it will have previously checked who you are using the From header
obviously).
If I allow you to subscirbe to that feed... it's all great. I can also
decide that you're actually going to be subscribed to
http://ouvre-boite.com/feed/friends and you will then get a confirmation
with that new url (check 0.4 for the confirmation steps).

it's obviously similar is you try to subscribe to
http://ouvre-boite.com/feed/friends  and I decide that you should only get
http://ouvre-boite.com/feed/main...

Etc. The benefit of this, I believe is that it leaves each publisher decide
on their 'model' as for privacy, with 'group' feeds, individual feeds...
etc.

Mart, I haven't fully understood your proposal, but I think I generally
disagree with the idea of 'binding' the pubsubhubbub protocol with a
particular mechanism (which, it seems you do...). I think the callback
approach is very powerful because it lets the publisher decide whatever
makes sense for them...

julien



On Fri, Jun 22, 2012 at 11:52 PM, Martin Atkins <mart@degeneration.co.uk>wrote:

> On 06/22/2012 01:55 PM, Evan Prodromou wrote:
>
>> On 22/06/12 04:07 PM, Martin Atkins wrote:
>>
>>>
>>> This general idea was the basis of this draft I wrote a while back:
>>> http://specs.mart.me.uk/dfp
>>>
>>> I intended for it to be applicable to more than just PubSubHubbub,
>>> allowing ad-hoc "authentication" (insomuch as you're willing to trust
>>> what DNS and SSL certs tell you) of one domain to another with the
>>> assumption that once you've authenticated the domain you can trust it
>>> to make assertions about users in its domain without separately
>>> authenticating each user, because the domain would've been in control
>>> of each user's discovery documents anyway.
>>>
>> Could you sketch out the flow of how that would work with a PuSH
>> subscription?
>>
>>
> Sure.
>
> Assuming that we're only changing the part where we're authing the
> subscriber:
>
> * The subscriber domain, acting as a "source domain" per the terminology
> in the spec, establishes a domain association with the hub, which is the
> "target domain".
>
> * When making a subscription request, the subscriber provides the domain
> association bearer token established in the previous step along with the
> identifier of the user within its domain that is making the subscription.
> In my draft this is via an HTTP Authorization header, but it could easily
> be a pair of hub.* parameters in the request payload.
>
> * The hub checks the domain association bearer token against the set it
> has issued and thus verifies the identity of the requester.
>
> * The hub creates a subscription and notes that it "belongs" to the
> authenticated user.
>
> * At content distribution time, the hub is selective about which of the
> subscriptions will receive the new content based on the authenticated user.
>
> The main difference here vs. your proposal is that the dialback
> verification happens out of band of the PubSubHubbub request, much like
> OAuth separates the issuing of a token from the use of that token.
>
> When I originally drafted this I also imagined it as an alternative means
> for authenticated content distribution in PubSubHubbub, with the hub
> establishing an association with the subscriber and using it to prove its
> identity when sending a ping request, thus avoiding the need to sign the
> content and thus bypassing the so-called "turducken" problem that arises
> when supporting arbitrary content types.
>
>
>