OpenID

From Wikipedia, the free encyclopedia

You have new messages (last change).
To comply with Wikipedia's lead section guidelines, the introduction of this article needs a complete rewrite.
Please discuss this issue on the talk page and read the layout guide to make sure the section will be inclusive of all essential details.

OpenID is a decentralized system to verify one's online identity. While it is not intended to prevent spam or create a trust metric,[1] it solves the single sign-on problem without relying on any centralized website to confirm digital identity. OpenID users identify themselves with a URI or XRI which they own, such as for a blog or a home page. Since OpenID is decentralized, any website can employ OpenID software as a way for users to sign in.

On OpenID-enabled sites, Internet users do not need to register and manage a new account for every site before being granted access. Instead, they only need to be previously registered on a website with an OpenID "identity provider", sometimes called an i-broker. They can also link to this identity provider from another website they own and log in using that website's URI instead, allowing them to connect their identity to their website. A website which accepts sign-ins from OpenID is called a "relying party."

OpenID is increasingly gaining adoption amongst large sites, with organizations like AOL acting as a provider. In addition, integrated OpenID support has been made a mandatory priority in Firefox 3[2] and Microsoft is working on implementing OpenID 2.0 in Windows Vista.[3]

OpenID does not provide its own form of authentication, so it is not meant to be used on sensitive accounts (banking, e-commerce transactions, etc.), but if an identity provider uses strong authentication, OpenID can be used for all types of transactions.

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

Contents

[edit] Development

OpenID was originally developed by Brad Fitzpatrick of LiveJournal, but the term now also includes the Light-Weight Identity, Yadis, Sxip DIX protocol that was proposed at IETF, and OASIS XRI/i-names. Future OpenID specifications are being developed in a meritocratic fashion on openid.net, involving many technology companies, user companies and open-source developers.

To help spawn additional deployment, a group of vendors announced a $50,000 USD developer bounty program in August of 2006, offering $5,000 USD each to the first ten large-scale Open Source projects to implement OpenID support.[5]

Starting with version 1.1, OpenID uses the Yadis service discovery protocol. Currently work is underway developing OpenID Authentication 2.0, though OpenID is now developing into a much more complete framework that will support other identity services besides authentication.

[edit] Notable providers and relying parties

Two major identity providers online, AOL and Yahoo!, can currently be used with OpenID. AOL's system, using openid.aol.com/username, is currently in beta. Yahoo has unofficial, third-party OpenID support at idproxy.net.

Websites which use OpenID as an alternative to registration include LiveJournal, Zooomr, Wikitravel, ma.gnolia.com, claimid.com, Highrise (by 37signals), and Jyte.

There is a list of public servers on which someone may get an OpenID at openid.net.

[edit] Trademark issues

R-Objects Inc. filed for the OpenID trademark (serial 78899244) on 2 June 2006[6] which was published for opposition on 9 January 2007, claiming a first use date of 17 May 2005 and a first use in commerce date of 18 April 2006. Sxip Identity Corporation subsequently filed for the OpenID trademark (serial 77041930) on 11 November 2006[7] but abandoned it on 23 November 2006[8]. Randy "ydnar" Reddig claimed ownership of the OpenID logo on 29 June 2005 and announced plans to transfer it to Six Apart (or some OpenID.org).

There is a pending USPTO patent application with PCT priority from Denmark of March 9 2001 that covers the central aspects of OpenId.

Six Apart Ltd. are the registrant for the 'official' openid.net domain, which was transferred from David I. Lehn on 16 June 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.

[edit] Terminology

A basic glossary of the terms used with OpenID:

  • consumer — An obsolete term for the relying party.
  • end user — The person who wants to assert his or her identity to a site.
  • identifier — The URL or XRI chosen by the End User as their OpenID identifier.
  • identity provider or OpenID provider— 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.
  • 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.

[edit] How OpenID works

A website, such as example.com, which wants to enable OpenID logins for its visitors, places a login form somewhere on the page. Unlike a typical login form, which prompts the user for a user name and password, there is only one field - for the OpenID identifier. The site may choose to display a small OpenID logo next to the field. This form is connected to an implementation of an OpenID client library.

If a user named Alice wants to log in to example.com using the OpenID identifier alice.openid-provider.org that she has registered with the identity provider openid-provider.org, she simply goes to example.com and types alice.openid-provider.org in the OpenID login box.

If the identifier is a URL, the first thing the relying party (example.com) does is transform into a canonical form, e.g., http://alice.openid-provider.org/. With OpenID 1.0, the relying party then requests the web page located at that URL and, via an HTML link tag, discovers that the provider server is, say, http://openid-provider.org/openid-auth.php. It also discovers whether or not it should use a delegated identity (see below). Starting with OpenID 1.1, the client does discovery 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, which is machine-oriented and in which all communication between the two servers is done in the background, without the user's knowledge;
  • checkid_setup, in which the user communicates with the provider server directly using the very 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 provider (optionally) establish a shared secret - an associate handle, which the relying party then stores. If using checkid_setup, the relying party redirects the user's web browser to the provider. In this case, Alice's browser is redirected to openid-provider.org so Alice can authenticate herself with the provider.

The method of authentication may vary, but typically, an OpenID provider asks for a password (and then possibly stores the user's session using cookies, as many websites with password-based authentication do). Alice may be prompted for her password if she was not logged in on openid-provider.org, and then asked whether she trusts, say, http://example.com/openid-return.php - the page designated by example.com as the one where the user should return after completing authentication - to receive details about her identity. If she answers positively, OpenID authentication is considered successful and the browser is redirected to the designated return page with credentials given. If Alice decides not to trust the relying party site, the browser is still redirected - however, the relying party is notified that its request was rejected, so example.com refuses to authenticate Alice in turn.

However, the login process is not over yet because at this stage, example.com cannot decide whether the credentials received really came from openid-provider.org. If they had previously established a shared secret (see above), the consumer can validate the shared secret received with the credentials against the one previously stored. Such a consumer is called stateful because it stores the shared secret between sessions. In comparison, a stateless or dumb consumer must make one more background request (check_authentication) to ensure that the data indeed came from openid-provider.org.

After Alice's identifier has been verified, she is considered logged in to example.com as alice.openid-provider.org. The site may then store the session or, if this is her first logon, prompt Alice to enter some information specific to example.com, in order to complete registration.

[edit] OpenID identifiers

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.

[edit] URLs

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

  1. To use an existing URL that 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.
  2. 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.

[edit] XRIs

XRIs are a new form of Internet identifier 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.

[edit] References

  1. ^ About OpenID
  2. ^ Current Firefox 3 Requirements on the Mozilla Wiki
  3. ^ The Register: “Gates: protect Windows Vista users with IP” (6 February 2007)
  4. ^ Anderson, Tim. "OpenID still open to abuse", IT Week, 2007-03-05. Retrieved on 2007-03-13.
  5. ^ bounty sponsors
  6. ^ Application #78899244 on uspto.gov
  7. ^ Application #77041930 on uspto.gov
  8. ^ Notice of Abandonment for application #77041930 on uspto.gov

[edit] See also

[edit] External links

The external links in this article may require cleanup to comply with Wikipedia's content policies.
Please improve this article by removing excessive or inappropriate external links. Please remove this tag when this is done. (talk)
Retrieved from "http://en.wikipedia.org../../../o/p/e/OpenID_10d8.html"