[OpenID] OpenID provider with gibberish identity URLs to avoid nickname change issues

[Josh Hoyt]

On 5/28/07, Stuart Bishop <stuart at stuartbishop.net> wrote:
> I am working on turning a webapp into an OpenID provider. One if the
> features of the webapp is that the user's nicknames are changable.

In general, I'd recommend against "turning a webapp into an OpenID
provider." For security reasons, it's usually better to run a separate
application that acts as an OpenID provider and enable your
application as a relying party. There are certainly cases where this
doesn't make sense (e.g. the purpose of your application is to support
several single-sign-on protocols for users), but in general, you're
better off compartmentalizing the OpenID server component so that any
vulnerabilities in your application won't affect your users' accounts
on other sites.


> We would like nickname changes to not affect other applications we
> need to integrate with, so wish to use an unchanging opaque
> identifier instead of the user's nickname.
>
> So we are thinking of having https://openid.example.com/<nickname>
> issue a temporary redirect to
> https://openid.example.com/<opaquekey>. This way users can use the
> nicer, more memorable URL but name changes will not affect the
> systems we are integrating with.
>
> Can anyone see problems with this approach? The only issue I'm aware
> of is that the identity URL will look like gibberish on sites that
> choose to display it.

The problem of recycling identifiers is one that we are attempting to
tackle right now for OpenID 2.0. In the meantime, your solution will
definitely work. I think that the usability might be better if the
redirect were to https://openid.example.com/nickname/<version number>
so that it's easier for humans who see the URL to differentiate
between users of your provider.


> I am also toying with the idea of instead of having a single identity url,
> instead generating a unique opaque identity URL for every trust root using a
> hash. Combined with the above, users should be able to enter their memorable
> identity, but every consumer would get a different opaque identity url
> making it impossible to correlate data across sites.
>
> Does this sound like a sane idea?

The term that is usually used to describe this feature is "directed
identity."

There are two problems with trying to do this with OpenID 1.1. First,
you can't do the redirection on a per-relying-party basis, because you
don't know who the relying party is when they request the identity
URL. Second, the OpenID 1.1 specification does not allow for returning
a different identifier than the one that was requested.

Support for directed identity is one of the key features of OpenID
2.0. If you implement OpenID 2.0, your users will enter the URL for
your provider, and the provider will get a request for identifier
selection. It's up to the provider and the user at that point to
choose or generate a URL to send in the response.

My preference as a user is for my provider to allow me to choose
exactly where I can be correlated. There are places where I *want* to
be correlated, both by humans and software agents, and there are
places that I do not. For example, I do want to be correlated across
blogs, so that I can take my reputation with me, but I do not want to
be correlated across sites where I make purchases.

Josh