Dialback in PubSubHubbub

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