I suspect I might have created the term "light-weight digital identity" (as in LID), or I was at least one of the first to widely talk about it. So given the intense discussion on what the pros and cons of "light" vs. "heavy" might be on various mailing lists these days, I thought I throw in some of my thoughts on what makes an identity technology light-weight:
- A developer can say "I understand how this works" after, say, less than an hour of time spent trying to figure out which information there is, and studying it. Granted, that depends on the quality of the documentation, and it that doesn’t mean he’s got to understand every last detail, only that he’s confident he gets it.
- After that hour, the developer has a good grasp about how the technology impacts her project.
- After that hour, the developer has a good idea of the security ramifications that the technology brings. That doesn’t mean the developer has figured out really sophisticated attacks against the technology, but he is able to have a good idea about the kinds of attacks he should be worried about.
- Assuming good libraries are available, the developer can incorporate support for the identity technology into their own project "over the weekend".
- If a developer is a good hacker, she can implement the spec at least in some basic form very quickly. If there is currently no support for it in language X, the developer can create that support quite quickly herself.
- Any developer can go through the source code of an implementation and "get it" how it works from reading it. This means, among other things, that the code supporting it is not of unlimited size…;-)
- The identity technology has no major architectural ramifications on existing code. For example, it does not drag in other things as prerequisites (e.g. the existence of a public key infrastructure, having to move from Apache to Tomcat, or things like that)
- All that’s required for developer A to interoperate with developer B is a shared spec. No custom negotiation is necessary, neither technical nor contractual.
- The technology can be successfully deployed without having to acquire "big software", pay big consulting fees or anything of the like. Of course, that’s one of the reason why certain parties don’t like these much simpler technologies…
When I say "developer" I mean "developer with no specialized knowledge"; I don’t mean "developer who has spent the last 5 years in standards organization X".
And, I think the most important characteristic, although difficult to measure, is this: the technology is so straightforward that the developer can, after some time (days, not weeks) come up with new ideas on how to build the next layer on top of the identity technology that just uses the identity technology as a stepping stone. For example, there are now a bunch of people thinking about how to build a reputation layer on top of YADIS/OpenID/LID, neither of whom felt the need to first ask the people who built that layer (that is a feature, not a bug!) It is a measure of technology complexity if one can’t simply do that.
A heavier technology would not have the same properties; while it is correlated, the actual size of the code implementing the protocol is not really the core issue.