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
signature.asc
Description: This is a digitally signed message part
