Specifying identifier recycling

Dick Hardt dick at sxip.com
Sun Jun 3 11:17:57 UTC 2007


A little late to the conversation, but some comments inserted as I  
did not see them all in any other aspect of this thread ...

On 30-May-07, at 10:28 PM, Josh Hoyt wrote:

> 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?

The user does not use the fragment. If they do type it in, the RP can  
strip it.

> How should fragments work with delegation (both as the claimed
> identifier and the provider-local identifier)?

Not sure there is an issue here. Can you elaborate?

>
> 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

the user now has to enter something that is not as memorable -- there  
is little difference between http://josh.myopenid.com/1 and http:// 
josh1.myopenid.com/

Your approach does not solve the recycling problem.

>
> 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

The user types in the memorable part of the URI, and not the fragment.

>
>   * Potential problems with inconsistent behaviours on OpenID 1 sites

We discussed this at IIW and the consensus was that we would just  
have to get them to upgrade. Many of them will not allow the user to  
enter an i-name or OP currently anyway.

>
>   * 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

ISSUE: The new user of the identifier will get access to the old  
user's account.

>
>
> 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


ISSUE: URIs are not being recycled





More information about the specs mailing list