The Real Problem · Of course, out there in the enterprise space where most of Sun’s customers live, they think about identity problems at an entirely different level. Single-sign-on seems like a little and not terribly interesting piece of the problem. They lose sleep at night over “Attribute Exchangeâ€; once you have an identity, who is allowed to hold what pieces of information about you, and what are the right protocols by which they may be requested, authorized, and delivered? The technology is tough, but the policy issues are mind-boggling.
While it’s true that OpenID doesn’t really deal with attribute exchange (and usage, etc — yet) I think what it really does is standardize a user-controlled request process. So… just like restful proponents seek to standardize the semantics of acquiring resources and interacting with them, OpenID provides a simple, standard authentication channel. An application could be locally configured to only accept OpenIDs from certain IdPs (e.g. a University’s OpenID server, federated partners, AOL) or have some kind of assurance checking mechanism, but that’s *optional*. Whereas, for the common internet case of just wanting a persistent handle so people can come back to the same account again (low assurance).
In terms of attribute release – just like DRM, I have yet to really see a workable attribute usage and release scheme that doesn’t require you to trust recieving parties anyway. And the OpenID approach of having the user approve the IdP’s release of particular attributes seems just as reasonable (and much more scalable) than an institution trying to build a policy with tiers or permissions as to who can get data. Requiring user release seems to solve lots of problems, actually.