Re: Dialback in PubSubHubbub

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.

Received on Friday, 22 June 2012 21:52:38 UTC