This Blog
Syndication
Recent Posts
Tags
Calendar
Archives
Identity and Access Management (IAM)
Tuesday, June 12, 2007 - Posts
-
Open ID 2.0: A Step Towards User-Centric Identity
Recently I attended the IIW (Internet Identity Workshop) in Mountain View, CA at the Computer History Museum. If you ever get the chance to visit the museum, I highly recommend it. This conference is normally attended by about 100 technology individuals from all walks of life -- major vendors, educational institutions, government bodies, small startups, etc. Basically, a "Who's Who" in user-centric initiatives.
You probably have read about the Identity Metasystem, CardSpace, and OpenID. I am going to discuss OpenID in this posting, and will save the Identity Metasystem and CardSpace for a later time. If you are unfamiliar with user-centric identity initiatives, I suggest you Google it to get up to speed.
First, some history. OpenID grew out of the social networking community in an attempt to provide for a simple, unique URL-based identifier that individuals could use to identify themselves to multiple websites (blogs, social networks, etc). In contrast to normal userid/password authentication mechanisms, OpenID is intended to use unique URLs to represent individuals. The idea behind OpenID is that it is better to have one ID that I can use at multiple sites as opposed to a unique username/password at each site. This would help with the username/password proliferation, registration and identity data duplication. A pretty helpful concept.
To get an OpenID, you need to register at an OpenID Provider (OP), and there are some free OP's out there that allow you to grab your OpenID of choice. For example, one possible OpenID is http://jeff.fromCA.myopenid.com, and my OP is http://www.myopenid.com. This means that I have registered with the OP, and provided various pieces of identity information for them to hold for me. When I need to authenticate or register at another website, I can give it my OpenID, and my OP will vouch for my identity and will also provide some of my identity information to the new site, if requested. But - and here is the user centric part- I get to determine if I want my identity information provided to the website, and what information I'm willing to share with it. So, I have control over the proliferation of my identity information.
Note: for the remainder of this posting, I will use OID1.1 and OID2.0 to refer to the OpenID 1.1, and OpenID 2.0 specifications, and OID to refer to OpenID the concept.
The OID1.1 specs have been around for awhile, and the OID2.0 specs have been in a state of flux for the last year. The OpenID community had hoped to deliver the 2.0 specs last December, but a few issues have slowed down the delivery.
While some social networking sites have implemented OID1.1 registration and authentication services, OID2.0 is much less prevalent, simply because it is not complete and approved yet.
The original OID creators defined some guiding principals in the definition of OID1.1 that they have brought forward in the definition of OID2.0. They wanted to use basic building blocks in the construction of the system. This means basic open protocols (http, post, get, headers, etc) should be used in the construction of the message exchanges, SSL certificates should not be required, and if needed, Transport Level Security (TLS) should be favored over Message Level Security (MLS). Also, the user ceremony (user logon process between the website and OP) should not require any browser extensions or plug-ins.
For social networking sites like blogs, photo sharing, etc, these restrictions were not overly onerous. The convenience that OID1.1 provided to the user outweighed any increased potential for usage tracking and collusion between sites. It is easier to create a reputation (opinions about yourself) when you can show that you are the same person at multiple sites. Another potential benefit that was envisioned is the creation of friend lists that could be used at multiple web sites. Just the mere benefit of reduced username/password proliferation and entry, is more than enough to justify the enthusiasm and amount of brain power going into the new specification.
OID also allows for the definition of profiles that allow you to define your attributes for the various hats that you wear on the web. For example, I could have three personas defined for my OID, " Jeff at work " Jeff at home " Jeff the invisible
As long as my OP was in business, I could use my OID at any sites that accepted OID's as authentication credentials.
To authenticate to a website that supports OID, you type your OID into the logon dialog of the target website, the website asks your OP to authenticate you and validate that you are the owner of your OID. If all goes well, you are granted access to the resources you requested. This requires a level of "trust" between the target website and your OP. The target trusts the OP to authenticate that you are who you claim to be. How this is done is left up to the OP, and it could range from authentications using username/password, certificates, to more advanced mechanisms.
The key point is that a URL-based identifier was enough to uniquely identify me. OID provided a nice, simple, scalable authentication mechanism based on open web protocols. In the value chain, the risk of identity theft or phishing was lower than the benefit of using a single identifier/password at multiple sites. After all, I was using the OID to access my blogs, or photos, or music. I was not using it to access my bank account or my company's network. The usage of OID is appropriate for low risk transactions, but as the usage of OID tried to move into the enterprise, new requirements were discovered and OID1.1 needed to address these issues with a new specification.
The first version of the OID specs did a nice job of what it was designed to do. It provided for a universal identifier for authentication to relatively low risk social networking sites.
As OID1.1 began evolving to OID2.0, additional capabilities were added to the existing specification, but the underlying foundational premises were kept the same (no SSL, no browser extensions, OID1.1 compatibility, and basic HTTP building blocks). Some of the new OID2.0 capabilities and associated solutions have opened up some security concerns. There have been many conversations describing the Phishing problem that the current OID2.0 draft allows. To address this concern and a few others, the OID community has started to reevaluate some of the basic premises just mentioned. Hopefully, some of the discussions currently under way on the mailing lists will lead to acceptable solutions to the very difficult problems. Not surprising, but some of the proposed solutions are even investigating ways in which existing standards and protocols may help. Current standards such as SAML, and the proposed WS-Federation have some capabilities and concepts that could be helpful in rounding out the specification. Combining the OID2.0 specification with some of the existing proven protocols would be good for all, since the more interoperability that can be provided between the various standards, the more prevalent user centric identity will become. We need to make sure that OID succeeds, and one way to do that is to provide interoperability with existing standards, this will help bridge the perceived chasm between the social networking environment and the enterprise ecosystem. Having OID interoperating with existing standards will make it easier for organizations to use the most appropriate technology for the problem space.
OID has a unique challenge in front of it. It has the attention and support of the Identity community, and has positioned itself to help educate the web community on the benefits of user-centric initiatives. The OpenID 2.0 specification needs to be completed as soon as possible. Ideally, the problems that have been uncovered can be mitigated with the integration of existing standards. There are some problems, and it will not be without some heartburn, but we as a community should look for answers and find a way to help OpenID2.0 achieve the goals it has defined for itself. In the end, everyone wins.
Print
Email
Rate+-+CA&dcsref=-&WT.cg_nid=120298&WT.cai_l1=120399&WT.cai_l2=120298&WT.cai_l3=&WT.cai_cntry=us){kind=small}