Considering our background, it shouldn't be surprising that when looking at OpenID we do so from a security and privacy perspective...in fact three of our other blogs are related to various security topics. While we have a lot more coming around the Personal Identity Provider related to security, right now I'd like to focus on a new extension to OpenID which is designed to help Relying Parties make informed decisions as to the reliability and strength of an authentication when an OpenID user logs in.

While we may be a security company, and certainly sell high-end solutions to three letter agencies, we also very much take the approach that security must scale with the requirements and associated risk of any transaction. Last year at the Digital ID World conference the former CTO of VeriSign Information Services spoke on a panel and clearly articulated this view; one authentication mechanism is not the solution for every problem.

What becomes painful on the Internet is that if I want varying levels of authentication at different sites, it means I have to remember different passwords, have different certificates, or have multiple physical devices depending on what I'm doing. Thankfully we've been able to help this with the VeriSign Identity Protection network where you can have a single hardware one-time password token and use it at a variety of sites...assuming each site is a part of the network. Overall this is still the fragmented view of the world; each site I visit creates its own password policies (don't even ask me the number of times I've had to call an unnamed bank I use due to forgetting how my two passwords work) as well as needs to choose to integrate with the VIP network for me as the consumer to benefit. So now how does this change in the decentralized world of OpenID?

The integration cost of OpenID as a Relying Party is extremely low, the technology is free and as Brian Ellin and I showed at Web 2.0 Expo the time commitment is also low due to a lot of great Open Source code out there which takes care of the heavy lifting. So now the RP has successfully integrated OpenID and removed the need for new users to create yet another password for their site, though they no longer have the control over the strength of a user's authentication process. The RP may be a simple Web 2.0 site and not care beyond that the user has a password, it may store marginally sensitive information and want to make sure that the Provider did something to help protect the user from common phishing attacks, or maybe it's a site which has truly sensitive information and wants to make sure that a second-factor device, such as a VIP token, was used.

With the OpenID Provider Authentication Policy Extension that I just published, this is now possible. This extension to OpenID 1.1 and 2.0 allows Relying Parties to express preferences around the authentication, such as "use technology which is phishing resistant" (stemming from the collaboration announcement at the RSA conference earlier in the year), for the Provider to inform the user of the request, guide them through the authentication process, and then inform the Relying Party what happened. By taking advantage of existing specifications from the likes of the National Institute of Standards and Technology (NIST), Providers can also convey information as to the strength of a password or combination of a password and digital certificate or hardware device used. While the high-end of the specification may be beyond the uses of OpenID today, it certainly fulfills the scalable security vision that we have. Through this specification not only can I now strongly protect my OpenID identity, but let others know that I'm doing so and truly take advantage of a reduction in credentials needed when browsing the web.

So please, take the time to read over the specification and chime in on specs@openid.net if you have any feedback.