I started writing up the use of fragment identifiers for URL-recycling
for the OpenID 2.0 authentication spec, and I ran into some unforseen
challenges. It's not obvious how a relying party should behave when a
URL with a fragment is entered. How should the discovery process work?
How should fragments work with delegation (both as the claimed
identifier and the provider-local identifier)?

After thinking this over for a while, I'm no longer convinced that
using URI fragments as the uniquifying value is the right
approach. Looking at the available options, I think that the best
approach might be to add a uniquifying value to some part of the URL,
in a provider-specific manner. For instance:

  I own <http://josh.myopenid.com/>. I delete my account, and so it
  goes back in the pool of identifers. The next Josh who registers the
  username "josh" at MyOpenID.com gets <http://josh.myopenid.com/1>.

Providers can also provide a redirect from the general form of the
identifier to the current version of the identifier so that users do
not need to remember or type the uniquified version. This is pretty
much equivalent to the fragment scheme, except:

  * It does not require spec changes (and is backwards-compatible!)

  * The uniquifying component is user-visible

I'd like to hear opinions on whether this unique-URL solution is good
enough to solve the problem. If you think it isn't, I'd like
suggestions on how discovery and delegation should interact with


For reference, here's a comparison of the three different approaches
to solving the identifier recycling problem:

1. Using a URI fragment with a uniquifying value:

  * No database changes necessary on the RP (the RP can store the URL
with the fragment as the identifier)

  * Potential problems with initiation and discovery

  * Potential problems with inconsistent behaviours on OpenID 1 sites

  * Comparing identifiers is easy

  * URLs that user see may be ugly or inconsistent across sites (if
    some relying parties do and others do not strip the fragment
    before display)

  * There is no difference between different versions of a
    *user-displayed* identifier (users can't tell if a reference to a
    URL in the wild belongs to the current ownder of a URL or another

2. Adding an extra field with a uniquifying value:

  * Database change required

  * No change in initiation or discovery

  * OpenID 1 sites will behave as they do now

  * Identifier comparison is no longer obvious

  * Display URLs are easy

  * There is no difference between different versions of an identifier

3. Just use different URLs:

  * No database change required

  * No change in initiation or discovery

  * No implementation change at all (just a new best practice)

  * Comparing identifiers is easy

  * Display URLs are easy

  * Users can tell the difference between an old and a new identifier
specs mailing list

Reply via email to