Token accumulation

One of the problems that comes with proper management of federated identity is providing unique tokens (which implies storing and associating for later use) for use with each of the millions (billions) of destination services where a user (or device) might need to establish an identity interchange.

The best (most easily observable) negative example, is the use of a single token for identity representation by our federal government. I'm talking about Social Security Numbers. Because we have a widely available, unique token it's quite common these days to see identity driven systems require a SSN, even if it makes no sense. Everyone wants your SSN, and once they have it, all kinds of fun and games are possible.

In a future I think we can help grow, why should a business (Joe's Wrenches) really require a SSN? What they need is a connection between between the employee they know as Barb Jones and the representation the federal government has for 010-010-1010. Ms. Jones should be able to perform the association between the big G and her employer in a way that makes her SSN transparent and leaves her in control (Joe's will dismiss her if things go badly wrong). Ultimately, Joe's Wrenches gets a token to represent Barb Jones to the G for income purposes. Where the model gets a little sticky is with revenue collecting states. What needs to happen here is that Joe's Wrenches needs to let the state (S) know that they have a negotiated ID token with the big G. Once again, Barb Jones will need to enter some information; certainly some company information, perhaps her G ID as well (her SSN: 010-010-1010). Once again, the G has to issue a new token for Barb Jones, this time to the State. Because the State requires Joe's Wrenches to report financial data, they'll be given a new token for Barb Jones, this one from the State, verified by the G.

The three legged identity cooperation in the previous example isn't going to be the bulk of the identity problem (we're definitely in the 20% category), but it's far from unique. Especially if we want to model devices and a whole host of other entities we haven't considered. One can easily see a not too far distant future, when considering even simple device based authentication will require such a three way ID exchange (device identity, user identity and network provider). Add another layer (roaming via WiFi perhaps?) and things get exponentially more complicated (that's just the way things work).

Outside of finally getting the examples above written down, I think they help to describe a problem that we'll need to wrestle with in the coming identity management world. We've got lot's of experience that demonstrates that using the same unique token (pick your poison, SSN is the easiest to make fun of) everywhere is bad thing. The solution is to use completely unique identifier's (tokens) for each external system. Before Barb has ever done anything with another system that Joe's Wrenches needs to work with from a business perspective, they've already accumulated three representations of her... their internal representation, the negotiated token used for the G and another used for the S. Over a period of a few years working for Joe's, it's quite likely that she will accumulate many hundreds (perhaps thousands) of these tokens.

Accumulating tokens for every user (which would normally be used as a reverse lookup process) isn't a big deal initially, regardless of how big your identity group is. It's a hassle if you've got 100,000 employees with a typical turn over of five years. It's a huge problem if you deal with hundreds of millions of identities and intend to keep them as customers for decades. The problem is expiration of tokens which are no longer needed; services which no longer exist, bank accounts which have been closed, cards which no longer exist... the list could go on and on.

And if you're the G, with the need to track 300 million plus identities over at least eighty years, this concept is going to cause a brain hemorrhage.

Toss in revocation and expiration? Things get really fun.