Dev411 Blog

There has been a lot of talk about OpenID so I decided to take a look at it and think about some of the potential issues with respect to broad adoption and integrating it into a website as a relying party. There have been numerous attempts to either improve the security of authentication via the web or improve the usability with SSO (Single Sign-On) including client SSL, OTP tokens, USB tokens, AmEx Blue smart cards, Microsoft Passport, Verified by Visa, etc. Many of these had SSO capabilities but none has been able to supplant local passwords. It will be interesting to see if OpenID can succeed where these others have failed. Here are my thoughts after watching two screencasts but before following the mailing lists. I'm now reading the list archives and it seems a number of similar issues are being discussed.

Provider Types

The decentralized nature of OpenID means anyone can be a Provider and because the Provider is entrusted with performing the authentication, it is important to trust the provider. Here's my way of classifying Providers.

1. Tier 1 Provider: These are organizations that have good reputations and perform initial identity verification in a manner that is not often subject to identity theft. Banks and brokerages qualify. At bricks and mortar banks, you often appear in person and provide identification via a physical national or state/provincial government ID. At a brokerage you have to invest money which many thieves aren't willing to do (though some are). These organizations will have known domain names and employ a method of authentication in the response such as TLS/SSL.
2. Tier 2 Provider: These are organizations that have good reputations but base identity verification on anonymous information or information that is subject to identity theft. Examples of anonymous information include website urls and email addresses. Examples of information subject to identity theft include using a credit card for $1 auth verification. Response authentication via TLS/SSL or other crypto mechanism is not required here.
3. Tier 3 Provider: These are organizations that have low or unknown reputation.

OpenID Assurance Levels

Given the sophistication of phishing and pharming combined with the propensity of Internet users to succumb to such attacks, there is a real need for higher assurance authentication, especially since this is a SSO (Single Sign-On) system. One way to think about assurance levels can be qualify OpenID solutions by the level of authentication employed and the reputation of the OpenID provider. The latter is needed given the third-party authenticator architecture.

1. High-Assurance OpenID: A high-assurance OpenID is one that uses strong, aka two-factor, authentication issued by a Tier 1 Provider. For example, a two-factor hardware token issued by an e-banking or e-brokerage company can be considered high-assurance because the authentication method is strong and you can trust the provider confirming the authentication. A cell phone with OpenID password may also qualify. In this case, two-factor authentication is achived by requiring the user to enter their OpenID and password before their registered cell phone is text messaged with an authentication key. The reason a Tier 1 Provider is needed in addition to strong authentication is due to the third-party nature of the authentication. An untrusted provider can simply skip strong authentication while claiming to do so. Because of this, only OpenIDs issued by trusted Providers that use strong authentication may qualify as high-assurance.
2. Medium-Assurance OpenID: These are weaker authentication solutions but where the user should notice the compromise quickly. Cell phone authentication using text messaging without requiring a password is one example. Although losing one's cell phone will compromise the account, theoretically the person will realize their cell phone has been lost before they realize a password has been compromised. So while both are considered single-factor in the traditional authentication sense, one compromise is more difficult achieve and easier to detect than the other. OpenID providers should be somewhat well known but may not be the largest organizations with the most stringent procedures.
3. Low-Assurance OpenID: These are weak authentication solutions or from unknown OpenID providers. Username/password based OpenIDs are low-assurance, regardless of the provider. Strong authentication paired with an unknown OpenID provider cannot be trusted to have actually occurred so these are also low-assurance.

Relier Types

Now that we have a framework for understanding the types of OpenIDs, let's look at the OpenID relying parties to see what kind of OpenID each relier type would prefer. Reliers can be classified by the type of information they hold for the OpenID end user. Depending on the sensitivity of information, users may prefer one level of OpenID vs. another.

1. Sensitive Information: e-banking and e-brokerage. These organizations will most-likely not rely on OpenIDs issued by other organizations but it's possible for them to issue hardware token authenticated OpenIDs that can then be used by other relying sites independent of the issuer (except for the load on the issuer's OpenID authentication servers). E*Trade and other organizations have already issued hardware authentication tokens to their users. It wouldn't be overly difficult to leverage those tokens for an OpenID provider service if there was enough business justification.
2. Important Information: online identities. There are many social networking and community websites where a person's online identity is very important for personal and reputation perspectives but there's no financial or other sensitive information at stake. Users and owners of these sites may also want high-assurance OpenID if they are going to place faith in a third-party OpenID provider. However, because the information on these sites is not that sensitive, few of these sites may be willing to issue expensive hardware-based high-assurance OpenIDs. OTOH, these sites may be willing to rely on High-Assurance OpenID issued by Tier 1 Providers. Perhaps these sites can provide some kind of incentive to potential Tier 1 Providers to convince them to move their existing hardware token authentication methods to OpenID. Like their local username/passwords today, these sites can also participate in OpenID by issuing their own Low-Assurance OpenIDs.
3. Unimportant Information: blog comments. Today some sites require users to authenticate themselves to post blog comments but others don't. Presumably the ones that don't require any authentication will not mind switching to low-assurance OpenIDs though the benefit is somewhat elusive.

Given that some types of Relying Parties may require different assurance levels for OpenIDs, it makes sense to have some local filtering rules (white lists, black lists, etc.) on which OpenID providers to allow and which to disallow. Something like this is already happening on a simple level at OpenID relier websites that only recognize OpenIDs they issued themselves (many, if not most or all, of the larger OpenID reliers?). While these sites have deployed OpenID, they are not allowing use of any externally issued OpenIDs. This may defeat the purpose of OpenID but it could be because no other issuers are issuing OpenIDs of high enough assurance for them to rely on.

OpenID growth may be slowed due to lack of recognition if the larger OpenID Relying Parties continue to recognize only OpenIDs they issued themselves. For example, if two large websites are issuing OpenIDs, A and B, and A does not recognize B's OpenIDs, there may be no incentive for B to pre-emptively recognize A's OpenIDs. In this case, both A and B's OpenIDs may effectively remain "CloseIDs."

It could be beneficial to have the Provider return the authentication type/level in the OpenID response so the Relying Party can decide whether the assurance level is high enough for the requested resource. This may only work with Tier 1 or 2 OpenID Providers since a Provider can return anything here so you need some level of reliance. The known/trusted providers can be placed in a local white list.

Relier Considerations: User Experience

Some considerations for a pleasing end user experience.

1. Redirect experience: the basic user experience presented is to have the relying site redirect to the provider site which then redirects back to the relying party site. This might be ok for early adopters but it's questionable whether the masses will accept this type of redirect authentication. Visa's Verified by Visa tried this approach, then switched to pop-ups to provide some continuity in the user experience, and then switched to iframes in the relying party site after pop-ups proved problematic with pop-up blockers. I'm skeptical whether the average Internet user will accept a redirect and think it may be up to the browser providers to create a better user experience. It will be interesting to see how Firefox 3 handles OpenID authentication.
2. Redirect branding: one way to improve the redirect experience is to brand the OpenID Provider's authentication page with the Relying Party's logo to add some continuity to the user experience. Today a user doesn't mind being redirected from groups.yahoo.com to login.yahoo.com and back to groups.yahoo.com again because the branding is consistent. The domain is also the same but how many Yahoo users check? To do this, a logo URI can be included in the OpenID request for the OpenID Provider to embed in the login page. This will be more doable if sites choose which OpenID Providers to recognize, creating some incentive for OpenID Providers to assist in creating a better end user experience.
3. Redirect to unresponsive site: no recovery is possible with a straight redirect to a site that is either dead or having temporary difficulties. A frame could solve this issue but that could create an opening in the user experience for phishers to take advantage of. A list of dead or unresponsive sites is useful so these can be avoided. This list can either be created/managed centrally or locally and kept up to date with periodic pings to the server. It might be more efficient for the Relying Party to ping the servers that are supposed to be live. The ping can happen immediately before redirecting the user or can be done periodically to reduce load on the authentication server, say every 5 to 15 minutes.
4. Remember me: when a user's session ends on the relying party site, the site can remember the user's OpenID in addition to the username so the OpenID will already be populated with a redirect to the Provider site.
5. Short names: if the relying party has issued their own OpenIDs, they can append their domain name automatically for local verification so the user doesn't have to type as much. For sites that recognize more than one Provider, there can be a select list for a limited number of providers or an auto-complete for a large list.

Relier Considerations: Captive OpenIDs

Captive OpenIDs are ones that are issued by and relied upon by a single site without even letting anyone know OpenID is being used. The benefit is SSO across all of a organization's servers and partners. Some multi-host websites today use a separate host, http://login.$domain.com, to handle authentication. OpenID can be easily leveraged to create that type of solution without having the user redirected to an outside site, go through multiple pages to authenticate or type long OpenIDs. The UI can be exactly the same as username/password on a single page today because the relier is the same organization and thus trusted.

Today the site will get SSO across their sites, with the same domain or not. In the future, additional OpenID Providers can be recognized or the organization can become a public OpenID Provider themselves. Underneath, a single authentication method is used for authentication internally or to exteral Providers to reduce the level of effort in the future.

Conclusion

There does not appear to be enough higher-assurance Tier 1 and 2 OpenID Providers to convince larger websites to recognize any Providers other than themselves, preventing the OpenID system from realizing its idealized potential. Because those sites refuse to recognize OpenIDs issued by others, there may be a negative feedback loop where other sites are reluctant to recognize their OpenIDs. Part of this is that the OpenIDs issued today tend to be Low-Assurance OpenIDs. If larger sites require Medium or High-Assurance OpenIDs from third-party Providers, then we may have to wait for a reputable provider to use two-factor authentication such as hardware tokens cell phones with passwords and text messaging to come on the scene.

Until High-Assurance OpenIDs become available, issuing one's own OpenIDs may be the way to go to get the SSO benefits across your own sites today while preparing for the future when it makes more sense to rely on OpenIDs issued by others. The OpenIDs can be marketed as such to generate more discussion or the OpenID nature of the authentication can be hidden until it makes sense to discuss it.