[OpenID] What's broken in OpenID 2.0? (IIW session)

[Allen Tom]

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.
>