Hello, 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 fragments. Josh 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 user). 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 specs@openid.net http://openid.net/mailman/listinfo/specs
