URL relationship permanence

[Ernst Johannes]

I don't think so ... see below.

On Jul 1, 2005, at 2:23, Martin Atkins wrote:


> Ernst Johannes wrote:
>
>
>> Let me disagree with both of you guys .... you'd be right if gpg   
>> wasn't in the picture, but it is. So I think LID addresses this  
>> case,  as Xageroth initially claimed.
>> The LID identity is backed up by a public gpg key, which is  
>> "your"  public key. Presumably, when you lose your domain/URL, you  
>> don't also  hand over your private key. (if you do, you are in  
>> bigger trouble  than we are dealing with here anyway ...).
>> So if a relying party receives a LID-approved request (such as a   
>> single-sign-on request, or an authenticated message, or an   
>> authenticated query, or whatever LID profile ...), the relying  
>> party  will authenticate that request against the public key  
>> exported by the  corresponding LID. If that public key is  
>> different than it was last  time, it indicates "we can make no  
>> assertion whether the 'old' and  the 'new' LID have anything to do  
>> with each other" (although they  look identical) exactly because  
>> of the scenario you are describing.
>> Makes sense?
>>
>
> That mechanism notwithstanding, there still exists a problem of Bob  
> signing into site A, then Bob losing his domain and Tim grabbing it  
> and posing as Bob on site B. As long as Tim never tries to log in  
> to site A no-one can prove that he is not the same person. Site B  
> never had a record of Bob's public key in the first place.
>

Let's break out the different use cases in here.

1) Can site A tell that a LID URL was "reused"?
It wouldn't be able to tell in case of a trivial (and thus not very  
secure) LID relying party implementation. A more  secure  
implementation of site A will store the public key that it used to  
verify Bob's identity the first time Bob showed up, and then keep  
comparing. (It probably will also store some profile information,  
such as the user's name, in order to personalize the site -- it  
obtains both the same way by querying the user's LID).

This the same mechanism as gpg works for e-mail, by the way. If my  
gpg didn't store your public key after the first interaction, I would  
have no assurance that the second e-mail from you was indeed from you.

2) Can site B, which Bob never visited, but which Tim has visited,  
tell that its Tim and site A's Bob are or are not the same people? Or  
a variation of it: can site C, which has no prior relationship to Bob  
or Tim, tell, by looking at site A and site B?

There are two answers to this:
a) Some people would argue that site B has no business attempting to  
correlate information it has with site A about a particular user.  
(Kim's 4th law of identity see http://www.identityblog.com/stories/ 
2005/05/13/TheLawsOfIdentity.html) And thus, they would argue, the  
inability of site B to tell just by looking at the identifier (the  
user's LID URL) is just fine.
b) But let's say you are site A and you disagree with point a) and  
you indeed want site B to be able to tell that it was Bob rather than  
Tim who left, say, a blog comment on site A. In that case, site A  
must not only store the blog comment, but the signed blog comment on  
the site in a way that site B can get at it. That way, B can compare  
the signature with the public key it gets from the user's LID, which  
will not match in case of Tim reusing Bob's URL.

Not that the LID POST profile, which is a generalized version of  
doing blog comments using LID, automatically signs the content POSTED  
to a site by a user, so it already has the public key.

You are not bringing this up (yet? ;-) but if you did, you'd be right  
that it does leave open the case about what to do when the public key  
expires and must be replaced. We haven't come up with a "defined"  
protocol for LID to do that, but the essence of it will be a two- 
keypair scheme where one key certifies the other and its replacement  
once it needs to be replaced.


> Identifiers being transferred to other people is a general problem  
> regardless of what you use for identifiers. LiveJournal has this  
> problem within its own namespace: LiveJournal users can become  
> previously-deleted accounts, and suddenly all of the old links go  
> to a new journal. Little can be done about it because the username  
> is the only means of identification for that person.
>
> Unless you have some mechanism to transfer ownership in a machine- 
> readable way or somehow ensure that an identifier can't be reused  
> (unlikely) you're going to have to deal with this ambiguity  
> eventually regardless of how much fancy crypto stuff you've got  
> going on.
>

Do my comments above solve that issue?


> It's the user's responsibility to choose an identity provider  
> (which might be himself) which he believes will be under his  
> control forever. LiveJournal users are trusting LiveJournal with  
> this role, and in the present situation unless they explicitly  
> delete an account users are in control of their identities. Of  
> course, they must trust LiveJournal not to take their identities  
> out from underneath them either by suspending their account or just  
> going out of business altogether.
>

Right, this is also a reason why I asked earlier about how closely  
OpenID reflects the business cirucmstances of LiveJournal and its new  
parent company. LID's assumption here is that it is best if the owner  
of the identity ("you") gets their own domain name (a .name tld might  
be perfect, and cheap ...), ties their LID URL to their own domain,  
and moves hosting providers with their domain as they like, if for  
some reason, they don't like their hosting provider any more.


Johannes Ernst
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20050701/a148224c/lid.gif
-------------- next part --------------
  http://netmesh.info/jernst



Johannes Ernst
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20050701/a148224c/lid-0001.gif
-------------- next part --------------
  http://netmesh.info/jernst