Notes on the Cloud Identity Summit - Guest Post from Zane Rockenbaugh
A couple week ago, we held out second Cloud Summit, the Cloud Identity Summit. It was a fun afternoon talking with several, local identity experts and users. One of the attendees, Zane Rockenbaugh of Liquid Labs was kind enough to share his write-up of the event, below:
What is identity?
Identity consists of set of identifiers, authorization credentials, and a small set of extensible attributes and endorsements.
What isn't identity?
More expansive definitions for identity certainly can make sense, but for purpose of creating a real world, technical system, it is necessary to separate "identity" from "data" in general. E.g., from the standpoint of "you are what you do", your shopping history is part of or your larger identity, but for the purpose of this statement, that kind of information would be considered out of scope.
What is cloud identity?
Classic cloud identity is conceived as a portable, comprehensive, and extensible identity. Control and management of identity would be focused on the identified entity itself, and while not entirely centralized, use and flow of identity would be more transparent.
What are the benefits?
By locating primary control of identity with the entity itself, it necessarily follows that “utility friction” would be lessened and that total utility would be increased [if people control their own identity, it's probably easier for them to use it -Cote]. With the necessary technical, legal, and social framework we would expect to see privacy rights strengthened and while the exchange and value of information would simultaneously increase.
What could this look like?
The most likely form would be:
An open, easily consumed container format, likely some XML variant.
A small set of core attributes “that (most) everyone can agree on”. Core identifiers, such as “user name” and email may be reasonably defined by existing specification or fiat. Personal information (name, address, etc.) is tougher, but also not critical to the basic operation.
Extensible modules. Some identity information may be understood by some consumers and not others. These boundaries would need to be made clear.
Clear access rules that are based on who is asking for what and under what context. E.g., a cellphone carrier can get my credit card for billing, but not for basic support.
For the classic conception to be made real, the identity itself has to be housed at a third party identity provider who services the individual whose identity is being stored. Any other arrangement would effectively fragment the identity.
What are the key obstacles?
The preponderance of existing business models view “identity” and related data as a proprietary asset of the company. A lot of the value of Google and Amazon is in what they know about the customer.
One can imagine a stable and economically rational world in which Google (etc.) is properly incentivized to recognize a “cloud identity” rather than forcing the user to create a proprietary identity wholly owned by Google, but getting from current reality to that reality would be very difficult.
One of the difficulties in bridging the chasm is the value proposition for a company offering a cloud identity service. Such a business would, by definition, not own the data it manages on behalf of the customers, so how it would be financed is unclear. If such a business existed and had critical mass, it could be viable, but again, how does one get from here to there?
There are also a host of regulatory concerns which would make participation by certain domains (namely healthcare and banking) difficult and potentially—at least without major changes to the regulations—impossible.
What could be done today?
Rather than focus on a theoretical “cloud identity”, it makes more sense to focus on the benefits such a system could provide and ask, “Is there a way to provide that specific benefit now?”
Cloud services pose a problem for organizations that need to control access to information, manage brand, and manage authority. “Hoot Suite” is a tool that provides for corporate (in the older, broad sense) management of individual Twitter accounts. The same concept could be expanded to many cloud services to provide a point of necessary control in service access and usage. In the ideal case, there would be one service that would provide single point control and provisioning for all the underlying cloud services which would appear as modules within the identity management service.
Many cloud services offer business accounts which allow the business to create an virtual instance of the service with additional controls for the business. Google is an example. This approach solves some of the problems mentioned above, but doesn't do anything to centralize identity management. From the standpoint of evolving a cloud identity, service providers would be best served by designing robust APIs with the appropriate concerns in mind.
