Dealing with renames
pp at myelin.co.nz
Sun May 29 16:46:33 PDT 2005
> The ID server shouldn't do that. http://domain/someguy/ and http://
> domain/anotherguy/ might be different "personas" for me, even if I'm
> the same user on the ID server.
I think this is to disambiguate users with the *same* URL. So you
could reasonably concatenate userid:url and hash that - as someone
(Kris Tate?) suggested earlier.
> Also, I'm still http://domain/someguy/ even if I change from using LJ
> as my ID server to using http://www.openlogin.net/; so that should be
In this case I guess you *wouldn't* want to assign a userid - and just
use the URL.
I suppose we have several cases:
id server = web server (e.g. livejournal)
(1) if you delete your account and someone else signs up with the
same name, they shouldn't be able to authenticate as you.
id server != web server
(2) if you delete your domain and someone else registers it and
puts up an openid <link> tag pointing at your id server, the id
server shouldn't authenticate them as you -- this one is
(3) if you change id servers from openlogin.net to
someotherlogin.net, the new id server should be able to
My suggestion is that id servers which are also web servers should
include some sort of userid to prevent your url being usable to
authenticate as you in future (#1).
Other id servers shouldn't put in a userid - because there's no need.
This makes sure #3 works.
I don't think #2 is fixable without having users do their own crypto,
i.e. Ask's proposal ...
> One possible solution (quickly getting into More Complicated Than We
> Want Territory) could be something along these lines:
> You put a root type certificate and a revocation list on your site
> and then give the ID server a certificate it can sign the request
> with on your behalf.
> The private key to the root certificate is on your local computer and
> the consumer can then use the fingerprint from the root certificate
> on your site for your user-id.
More information about the yadis