A former colleague, Wim Guerden, is fond of saying: "You know all about me, but I'm in control." It is a statement about how comfortable we are giving over information to a company (in Wim's case, he's usually talking about a bank), as long as we retain control of the information. This implies an underlying trust relationship. What does it mean to be in control? How much more complex is control when innovation reigns in the hands of sophisticated users? How do I know if I can trust? What is the right amount of information to expose in a given context?
The drive to place greater control in the user's hands is obvious in the consumer electronics space. But to be "in control" means to give the user better control over their data. That data may be spread across multiple providers, and some of it held solely by the user. Access to the data relies on strong identity management (IdM) strategies, but whose responsibility is IdM? A single enterprise may have an IdM strategy to cover users of its systems, but that may not suffice to support all end user scenarios. So, the question arises, should the enterprise even be in the IdM strategy business at all? Or should they focus on authentication and application of identity provided from an external trusted source?
A few weeks ago, I met with a senior architect from a European company over coffee in Amsterdam. I paraphrase, but his comment was: "IdM is a pain, and I shouldn't have to do it." He had more colorful things to say about Role Based Access Control (RBAC), but I'll come back to that another time. From there, the discussion branched into IdM in the "cloud", meaning that IdM would be accessible as a service and that the user (i.e. owner of the identity) is ultimately in control. That user could choose how and what to expose to trusted parties on the web in order to fulfill their cross-provider experience.
Bob Blakley, research director from our IdPS team, is writing extensively on a Relationship Layer for the Web (and enterprises too), recently concluding:
An identity is a model of a person. Only an organization which has a close relationship with an individual knows enough about that individual to build an identity which is an accurate model; the more intimate the relationship is, the more accurate the identity will be. Organizations have only casual relationships with most of the individuals they deal with, so they build inaccurate identities which create risks for individuals and for themselves. Building accurate identities on the Internet will require new relationship technology and a new set of intermediaries who have sufficiently intimate relationships with individuals to construct identities for them.
Like Jack (see this post, for example) , I am loathe to blithely toss things into the nebulous "cloud" because it is currently cool to do so. In conversation, the "cloud" can be a stand-in for the classic meeting "parking lot" where we dump things that we either don't want to discuss, haven't figured out, or don't want to waste any more time on. In fact, the "cloud" concept is (literally) drawn from software and network diagrams when we needed to represent something that happened (usually on the web), but we didn't want to specify the details. Perhaps we didn't know them.The cloud just magically did its work and handed us the results and life was good. (See the beautifully meaningless image here as an example.)
When it comes to identity in the cloud, we have to come to grips with ownership. If the user -- who is mobile and uses multiple applications that require identity -- is the "system of record" for their identity, then it makes sense for identity management to fall outside enterprise walls. But, as Bob indicates, the mechanics and intermediaries to provide ubiquitous, external IdM facility need to be put in place. For related insights from Bob and his team, start here.