Dialback

The goal is limited distribution.

1. When making a subscription request, the subscriber passes an additional parameter, "hub.from". This is either a Webfinger address or an HTTP URI supporting LRDD.
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 Cook (original author of this idea) suggests using the "From:" HTTP header. A parameter is used instead.
• The contents of the feed as viewed by an unauthenticated user or process might not include the values that are delivered through PubSubHubbub.