Domain Federation Protocol

[Martin Atkins]

Hi all,

A while back I penned this simple specification that I think offers a
foundational piece that could be built upon for a number of federated
social web use-cases that require clients to have identities:

http://martin.atkins.me.uk/specs/dfp

Depending on your background, you could choose to understand this as
either "an HTTP mechanism similar to XMPP dialback" or "the dialback
functionality from PubSubHubbub refactored out into a more
generally-useful component".

Federation is done at the DNS domain level, so there is one bearer token
for each (source domain, target domain) pair. With this I aim to make
this both usable for personal domains and scalable to large domains like
facebook.com with minimal per-user overhead.

Example use-cases:

- Salmon-like pushing of comments "upstream" could use DFPEntity auth
as an alternative to magic signatures, at the expense of losing the
end-to-end authentication magic signatures affords. However, given that
websites can already lie in their HTML pages and say that someone said
something they didn't I'm not sure this is a problem.

- Authenticated PubSubHubbub subscriptions, with dialback cost on a
per-target-domain basis rather than a per-feed basis.

(In short, the use-cases for authenticated OStatus.)

This specification also bundles a WebFinger-like mechanism that uses a
simple JSON document instead of XRD, with the intent of establishing a
registry for the keys in that document. However, the basic idea of doing
dialback could be applied with XRD as the discovery mechanism if folks
find it distasteful to reinvent that particular wheel.

I'd be interested to hear any thoughts or feedback people have about
both this concrete protocol and the general idea of using inter-domain
association tokens established via dialback.

Thanks!

[Evan Prodromou]

Martin,

I haven't had a chance to review in detail but definitely an interesting line of inquiry.

I'll take a look further.

-Evan