Radovan Semančík's Weblog

My identity prediction number 2 got some attention also. Johannes Ernst asked me in mail to explain the "URL-based" bit of the prediction.

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.

WS-Federation

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.

Shibboleth

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.

LID

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.

SXIP

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".

ISSO

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.

My identity prediction number 6 caught the attention of Mark Dixon and Robin Wilton.

Strong authentication will get integrated with "identity": Authentication and "identity" may not be the same, but they cannot be seen as separate. Authentication companies will look at "identity" technologies as a way to sell more of their products. And the authentication products will comoditize. Maybe it will not happen in 2006, but we will eventually buy SecurID tokens in hypermarkets.

It looks like it would help to explain it a bit.

Robin is right stating that the token bought in hypermarket will prove that the holder is no-one in particular. It is exactly like that at the moment the token is purchased. But when the token is used, that may change.

If the token is used to browse some books at amazon, a wishlist may be created and "stored" at the token. And maybe some preferences profile also. Then the token may be used to browse a movie store. The movie site may get the topic profile from the token's "memory" and see that the owner is interested in sci-fi. The movie store may provide a list of best sci-fi movies directly on the store homepage.

(The information may not be "stored" directly at the token, but more about that later.)

After some time the data "stored" on the token may get quite rich. The sites may not know what is the name of the token holder, but may get user's preferences. That may be much more interesting than token holder's name. I'm sure you've got the idea.

Naturally, the use of the token must preserve user's privacy. "Traditional" tokens usually cannot do this. You have to bundle the token with something like Liberty Identity Provider (IDP) account to provide at least some privacy features. Therefore you will buy e.g. SecureID token branded with the logo of ReallyCool Identity Provider on it. And you will be buying an IDP account with the token. And if someone get the idea to bundle some interesting services (e.g. social networking or pre-paid account) with it, people may really want it. That is the reason I think that authentication products will integrate with "identity" technologies quite soon.

But that may be only the beginning. More and more "serious" companies provide "serious" products on-line. Take Internet banking and on-line brokering as examples. Each of these services requires (strong) authentication. As I've written before, we have been seeing that situation here in Slovakia for quite some time. We usually end up with several tokens for different services, and that's only few on-line service providers in a small country near the end of the world. Imagine that situation on the Internet scale ...

But if you've already bought token in the hypermarket, there is no reason why a bank has to issue you a new one. You may quite well use the one you already have. Just instead of going to your bank to collect the token, you go to the bank to tell them the number of your existing token (simply speaking, but LICSLW). No real trusted third party is needed, as the bank itself "certifies" your token (there is trusted third party in fact: the IDP). You can use similar procedure for other "serious" services as well. And end up with single token.

I hope that makes sense. Being a technologist, I'm not too good at predicting the "common" market trends. But selling tangible "token" instead of intangible "IDP account" may be the sparc leading to ... explosion?

James McGovern asked a lot of quesions few days ago. I think I can answer some.

The question on Message-Oriented Middleware is good but avoided one thing that is rarely discussed in terms of identity and that is workflow. Pretty much every Fortune 1000 enterprise already has some form of workflow engine in their shop which is a major component to identity management on the provisioning side. Why would an enterprise want to bring in yet another workflow engine that is relabeled in another context?

Absolutely none of the enterprises that I worked for had any workflow system usable for identity management. They have only small, inflexible (usually groupware-integrated) workflows. They were not exactly Fortune 1000 (I live in East Europe, you see), but I believe the same situation applies to most medium-sized enterprises.

And even if the enterprise has a good workflow engine, it may not be that easy. The "ideneity management workflow" is quite different form usual "document managemt" workflow. First of all, it works with quite special data units (provisioning requests) and has a lots of error conditions to take care about. In theory you can do that with generic workflow engine, but in practice it will be very difficult and will take a long time. Maybe the option of having two workflow engines integrated using WfMC interfaces is lesser evil than spending two years only on unifying identity management workflows. At least for now.

Another component would be connectors to directory services. Could someone tell me how many I need? One could logically assume one for each type of application / technology but if I go down this path, ain't I really just making a bad situation worse? How about telling me that it may be better for me to not spread provisioning type services all over my enterprise and instead recommend to me that I should consolidate identity stores?

You may be right, but only in ideal environment. In the ideal world, you would store your employee data only in one place and use that in all applications. But, imagine you have your employee data in SAP available only using SAP RPC. You may build SAP RPC to DSML adapter (or virtual directory) to make it "standard". Other applications will use DSML to get the employee data and use it instead of user databases. Great. But now imagine that you need to make "join" over that employee data with data internal to the application. That would be terribly ineffective even in medium-sized enterprises. OK, you can cache the employee data in applications, but that way you cannot use DSML (or LDAP) only. That will not support cache invalidation and will not work in security incidents, etc. And I have not yet mentioned legacy applications that will not adapt to anything. The best you can do is to inject user data to their databases and hope that it will not break the application and/or void the warranty conditions and rise suport cost.

The identity store consolidation may be a topic for future (if ever) when you will have unified and clean (SOA?) architecture. But it is not feasible now. "Single directory paradigm" does not work in the practice. A wild mix of directory integration, provisioning and (possibly) federation is the only hope for next 3-5 years.

If I wanted to consolidate identity stores, wouldn't Active Directory be a great place to do such a thing? What if I could get RACF to trust Active Directory? What if I could make all of my other enterprise applications not understand SPML but instead have them consume XACML from a centralized policy server that binds against Active Directory? Maybe I shouldn't care about SAML at all even though folks like Pat Patterson believe I should.

Maybe. But I believe that using directory/XACML will help only the simplest applications. XACML is quite static, complex and yet not that powerful. You may probably not want a policy language but rather a policy service (or more specifically an authorization service). SAML can supply an interface to such, remember PDP and PEP?

And if you want to forget about SPML, how would you manage stateful services/resources such as home directories on fileservers? I can imagine how to create these, but how to delete them? Using some unreliable and cumbersome cleanup/synchronization script? Old provisioning wisdom says that deprovisioning is as important as provisioning, but its importance is almost always underestimated.

The "Enterprise Identity Management" landscape is still in the heavy mist. There is no complete product or suite that can do everything that is needed. You will have to glue several parts together even if you "acquire" a "solution". It is partialy caused by heterogenity of enterprise IT systems. You cannot expect any product that has to span all the glued systems to be a polished monolith.

To get some insight into the real-world problems of enterprise identity management have a look at Enterpise IDM section of my blog or the Desmond O'Neil's Identity Crisis blog.

The beginning of a new year is usually a time for planning and predictions. I allowed myself a little fun to make these predictions (and hopes) about the "identity" techologies.

1: "Identity" becomes mega-buzzword

Every other company will be "identity-focused". More and more products will be "identity-enabled". You will hear more about "identity" in mainstream media. And most of the people (include those in "identity-focused" companies working on "identity-enabled" products) will know absolutely nothing about what this "identity" is all about. The "identity industry" will be hyped. The stock prices will rise too high to be realistic. Many startups and aquisitions. Some really valuable, most of them average, and some just empty shells with good marketing. As usual.

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.

3: More client-side identity implementations will be seen.

As of today, we have almost exclusively seen only pure-web server-side "identity" solutions. As the technology starts to mature, we may see more of a client-side support for "identity". Microsoft "identity selector" (InfoCards), and Liberty-Enabled Client Profile being the first signs, but I believe there will be more activity. Maybe Mozilla community will be drawn to "identity". Or maybe we will see first "identity selector" for Linux?

4: Enterprise Identity Management will spread through Europe.

This one is more a hope than a prediction. European companies are quite late adopters of Enterprise Identity Management technologies. I think that it will change, but the change will be quite slow (especially here in Central/Eastern Europe). There will be a bit more "identity" projects in 2006. But the hype wave will come with full strength in the following years, powered by regulations such as Sarbanes-Oxley or EU auditing rules.

5: Spam, phishing and pharming will get even wilder.

This is a safe bet. Nothing can be done to help in this area given current technology and only one year of progress. Spam will continue unhindered, heuristic methods being the most effective. The community will start to design the replacement for SMTP, that will be based on identity and social networking. It will not be seen as SMTP replacement at first, but will evolve to that. The phraud will move on beyond its current primitive techniques. Phrauders will find advanced methods, just like putting pharming functionality into viruses and worms. Strong auth will help a bit, but will not stop the most sophisticated attacks.

6: Strong authentication will get integrated with "identity".

Authentication and "identity" may not be the same, but they cannot be seen as separate. Authentication companies will look at "identity" technologies as a way to sell more of their products. And the authentication products will comoditize. Maybe it will not happen in 2006, but we will eventually buy SecurID tokens in hypermarkets.

7: We will see attacks targeting legacy "trust" mechanisms.

Ever seen the list of "trusted" certificate authorities in your browser? Ever wondered how difficult is to get a false certificate from any of these authorities? Well, I expect that someone will try and succeeds. There was not much motivation yet, as it was easier to steal a password. But once strong auth will be here, man-in-middle attacks will be popular again. And given the cumbersome and not-much-functional revocation mechanisms of X.509 implementations, these attacks may get pretty effective. The year 2006 will be long over when people finally realize that the authentication must be mutual, not only one-way and that the "strong auth" is not a panacea.