social-discuss
[Top][All Lists]
Advanced

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

Re: [Social-discuss] Privacy-over-Webfinger Draft


From: Ted Smith
Subject: Re: [Social-discuss] Privacy-over-Webfinger Draft
Date: Wed, 14 Jul 2010 22:58:51 -0400

On Wed, 2010-07-14 at 02:34 +0100, Blaine Cook 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.
> 
> For those concerned about security, don't despair, crypto can be
> layered on like maple syrup at a sugar shack. :-)
> 
> b.

An editing note - you use the phrase "reader" in section 3, but it seems
like after that, you use "user" where you want to say "reader".

The sort of thing in Figure 4 unnerves me - that sort of transparency in
the origin of a request reveals the social graph to both the client and
the publishing server. I'm not quite sure if there's a way to avoid this
while still doing authentication of the type you propose; in Social-P2P
we avoid this by simply giving encrypted data to anyone who asks
(Diaspora, I hear, will do the same thing). It seems to me that the only
way to protect the social graph in this case is to use public-key
cryptography; if the user and publisher can have an exchange that's
encrypted end-to-end, then they can utilize crypto at key points to
ensure that the client and content server don't know who's talking to
whom. This also allows you to forgo the question of whether the user has
delegated to that client, since the client is no longer trusted with
either the data being requested or the social graph.

I'm not sure if this is permitted by your specification, however. I'm
not really good at reading this sort of draft, but it seems like the
content server MUST know the originating user, and since they have to
know who the publisher is, it seems like the social graph is irrevocably
compromised.

Is that included in "Plenty"? :-P

- Ted

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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