Summary

  • OpenID Authentication 2.0 separated the URL a person claimed as an identifier from the provider-local account used to authenticate them. A user-controlled URL could point to a different provider without changing the identifier another site stored.
  • That portability depended on the relying site discovering the provider from the claimed URL, checking the assertion against that discovery and using the claimed identifier as its account key. The specification recorded the mechanism in December 2007, not a count of sites that implemented it correctly.

The address was the point. In the final OpenID Authentication 2.0 specification, a person could present a URL as the name by which another website knew them. The site did not need to receive that person's password. It followed the URL's discovery information to an OpenID Provider, sent the browser there for authentication, then checked the answer. OpenID's 5 December 2007 final-specification announcement named this protocol alongside an attribute-exchange specification. The durable idea lay in the first: an online name and the business checking it could be separate things.

The spec used two names for a reason. The Claimed Identifier was the identity the user asserted to the relying site. The OP-Local Identifier was a name inside the provider's system; it might not be under the user's control. If a site quietly substituted the provider-local name for the claimed one in its account database, changing providers could change the name it thought belonged to the user. The portability promise rested on keeping those fields apart.

HTML discovery made the separation concrete. The web page at the claimed URL could carry a link with rel="openid2.provider" pointing to the provider's endpoint. A second, optional link with rel="openid2.local_id" could specify the user's local identifier there. The host serving the claimed URL could differ from the provider's host. A person controlling the claimed page could update its pointer to a different provider while keeping the URL presented to relying sites. The user did not have to persuade each site to rename its local account, provided those sites used the claimed URL as the account key.

That last condition is the expensive one hidden behind an easy login button. The specification says a relying party must verify that the claimed identifier in a positive assertion was discovered and that the provider endpoint and local identifier in the assertion match the discovered information. If the relying party had not already performed discovery, it had to do so on receipt. Otherwise any provider could pretend to speak for someone else's URL. The claimant's page supplied the map; the relying site had to check that the messenger came from the destination on that map.

OpenID also told relying parties what to remember. A successful assertion's claimed identifier should be used as the key for local information about the user. That recommendation protected continuity when the provider changed. Compatibility with OpenID 1.1 exposed the same issue more sharply: because a 1.1 response did not carry openid.claimed_id, a relying site handling different claimed and provider-local identifiers had to retain the claimed identifier it used for discovery, for example in session state. The protocol could route authentication elsewhere; the accepting site's bookkeeping still determined which account opened.

This was a decentralization claim with an operating bill. The final specification said no central authority had to register or approve providers or relying parties, and a user could keep an identifier while changing providers. That was a design property, not evidence that every site made migration painless. Control of the claimed URL mattered. So did correct discovery, assertion verification and account storage at each relying party. Losing the URL, or letting a site bind the account to a provider-local name, would break the path the standard drew.

The historical wager was precise: let users hold the stable name while services compete to perform the credential check. That gave a person an exit from one authentication company without forcing every relying site to forget who they were. It also refused the comforting fiction that a protocol can make continuity happen by itself. The URL owner supplied the pointer. The provider authenticated. The relying site decided whether the answer was authorised and which local account it reached.

Original records