One problem with distributed identity systems

August 13, 2007

From one perspective, using someone else's identity system sounds very nice. Imagine the convenience of being able to just use LiveJournal user accounts on your site, or (for an example closer to home) a central university database of campus-wide accounts.

(Yes, I am conjoining 'identity' and 'authorization' here, because I believe that it's what a lot of people do in practice when thinking about this sort of thing.)

The problem with this is that any time you use a distributed identity system, you are delegating the ability to establish and retract identities on your system to some remote third party. Even if you trust them not to be malicious, can you trust them to take (enough) action if one of their users is merely abusing your system?

The inevitable result is that attempts to use distributed identity systems generally grow at least local blacklists, and may have to go all the way to local whitelists. At this point you have less of a distributed identity system and more of a global identifier and outsourced password handling mechanism.

(Not that this is useless; users appreciate not having to remember yet another identifier and password.)

I believe that a genuine distributed identity system can only thrive within an organization, and only then when all of the bits and pieces involved have the same policies on use, abuse, and termination. This probably rules out universities, or at least large ones.

Written on 13 August 2007.
« Adventures in network design, illustrated by our new backbone connection
The benefits of growing your toolbox »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Aug 13 21:30:54 2007
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.