Dealing with renames
kris at bbridgetech.com
Mon May 30 14:48:40 PDT 2005
On 2005/05/30, at 2:07 PM, Mark Smith wrote:
> I profess early my ignorance of many of the nuances of security.
> However, does this matter?
> The problem is that the server is
> authenticating someone,
> but if the user changes (as in the case on LJ when
> someone renames their account to a previous account that might have
> used at some consumer), right? So, two different people are
> identified to
> own the same URL.
> One of the design goals of OpenID is that you're simply proving "does
> person with this browser at this moment control this URL."
Ah, but that is merely one.
> Putting in any sort of state information, while useful, is not going to
> fix the underlying problem. If someone gains control over a URL (and
> presumeably the server) then they can pass through any sort of unique
This is not the case at all. The UniqueID would be included in the DSS1
signature. Unless the security was very lax, it is currently impossible
to forge. The Unique ID would not take the place of the ID-URL, but
instead be passed along as an argument back to the consumer among
> and verify anything. (Of course, assuming they know what hash was
> used originally, which I can't imagine would be hard to find out if
> managed to take over someone's URL.)
> Anyway, my point is that I don't think this will fix the problem
> but should instead be an optional addition that helps to improve
> If it's kept at that level -- so the consumers aren't required to store
> state information, which might overly complicate some uses of the
> -- then I think it's a good idea and would like to lend my support.
From what I've seen by example and by what I'm currently doing with
OpenID, it would be more than fair to say that OpenID may be used
primarily in two ways.
The first is to assert that the individual in question has control of
all subsequent information on a sub-domain, or sub directory. This is
good because we can ascertain that everything on the sub-domain or
sub-dir tree is safe to parse as that identity's.
The second, as shown on the OpenID wiki
<http://www.lifewiki.net/openid/>, OpenID-URLs can be used to identify
someone, in-order to gain access or post other information. This also
applies to blogs as well.
The first has already been supplemented well, many of us have working
code. The second works too, but there is a problem. The problem is
that, as you yourself mentioned above, if someone changes their name or
someone else takes it, the consumer still contains info on that person!
Two (or more) bad things can happen as a result:
1) Someone obtains the exact ID-URL, and gains access to information
that isn't theirs.
2) The person who originally had that URL has to go around and either
close accounts, delete information, etc... AND THEN RE-ENTER it. I
don't like re-entering information... especially passwords everywhere
-- that's why I invented Level9 -- and presumably why you guys invented
OpenID, as well.
With a uniqueID, a user can be any URL on the FQDN, and still login to
each of the other sites. This has an added benefit when
user.livejournal.com decides that he wants to use
livejournal.com/~user/ one day, and it'll still work.
The Consumer can take the info out of that asserted ID-URL, just like
it normally would -- but the user would still have the same
This also has an added benefit: profiles.
Say mylevel9.com/user/testaccount has two hidden profiles. Work and
What if mylevel9.com/user/testaccount wants to login to an OpenID
consumer, but because it's a friend's Guestbook, he wants to login
under play -- it has more info about him, afterall.
So, he enters mylevel9.com/user/testaccount/play -- because the server
gets a uniqueid back from the server -- if sometime later, the same
testaccount user enters in mylevel9.com/user/testaccount the server
will still know who he is, and won't ask him to enter the same info and
I hope this answers things...
More information about the yadis