OpenID

From DocForge

OpenID is a shared identity service, which allows internet users to log on to many different web sites using a single digital identity, single sign-on, eliminating the need for a different user name and password for each site. OpenID is a decentralized, free and open standard that lets users control the amount of personal information they provide.

An OpenID is in the form of a URL (Uniform Resource Locator). This URL can be the domain name of your own website, or the URL of an OpenID Identity Provider. When you log in with an OpenID, you have to log in to the Identity Provider for validation.

Using OpenID-enabled sites, web users do not need to remember traditional items of identity such as username and password. Instead, they only need to be registered with any OpenID "identity provider" (IdP). Since OpenID is decentralized, any website can use OpenID as a way for users to sign in; OpenID does not require a centralized authority to confirm a user's digital identity.

A service provider offering the service of registering OpenID URLs or XRIs and providing OpenID authentication (and possibly other identity services). Note that the OpenID specifications use the term "OpenID provider" or "OP".

Relying party

The site that wants to verify the end user's identifier. Sometimes also called a "service provider".

Server or server-agent

The server that verifies the end user's identifier. This may be the end user's own server (such as their blog), or a server operated by an identity provider.

User-agent

The program (such as a browser) that the end user is using to access an identity provider or a relying party.

A relying party web site displays an OpenID login form somewhere on the page. Unlike a typical login form with fields for the user name and password, the OpenID login form has only one field - for the OpenID identifier, typically along with a small OpenID logo. This form is connected to an implementation of an OpenID client library.

A user typically will have previously registered an OpenID identifier with an OpenID identity provider. The user visits the relying party web site and types her OpenID identifier in the OpenID login form.

The relying party web site typically transforms the OpenID identifier into a canonical URL form (e.g. http://docforge.com/wiki/User:Me). With OpenID 1.0, the relying party then requests the web page located at that URL and reads an HTML link tag to discover the identity provider service URL. The relying party also discovers whether to use a delegated identity (see below). With OpenID 2.0, the client discovers the identity provider service URL by requesting the XRDS document (also called the Yadis document) with the content type application/xrds+xml that may be available at the target URL and is always available for a target XRI.

There are two modes in which the relying party can communicate with the identity provider:

checkid_immediate, in which the relying party requests that the provider not interact with the user. All communication is relayed through the user's browser without explicitly notifying the user;

checkid_setup, in which the user communicates with the provider server directly using the same web browser used to access the relying party site.

The second option is more popular on the Web; also, checkid_immediate can fallback to checkid_setup if the operation cannot be automated.

First, the relying party and the identity provider (optionally) establish a shared secret - referenced by an associate handle, which the relying party then stores. If using checkid_setup, the relying party redirects the user's web browser to the identity provider so the user can authenticate with the provider.

The method of authentication may vary, but typically, an OpenID identity provider prompts the user for a password or an InfoCard, then asks whether the user trusts the relying party web site to receive her credentials and identity details.

If the user declines the identity provider's request to trust the relying party web site, the browser is redirected to the relying party with a message indicating that authentication was rejected. The site in turn refuses to authenticate the user.

If the user accepts the identity provider's request to trust the relying party web site, the browser is redirected to the designated return page on the relying party web site along with the user's credentials. That relying party must then confirm that the credentials really came from the identity provider. If they had previously established a shared secret (see above), the relying party can validate the shared secret received with the credentials against the one previously stored. Such a relying party is called stateful because it stores the shared secret between sessions. In comparison, a stateless or dumb relying party must make one more background request (check_authentication) to ensure that the data indeed came from the identity provider.

After the OpenID identifier has been verified, OpenID authentication is considered successful and the user is considered logged in to the relying party web site with the given identifier. The web site typically then stores the OpenID identifier in the user's session.

OpenID does not provide its own form of authentication, but if an identity provider uses strong authentication, OpenID can be used for secure transactions such as banking and e-commerce.

Starting with OpenID Authentication 2.0 (and some 1.1 implementations), there are two types of identifiers that can be used with OpenID: URLs and XRIs.

There are two ways to obtain an OpenID-enabled URL that can be used to login on all OpenID-enabled websites.

To use an existing URL under one's own control (such as one's blog or home page), and if one knows how to edit HTML, one can insert the appropriate OpenID tags in the HTML code following instructions at the OpenID specification.

The second option is to register an OpenID identifier with an identity provider. They offer the ability to register a URL (typically a third-level domain) that will automatically be configured with OpenID authentication service.

XRIs are a new form of Internetidentifier designed specifically for cross-domain digital identity. For example, XRIs come in two forms—i-names and i-numbers—that are usually registered simultaneously as synonyms. I-names are reassignable (like domain names), while i-numbers are never reassigned. When an XRI i-name is used as an OpenID identifier, it is immediately resolved to the synonymous i-number (the CanonicalID element of the XRDS document). This i-number is the OpenID identifier stored by the relying party. In this way both the user and the relying party are protected from the user's OpenID identity ever being taken over by another party as can happen with a URL based on a reassignable DNS name.

The OpenID trademark in the United States was assigned to the OpenID Foundation in March 2008.[1] It had been registered by NetMesh Inc. before the OpenID Foundation was operational.[2][3] In Europe, as of August 31, 2007, the OpenID trademark is registered to the OpenID Europe Foundation.[4]

The OpenID logo was designed by Randy "ydnar" Reddig, who in 2005 had expressed plans to transfer the rights to an OpenID organization.[5] The official openid.net domain is registered to Six Apart, which was granted by the previous owner David I. Lehn,[6], and the rights of which were officially transferred on June 16, 2005.

The official site currently states:

Nobody should own this. Nobody's planning on making any money from this. The goal is to release every part of this under the most liberal licenses possible, so there's no money or licensing or registering required to play. It benefits the community as a whole if something like this exists, and we're all a part of the community.

Sun Microsystems, VeriSign and a number of smaller companies involved in OpenID have issued patent non-assertion covenants covering OpenID 1.1 specifications. The covenants state that neither company will assert any of their patents against OpenID implementations and will revoke their promises from anyone who threatens, or asserts, patents against OpenID implementors."VeriSign's OpenID Non-Assertion Patent Covenant", VeriSign. Retrieved on 2008-03-20.</ref>

Some observers have suggested that OpenID has security weaknesses and may prove vulnerable to phishing attacks.[7][8]

For example, a malicious relying party may forward the end-user to a bogus identity provider authentication page asking that end-user to input their credentials. On completion of this, the malicious party (who in this case also control the bogus authentication page) could then have access to the end-user's account with the identity provider, and as such then use that end-user’s OpenID to log into other services.

In an attempt to combat possible phishing attacks some OpenID providers mandate that the end-user needs to be authenticated with them prior to an attempt to authenticate with the relying party. However this then relies on the end-user knowing the policy of the identity provider, and regardless this issue remains a significant additional vector for man-in-the-middle phishing attacks.

Other criticisms are that the addition of a third-party (the identity provider) into the authentication process significantly adds complexity and therefore possibility of vulnerability into the system. Also this system shifts responsibility for "quality" of authentication to the end-user (in their choice of identity provider), a shift that the end-user and the relying party (for example their bank) need to understand.

Additional copyright notice: Some content of this page is a derivative work of a Wikipedia article under the CC-BY-SA License and/or GNU FDL. The original article and author information can be found at http://en.wikipedia.org/wiki/OpenID.