social
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Social] Re: Privacy-over-Webfinger Draft


From: Blaine Cook
Subject: [Social] Re: Privacy-over-Webfinger Draft
Date: Wed, 14 Jul 2010 16:42:23 +0100

On 14 July 2010 14:47, Ben Laurie <address@hidden> wrote:
> On 14 July 2010 02:34, Blaine Cook <address@hidden> 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.
>
> What summit is this?

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]