[OpenID] OpenID provider with gibberish identity URLs to avoidnickname change issues

Nat Sakimura n-sakimura at nri.co.jp
Tue May 29 17:39:16 UTC 2007


Well, I guess the issue here is "How to turn an existing app with user
management capability to an OpenID provider. " Changeable nickname is common
in CMS such as Xoops so this is a problem worth contemplating... Actually,
having almost completed the OpenID consumer module for Xoops now, I was
starting to think about it, too. 

IMHO, there is no easy solution, but I would be tempted to use something
like http://example.com/<nickname>.<uid>, where <uid> is the system user ID,
which is usually a unique number. 
The other solution is to user http://example.com/<uid> as canonical ID, but
I was wondering if all RP are implemented to use canonical ID instead of
identity URL when available. If they are, the later is more preferable, I
think. 

Nat 

> -----Original Message-----
> From: general-bounces at openid.net 
> [mailto:general-bounces at openid.net] On Behalf Of Chris Messina
> Sent: Wednesday, May 30, 2007 2:28 AM
> To: Stuart Bishop
> Cc: general at openid.net
> Subject: Re: [OpenID] OpenID provider with gibberish identity 
> URLs to avoidnickname change issues
> 
> I may be wrong, but it seems overly complex and redundant. What if
> someone set their nickname to one of the opaque keys? While I applaud
> the notion of allowing for changeable nicknames, I'm not sure that
> it's necessary to bind the person's URL to their respective nickname.
> Instead, it might just be better to accept that there is a limited
> number of nicknames on your system and that folks can do what they do
> everywhere and simply find a nickname that's available, knowing that
> their preferred nick might not be available.
> 
> I'd say keep it simple -- as we've discussed before, the issue of
> passing on OpenIDs becomes an issue if people can recycle or claim
> previously used nicknames... I'm not sure what ramifications exist for
> redirects -- since that's technically not delegation -- and I'd be
> interested to hear what folks more familiar with the protocol says
> about this.
> 
> Chris
> 
> 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. 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.
> >
> > 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?
> >
> > --
> > Stuart Bishop <stuart at stuartbishop.net>
> > http://www.stuartbishop.net/
> >
> >
> > _______________________________________________
> > general mailing list
> > general at openid.net
> > http://openid.net/mailman/listinfo/general
> >
> >
> >
> 
> 
> -- 
> Chris Messina
> Citizen Provocateur &
>   Open Source Advocate-at-Large
> Work: http://citizenagency.com
> Blog: http://factoryjoe.com/blog
> Cell: 412 225-1051
> Skype: factoryjoe
> This email is:   [ ] bloggable    [X] ask first   [ ] private
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
> 




More information about the general mailing list