Issue link: https://digital.copcomm.com/i/15338
place single sign-on option for the Internet at large. Most sizeable Web-based service providers such as AOL, Google, Facebook, Microsoft, MySpace and Yahoo! have integrated at least limited support for OpenID. Services often run OpenID authentication side-by-side with their in-house de- veloped authentication or as an alternate method of authen- tication. Once the user has authenticated via their OpenID provider, their credentials can be used to automatically sign the user into other services previously linked to their OpenID. Widespread support has made OpenID the de-facto authen- tication mechanism for low-value transactions on the Web. T Two quick and somewhat loose definitions. An OpenID Provider is part of the backend of an identity system that offers an authentication services to other systems known as OpenID Relying Parties. Say your favorite blog requires that he OpenID authentication framework is the most well known of the federated user-centric identity systems. OpenID has effectively become the first common- ON MESSAGE WITH BEN GROSS OpenID Trends: Improved Usability and Increased Centralization you log into Google to verify your identity to comment on a post. In this case Google would be the OpenID Provider (Identity Provider is the generic term) and your favorite blog would be the Relying Party since it depends on Google to handle the details of authenticating you so you can post. Usability OpenID has made great improvements in usability in the last several years. Many people found early OpenID implemen- tations confusing. Users needed to first enter the URL that served as their OpenID identifier such as http://username. openidprovider.com. Without an existing cookie, users would have to enter their email address and password to complete the authentication. In addition, the users browser window was typically redirected to the OpenID provider’s site and then redirected back to the service they were trying to log into resulting in further confusion. Service providers found that the combination of URL-based identifiers and a login sequence differed from the entrenched standard of a user- name and password combination confused many people. Each of these factors significantly reduced the usability of OpenID. However, OpenID specifications and implementa- tions have evolved to mitigate and eliminate many of the usability problems. In many current deployments, users simply click on the logo their OpenID Provider (e.g. Google or Yahoo!) and then log in with familiar credentials without realizing the authentication is OpenID-based. One significant unsolved usability problem is that OpenID offers no support for Single Log Out. In the case of public or shared computers this situation is a significant security risk, as well as a usability problem, as subsequent users may find themselves signed in under the wrong user name when navigating to new sites. User centric identity theoretically offers the end-user more control over his own identifiers, however in practice the amount of control is dependent on the amount of control the user has over the domain name or service of the OpenID URL. Users may maintain multiple OpenIDs and OpenIDs may be delegated. For example, an individual may wish to use a personal domain as an OpenID URL. The problem is this requires the skills to run the OpenID server as well as the overhead of maintaining and securing the server. There are two straightforward solutions to OpenID delegation, both of which require some technical facilities. The first—and most common—requires inserting a block of HTML containing the delegation commands on a Web page on the site being del- egated to the OpenID Provider. The second requires adding mes sagingnews.com messagingnews.com 23 23