Users vs. Identity Providers in OpenID

Today, there are two discovery flows in OpenID: Directed Identity and Claimed Identity. This is not how they are called in the spec. In fact, they’re not separated in the spec at all (more about this below).

In the Claimed Identity flow, the relying party (RP) knows the user’s identifier (i.e., his or her OpenID URI), and attempts to figure out the OpenID provider (OP) for that user (i.e., the web site that will authenticate the user to the RP).

In the Directed Identity flow, the RP doesn’t know the user’s OpenID, but still figures out the user’s OP endpoint.


RPs use the Claimed Identity flow in two situations:

  1. The user told the RP what their OpenID URI is, and the RP now has to find out where to redirect the user’s browser to start the OpenID authentication.
  2. The RP received an authentication response from the OP, which contained a claimed id for the user. The RP must perform discovery on that claimed id and verify that the OP endpoint obtained from that discovery step is the same as the OP endpoint asserted in the authentication response (this is to make sure that only the OP that the user delegated to can make assertions about this user).

RPs use the Directed Identity flow if they don’t know the user’s OpenID URI, but have some other information about the user that allows them to figure out the user’s OP endpoint. Typically, this is some URL given to the RP by the user (or a button pressed by the user with its OP’s logo), which allows the RP to perform discovery, but is not the user’s OpenID.

We can see that the Claimed Id flow and the Directed Id flow serve quite different purposes.

The thing is, in OpenID 2.0, the RP can’t tell the difference between the two.

In OpenID 2.0, the user gives the RP a URI, and the RP doesn’t know at this point whether this is a user’s identifier (and it can therefore perform the Claimed Id flow), or simply a starting link for a Directed Id flow. Only after the RP fetches the contents of that URL does the RP find out which flow to use. If the document obtained from that URI has a “signon” element, it signals that the URI is, indeed, an OpenID. If the document has a “server” element, it signals that the URI merely pointed to a document that helps find the OP endpoint.

To tease these two distinct discovery flows apart, we need to look at the nature of the identifiers that the user is giving to the RP in each case. In the Claimed Id flow, the RP starts with an identifier for a user. In the Directed Id flow, the RP starts with an identifier for an OpenID Provider. While in OpenID 2.0, this OP identifier comes in a form that makes it indistinguishable from a user identifier, a URI is really not the right way to identify an OpenID provider. URIs identify resources at hosts, not the hosts themselves.

I believe that to make OpenID discovery cleaner, we need to distinguish between user identifiers and provider identifiers. A user identifier is a URI (such as “http://www.myopenid.com/bob”), while a provider identifier simply identifies the provider itself, for example using a DNS name of the provider’s domain (e.g., “myopenid.com”).

We can then re-define the two different discovery flows that an RP has to perform:

  • When given a provider identifier, the RP performs provider discovery. The goal of provider discovery is to start with the provider identifier, and somehow obtain the URI of that provider’s OP endpoint. This happens when the user indicates to the RP only his or her provider, for example, by clicking on a “Log in with Yahoo!” button, or by typing “yahoo.com” into a text box labeled “Your OpenID provider”, and the RP has to redirect the user’s browser to the OP endpoint.
  • When given a user identifier, the RP performs user discovery. This happens when the RP already knows the user’s identifier (i.e., his or her OpenID). The goal of user discovery is to start with a user identifier (OpenID) and somehow obtain the OP endpoint for that user. This happens when the RP already knows the user’s OpenID (perhaps because the user typed it into a text box labeled “Your OpenID”, or becasue the user’s browser sent a cookie with the OpenID to the RP, etc.), and needs to redirect the user to his or her OP endpoint. User discovery must also be performed in the claimed id returned in an authentication response.

In my next article, I will explain how provider discovery and user discovery for OpenID can be performed using the newly-proposed Link-based Resource Descriptor Discovery. Continue reading OpenID and LRDD.