[OpenID] Relying Party Best Practices
kra at monkey.org
Fri Mar 9 00:55:52 UTC 2007
Martin Atkins <mart at degeneration.co.uk> writes:
> Simon Willison wrote:
>> That's a really great list. I have one query about it:
>> - Many-to-one relationship between Identity URLs and "user accounts"
>> - Don't require users to choose locally-unique usernames
>> These appear to be conflicting recommendations. For the second one,
>> you advocate using the OpenID identifier as the primary identifier for
>> a user, but in the first you emphasize that a user account should be
>> able to have more than one OpenID associated with it. Even if you ask
>> the user to select their "primary" OpenID you still run in to problems
>> should they later ditch that one in favour of another. This could
>> definitely be clarified.
> I think I see where you're coming from here. I don't really think the
> two items you've called out here are necessarily in conflict (see John
> Panzer's reply) but once you bring "Allow, but do not require, users to
> attach a handle or name to their identity" into the equation it's a bit
> ambiguous, because that recommendation states that *the* (singular)
> OpenID identifer should be displayed alongside the non-unique display name.
> Jyte handles this by asking the user to select a primary identifier as
> you say. However, you're right that if this is not handled carefully
> problems could arise if a different identifier is switched to primary
> later. I'm not sure what effect that has on Jyte today, but I think Jyte
> is in some ways a model for many of these "Brilliant" requirements.
Being flexible with identity URLs implies that they can't be used as
persistent handles. I would add another Would Be Nice to the list -
"Treat identity URLs as content, not handles". This is implied when a
site lets users change identity URLs. This is not specific to OpenID.
I think that Jyte shows an example of why this should be avoided. On
Jyte, identity URLs are used as user handles when creating content -
"example.org is an OpenID user" could be the content of a claim. This
is perfectly fine. However, that content is then used as an URL in
Jyte - the URL for that content would be
Assuming that URLs to Jyte content don't change, this meant at one
time that if a user changed his identity URL, information linking
content to that OpenID was lost - I removed one of my identity URLs
from the site and claims that used to be about me weren't associated
with my user anymore until I put it back.
This isn't necessarily true anymore, I haven't checked, and it
wouldn't be too drastic to fix. The reason that it's fixable is that
the identity URL is treated as content *in the content* - it is
rendered as the user's human-readable handle. In a Jyte URL, it needs
to be regarded as a Jyte-generated handle as well. This is already
the case, anyway, since it's munged, it's just that when I checked,
the munging didn't get rid of persistence.
Consider the perverse case where example.org gets sold a few times to
people who use it to log into Jyte, leading to URLs like
There's nothing wrong with this, it just shows that identity URLs are
content, not handles.
Pardon me for criticizing Jyte here without even pointing it out on
the Jyte list first, I'm just trying to show a constructive example
that I hadn't thought about enough to warrant a bug report when I
discovered it. I have a lot of fun on that site.
Karl Anderson kra at monkey.org http://monkey.org/~kra/
More information about the general