Along with Internet development, some of the traditional actions have been implemented into the virtual space. Nowadays, we do not use paper and pen to send a letter, we email messages; we do not socialize only face to face, we also use Facebook, Twitter or Hi5. We have now access to an extremely fast method of sharing information. For all these technologies we have unique accounts that enable others to recognize our identity. Many accounts mean a lot of user names and passwords that we need to remember in our every day virtual world.

What if we could have only one identity that logs us once into all web sites where we have an account?

The original OpenID authentication protocol was developed in May 2005 by Brad Fitzpatrick, while working at Six Apart project. Initially, the authentication protocol was called Yadis (an acronym for Yet another distributed identity system 😀 ), but it was named OpenID after the openid.net domain name was given to Six Apart for the project. OpenID support was soon implemented on LiveJournal and quickly gained attention in the digital identity community. The result of the collaboration between OpenID users and developers was Yadis discovery protocol, which adopted the original name given to OpenID. Yadis was announced on October 24, 2005.

Now, there are many OpenID providers like Google, Yahoo!, LiveJournal, VeriSign, MySpace, WordPress, Blogger, Typepad, MyOpenID, claimID, Google Profile, Steam, Orange, TonidoOpenID, Launchpad.

As a service provider (or even non related business) you can also become an OpenID provider by installing a free OpenID server.

How Secure Is OpenID?

For those new to OpenID, the idea is simple. After creating an account with an OpenID provider, you are given an unique identifier (a custom URL), which you will use to log in to and register with sites that support OpenID (“consumers”, as they are named).

The security issues with OpenID exist due to browser/HTTP/web characteristics or to implementation and deployment practices. The browser is considered by default man-in-the-middle because messages are vulnerable when transiting the browser. Some observers have suggested that OpenID may prove vulnerable to attacks. For example, a malicious relying party may forward the end-user to a bogus identity provider authentication page asking the credentials and next using them.

In an attempt to combat possible phishing attacks some OpenID providers require end-user to authenticate with them prior to an attempt to authenticate with the relying party. This relies on the end-user knowing the policy of the identity provider. Regardless, this issue remains a significant additional vector for phishing attacks.

How to Use OpenID in VoipNow

VoipNow Professional’s OpenID implementation is compatible with a lot of OpenID providers. Some of the most important are below:

• Yahoo
• Google
• Google Profile
• Google Apps
• WordPress
• LiveJournal

Let’s suppose that you have a Google Profile username called “jenny”. In order to use this identity for authentication, go to the Unified Communications -> Global account -> OpenID Settings page and select the Google Profile provider. As Google Profile is one of the default OpenID providers, it is already configured.

Next, you have to add the OpenID identity linked to Google Profile that will be used to connect you to your VoipNow Professional account. Every VoipNow Professional account has an OpenID Identities button. Click this button and then use the displayed pop-up window to link your “jenny” OpenID. For the Provider choose Google Profile and next fill the OpenID account with your OpenID, “jenny”.This way, when you will log into your provider’s site, you will be also logged in your VoipNow Professional account.

But how is this done? The end-users interact with the relying party (an website or a browser application) and have previously registered an OpenID (e.g. jenny.openid.provider.org) with an OpenID provider (e.g. openid.provider.org). The relying party typically transforms the OpenID into a canonical URL form (e.g. http://www.google.com/profiles/jenny/).

If OpenID 1.0 is used by the relying party, then the website requests the HTML resource identified by the URL and reads an HTML link tag to discover the OpenID provider’s URL (e.g. http://openid.provider.org/openid-auth.php ). If OpenID 2.0 is used by the relying party, the client discovers the OpenID provider’s URL by requesting the XRDS document (also called the Yadis document) with the content type application/xrds+xml; this document may be available at the target URL and it is always available for a target XRI.

After the OpenID has been verified, authentication is considered successful and the end-user is considered logged into the relying party under the identity specified by the given OpenID (e.g. jenny.openid.provider.org). The relying party typically then stores the end-user’s OpenID along with his other session information.

If an OpenID provider uses strong authentication, then OpenID can be used for secure transactions such as e-banking and e-commerce.