[OpenID] Recycling OpenIDs (Was: What's broken in OpenID 2.0? (IIW session))

[John Panzer]

Well, as long as you don't mind being openid.aol.com/dick1138.... :^)

Memorable, human readable, globally unique, and permanent : Pick three 
(maybe two).

-John

Dick Hardt wrote:
> I've been reflecting on this and I wonder if recycling OpenIDs is a  
> *good* thing.
>
> I understand the incentive for sites with large user bases to be able  
> to recycle names.
>
> An OpenID is much more then just a means of proving it is me again at  
> a website. An OpenID is a URI that is globally unique and that sites  
> can and *will* attach reputation to. It is also human readable, so  
> when I see the same OpenID at numerous sites, I expect it to refer to  
> the same entity. We expect the URI to be consistent over time and space.
>
> Any special treatment such as unique fragment must be preserved as  
> part of the URL wherever it is used and displayed otherwise there  
> will be confusion as to who the OpenID refers. I think that once a  
> URL has been handed out to a user, it is permanent.
>
> Perhaps I am missing something, but I don't see how OpenIDs can be  
> safely recycled even if there is some mechanism for an RP to know it  
> is different. We should just make them different.
>
> -- Dick
>
>
> On 10-May-07, at 7:15 PM, Allen Tom wrote:
>
>   
>> Hi Martin,
>>
>> I believe that adding unique generation identifier (like a nonce,  
>> serial
>> number, creation timestamp, or just a random blob) in the  
>> Authentication
>> Response would not necessarily break backwards compatibility with RPs.
>>
>> Existing OpenID 1.1 RPs can continue to ignore the generation
>> identifier, however 2.0 RPs should use the OpenID+Generation  
>> Identifier
>> to recognize users. RPs that are upgrading from 1.1 to 2.0 should
>> perform a rename operation on their existing users when their existing
>> users login for the first time after the RP upgrades to 2.0. For
>> instance, For instance, if an existing user has the OpenID
>> "http://op.com/user" the account will be renamed "http://op.com/ 
>> user#GenID"
>>
>> This assumes that RPs are able to support user rename operations.
>> Support of rename operations and linking and unlinking OpenIDs from
>> accounts are topics that the community needs to address as part of an
>> OpenID Best Practices document.
>>
>> The OpenID recycling issue needs to be resolved sooner rather than
>> later, and solving it in OpenID 2.0 seems to be the right time to  
>> do it.
>>
>> Allen
>>
>>
>>     
>>> Allen Tom wrote:
>>>       
>>>> Issue #2) OpenID recycling
>>>>
>>>> In order to free up desirable userids, many large OPs recycle  
>>>> userids
>>>> belonging to inactive accounts. If an OpenID is recycled, the new  
>>>> owner
>>>> will be able to access the previous owner's data if the RP is not  
>>>> aware
>>>> that the OpenID has changed ownership.
>>>>
>>>>         
>>> We have actually touched on this issue briefly in the past. One idea
>>> that was floated around was the use of a "serial number"[1] in  
>>> addition
>>> to the OpenID URL, where providers would ensure that the same serial
>>> number is not used for two instances of the same identifier. However,
>>> this is troublesome because it requires RPs to change the way they  
>>> store
>>> and identify identifiers, and is thus not backward-compatible.
>>>
>>> At the moment, OPs should not be recycling usernames at all. Any that
>>> are doing so are broken. That is not to say we should not come up  
>>> with a
>>> better approach that allows recycling, however.
>>>
>>>       
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
>>
>>
>>     
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070510/fb3f83eb/attachment-0002.htm>