Privacy-over-Webfinger Draft
Blaine Cook
insecure but easy-to-implement approach to decentralized authorization
using webfinger. Feedback is most welcome, especially in the lead-up
to the Federated Social Web summit in Portland this weekend.
For those concerned about security, don't despair, crypto can be
layered on like maple syrup at a sugar shack. :-)
b.
Blaine Cook
> On 14 July 2010 02:34, Blaine Cook <rom...@gmail.com> wrote:
>> Attached is a[n early] and long-promised draft of a relatively
>> insecure but easy-to-implement approach to decentralized authorization
>> using webfinger. Feedback is most welcome, especially in the lead-up
>> to the Federated Social Web summit in Portland this weekend.
>
http://federatedsocialweb.net/
> Anyway...
>
> a) So much of the spec is out of scope, this doesn't really describe a
> mechanism at all.
Most of the out-of-scope stuff is interface, but I wanted to include
descriptions for the sake of a complete description. The only bit
that's truly out-of-scope is how the requesting Client is
authenticated.
PubSubHubbub provides a callback mechanism, but I wonder if we
couldn't define something more generic (e.g., using the new-ish HTTP
Origin header as a key to verify requests?).
> b) Webfinger is used, it seems, to do all-or-nothing delegation to the
> Client. What about scoped delegation?
So far I've just started with rel=me; the real challenge, of course,
is going to be getting those XRD / hCard profiles populated (XRDP?).
I've punted on this one because rel=me is enough to get something
*built*, and it's not clear that rel values alone are sufficient to
describe a usefully rich scoped delegation scenario. Any ideas as to
how we might do scoping in a simple way?
> Not using HTTP throughout would probably be a good start.
Good point, thanks. :-) The direction I'm also heading is to use magic
signatures in much the same way that they're used for Salmon, but more
generically.
b.