Claimed Identifier URL is the URL that an end user provides to a relying party (consumer) during the OpenID authentication process, asserting ownership of that identifier. It is not yet verified and may not be unique across users of the same OpenID provider.

  • It is typically a general or delegate URL, such as https://www.google.com/accounts/o8/id, which serves as a common entry point for multiple users.

  • The claimed identifier is not unique—multiple users can use the same claimed identifier URL if they are registered with the same OpenID provider.

  • The actual unique identity is determined during authentication through the Verified Identifier URL, which is generated by the Identity Provider (IdP) and is specific to the user and the relying party's realm (e.g., https://www.google.com/accounts/o8/id?id=AltOawk...).

  • The OpenID protocol uses the claimed identifier to initiate the authentication flow, and the IdP then redirects to a unique verified identifier for cryptographic proof.

In short: The claimed identifier is a user’s assertion of identity, while the verified identifier is the unique, cryptographically proven identity used by the relying party.

AI-generated answer. Please verify critical facts.
Top answer
1 of 3
5

Ok, as I just have fixed my SMF OpenID endpoint implementation (read details about some very related problems I had here) where I made a few assumptions on those relations. Of course that doesn't prove them right (so please correct me). Here they are:

  • Identifier URL = OpenID endpoint URL = IdP

  • The OpenID endpoint is not unique. It is the same for all end users of that endpoint.

  • Verified identifier URL = identity

  • Verified identifier URL is unique. It is associated to the endpoint user account.

  • https://www.google.com/accounts/o8/id is the Google OpenID endpoint URL.

  • https://www.google.com/accounts/o8/id?id=AltOawk... is the Google OpenID verified identifier URL.

  • The hash the Google OpenID identity URL contains is also related to the OpenID realm (the consumer domain namespace where this OpenID identifier stays valid). That is one of the reasons to not be just the username.

  • About how to provide the unique verified identifier URL, see here.

Still some things remain unclear to me:

  • What other reasons are there that Google uses for the hashed id; it could have also used id?u={username}&oidrealm={...}.

  • What is the reason to have such OpenID realm at all?

  • What exactly is the difference between identifier URL and claimed identifier URL?

2 of 3
2

Here is my understanding. I am actually just answering the last two questions in your own answer. Hope someone finds these useful.

What is the reason to have such OpenID realm at all?

The realm is used for security. Basically the return_url is checked against the realm, and OpenID specs say they MUST match. Google has taken this one step further, and provides unique verified identifiers for each realm. They might have done as you suggested, and put the realm back in their identifier, but then you could tell by looking at two verified identifiers whether they were the same end-user or not. I think they are trying to keep their identifiers free of identifying information. (ironic, no?)

What exactly is the difference between identifier URL and claimed identifier URL?

The claimed identifier is the one the end-user has specified. This is not their unique identifier. Yahoo is a good example of this. They allow you to specify yahoo.com as your identifier, log into your yahoo account, and return a unique identifier to the openid consumer. This just simplifies the process for the end-user. (And increases the likelihood that they'll use yahoo.com as their openid!)

Find elsewhere