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?

This is known as a hash ID, a unique identifier typically generated from a unique attribute like an entity's primary key in the database. Hash IDs are usually shorter than typical hashes created by cryptographic hashing algorithms such as MD5 or SHA-256 and, unlike these, hash IDs are usually reversible, meaning we can decode the original value. They reduce exposure of your application's internal implementation which can improve security.

Check out hashids.org. This site provides implementations in various programming languages.

Unless you have a good reason to do otherwise, avoid generating the hash IDs in the client. By creating the hash IDs on the server, you can guarantee that the IDs are unique and consistent with identifiers used by whatever mechanism your application stores data through.

Edit for comment - here's the procedure you might follow to use a hash ID in a URL:

Let's assume that we're using hash IDs to create links to user profiles. When we generate a page that contains a link to a profile, our application will:

1. Convert the user ID (ex. 5) to a hash ID (ex. 3ac4jx60)
2. Show the page with a link like http://example.com/user/3ac4jx60

If the site visitor clicks that link, the application will receive the request and:

3. Decode the hash ID in the URL to get the user ID (3ac4jx60 → 5)
4. Use the user ID to fetch the appropriate record and display the user's profile

If you consider that a UUID is essentially just a 128 bits, usually displayed in hex, you can actually convert it quite easily from hex (base16) to a url friendly variant of base64 (e.g. this), making it about 1/4 of the size, but containing the same value. There's some good examples on here for converting regular base64 to a URL friendly variant, just be sure to decode the UUID hex first (or don't! it'll just end up being base64 encoded ascii instead).

this is call seo url you can see some samples here http://davidwalsh.name/htaccess-url