Naive Identity Systems09 Jan 2006
- 2: Many "identity" mistakes happen, but it will take a while for them to be seen.
- It will become apparent, that "user-centric" identity is not that easy. Not many of the "identity folk" will ever admit it, but they will know, sooner or later. The naive global (URL-based) "identity" systems will proliferate for a while, but (hopefuly) not for long. Most of the current "user-centric identity" systems will need to be redesigned, limited to specific purpose or will just die. Maybe not in 2006, but they may eventually face the fate of X.509. We need to see at least one more generation of "identity" system to get something really usable. Similar situation will be seen in the real world. Many "national ID" and "national database" system will be proposed only to learn that the technology or the approach is not yet good enough. If you ask me who will "win" on the Internet, I think that it would be something based on WS-Trust. Or maybe something similar to WS-Trust that can be used both over SOAP and REST. But that will not be apparent in 2006. And I think (a hope again) that the "claims" will be SAML-based.
There are identity system that oversimplify the identity approach. I call these system as "naive". The "gang" usually accuses these systems of breaking Kim Cameron's laws of identity, but that may not be the only problem with them. The systems may not only violate user's privacy, but may also violate the architectural or business best practice. For example, the systems may not scale well, may be wired to single cryptographic suite, may have inconsistent trust dependencies, etc. According to my prediction these systems need to be redesigned, limited or buried.
To know what (or who) I am speaking about, these "naive" systems are usually URL-based. I wrote a short paper on this in spring last year. This paper was shortened due to the conference requirements, therefore I've decided to put the full version of the paper online. (The paper is not yet a year old, but yet it is quite outdated. The development of identity systems is going fast, which is a good sign.) I summarize the document here and add some new information.
I've studied five identity systems: Liberty ID-FF, WS-Federation, Shibboleth, LID and SXIP. I've looked at them from the basic viewpoint of Internet-scale SSO systems, which may be a bit oversimplifying, but some observation are general. My current opinions on these systems:
- Liberty ID-FF
- Good and detailed specification, default use of pseudonymous identifiers. Good industry support. Ready to use. Limited to SAML.
- Identifier policy and token choice left to implementers. That might provide excellent flexibility as well as serious interoperability problems. Not yet ready to use. Needs more detailed specifications. But the architecture is right.
- Good for intra-organization use, or for use by several similar organizations that can agree on may details "out of band" (just like universities, where the project originated). Missing details (e.g. identifier policy) for general Internet use.
- Serious security risk when using "http" method. Strange architectural decision for mixing X.509 ("https") and GPG mechanisms in such a way, that compromise of either will lead to compromise of the whole system. The proposed self-hosting use of LID has questionable security/privacy benefits. The protocols may work, but the system has to be cleaned-up (possibly redesigned) and refined. The use of single, global URL-based identifier is terrible for privacy. While the system can support multiple "pseudonyms" using "delegation", this process is not fully automated and user must remember at least the "pseudonym URL" to use at each site. That may get very complicated if the number of "pseudonyms" will be large, like when implementing Liberty-like pseudonyms.
- No real security while using the "simple commands" even while using HTTPS. Missing details on XML Signature creation in "xml commands" mode, that may lead to incompatibilities and/or security weakness. Use of global identifier (GUPI) may in theory provide persona migration, but is very bad for privacy. Not only can membersite collude to correlate information about user, but if authDelegation expiration time is low, the rootsite could track part of the user's activity. The creation of different personae for a user may be supported, but the persona (and GUPI) creation is not automated (the rootsite GUPI creation policies may hinder it). The implementation of Liberty-like pseudonymous identifiers may require changes to SXIP protocols and/or policies.
And here are some new entries. No paper to back these statements, they are provided "as-is".
- Use of global-context i-name (such as =foo.bar) for all sites may be bad for privacy. The service providers may collude (see here) to get more information as explictily allowed. The XRI may be used as "pseudonymous" identifier in theory, but the practical system and/or protocol is not yet developed.
- Digital Credentials
- Progressive system build on modern cryptography mechanisms. And as far as I can see, this approach may be the most privacy-conserving mechamism, if it will keep to its promise. But the Stefan Brands' method for digital credentials is patented and even the protocols has not yet been released (AFAIK). And one cannot be paranoid enough, given relatively new cryptography methods that cannot be easily replaced.
Some of these statements may be outdated. The list of specifications (dates, versions) that I used for evaluation can be found in the paper. If there is something wrong, please let me know (using that "writeback" button below). I had not enough time to look at YADIS, passel, OpenID and others, so I will not write about these. Maybe later.
All of the above mentioned systems, except digital credentials, have the same drawback: Identity Provider may track quite a lot of information about user's activity. And digital credentials are patented and not much tested in Internet day-to-day practice. As you can see, no "identity system" is perfect. Only Liberty seems to be ready for production, and even that may not be feasible for full Internet-scale deployment. I really think that we must see at least one more generation of these systems to get it really right.