Right now, you implicitly trust the skills of every dba for every database where your social security is stored. Who are they? Where do they work? How were they trained? It's difficult to say from where you are sitting, isn't it. If you are one of the 1.5 million people who had their info stored in and stolen from a UC Berkeley database, you are know more conscious of the need for reform of how digital identity is managed.
By databases here I am referring to any system that stores user data. Could be LDAP, RDBMS, Legacy - any system that stores identity information. How many databases storing privileged identity information are connected to the network? The actual number is anybody's guess.
As the Cal story shows, each of these systems holds the potential for loss/theft/misuse/abuse of digital identity - so it follows that the sheer number of them poses significant risk. One of the great hopes of federated identity is the possibility that widespread deployment of systems that can exchange identity information at run time will lead to a decrease in the number of databases that store identity.
I'm not calling for an all out aggregation into a single mongoloid directory - but some aggregation of identity information into centralized systems would be a big step in the right direction. Each aggregation point will be held to higher benchmarks for trust, security, privacy, and open standards than any completely decentralized system can ever attain.
The current eulogies being written for MS Passport tend to dismiss the centralized model for universal identity as a threat to privacy. The fact is that without some degree of centralization it will be impossible to bring commonly recognized and trusted integrity to digital identity.
The only good thing about Passport was at least you knew Microsoft wouldn't buy their database. But you stopped short regarding lowering the number of databases: it should be just one.
I went into a bit more detail about user control of personal information on my blog at http://blog.fen.net/archives/000037.html
Posted by: Fen Labalme | January 10, 2005 at 07:02 PM
sorry - screwed up the URL: shoulda been http://blog.fen.net/archives/000038.html
Posted by: Fen Labalme | January 10, 2005 at 07:04 PM