Re: Dialback in PubSubHubbub

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.

I think this approach is advantageous because it allows a domain with 
many users to do only one dialback for each direction of communication, 
and it allows an association to be established up front and used many 
times until it eventually expires.



On 06/22/2012 12:42 PM, Evan Prodromou wrote:
> Folks,
>
> One of the things we've talked about as being a weakness in the 0.3
> standard is the lack of limited distribution -- delivering certain
> updates to certain people.
>
> One possible solution to this problem is dialback verification at
> subscription time. As far as I know, Blaine Cook is the originator of
> this method, but I'm not sure it's been implemented or described in detail.
>
> I've written up the idea here:
>
> http://www.w3.org/community/pubsub/wiki/Dialback
>
> Here's the basic idea:
>
>  1. When making a subscription request, the subscriber passes an
>     additional parameter, "hub.from". This is either a Webfinger
>     <http://en.wikipedia.org/wiki/Webfinger> address or an HTTP URI
>     supporting LRDD <http://tools.ietf.org/html/rfc6415>.
>  2. If the "hub.from" parameter is present, before verifying the intent
>     of the subscriber, the hub should discover the
>     "pubsubhubbub-callback" links for the hub.from account using
>     Webfinger or LRDD.
>  3. If the hub.callback value is not one of the links that match the
>     response, the hub should halt and return an error.
>  4. If the hub.callback value is one of the links, the hub should verify
>     the subscriber's intent. It should include the hub.from value in the
>     parameters.
>  5. At content distribution time, the hub should deliver content to the
>     endpoints that the publisher has authorized.
>
> Some notes:
>
>   * This method presupposes that there is one user per callback URL.
>     There is no information in the content distribution payload that
>     describes the intended recipient.
>   * Although it's possible to define a different callback per
>     subscription, it would probably make the Webfinger document or LRDD
>     document prohibitively large. A user with tens of thousands of
>     subscriptions, each with its own callback URL, would be too large.
>   * Communicating authorization info between publisher and hub is left
>     undefined.
>   * With this mechanism, there will be exactly one HTTP call per
>     subscriber. There is no bundling of multiple subscribers in one
>     payload.
>   * Blaine suggests using the "From:" HTTP header. A parameter is used
>     instead.
>
> I think this mechanism is simple enough to be included in the 0.4 spec
> as-is.
>
> -Evan
>
> --
> Evan Prodromou, CEO and Founder, StatusNet Inc.
> 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
> E:evan@status.net  P: +1-514-554-3826
>

Received on Friday, 22 June 2012 20:08:32 UTC