The fix for this will not break CODE on existing web sites, but it is expected to
cause returning users to be identified as new users since the Claimed Identifier will
be different.  

This is a big problem.  We absolutely need to fix it, but we need to provide some
recommendations to upgraders on how to upgrade their users' Claimed Identifiers.

Although this fix is very important, we will only make it available in the 2.3
release and later rather than back-porting it to earlier releases (2.1 and 2.2) to
protect webmasters who may upgrade for a maintenance release without expect breaking
changes.

*IMPORTANT GUIDANCE FOR RELYING PARTIES UPGRADING FROM PRE-2.3 RELEASES:*
Your visitors from Providers that issue #fragments in their Claimed Identifier WILL
NO LONGER BE ABLE TO ACCESS THEIR ACCOUNTS after this upgrade if you don't take
special steps to help them upgrade their Claimed Identifiers to the version with the
fragment on it.  The steps you take will depend on on your user base and the security
needs of your site.  Following is one possible solution:
1. Add a column to the users table in your database called "LegacyClaimedIdentifier"
and set it to true on all rows.  
2. When a user logs in, look for the user's row in the users table by the
ClaimedIdentifier given in the IAuthenticationResponse.  
2.a. If you find their user account by an exact match on their ClaimedIdentifier, set
the user's LegacyClaimedIdentifier to false and you're done.
2.b. If you DON'T find their user account, and the
IAuthenticationResponse.ClaimedIdentifier has a fragment part to it (contains a #
character), generate a new string that matches the ClaimedIdentifier but trims off
the # character and everything after it.  Search for a user row with the
ClaimedIdentifier w/o its fragment.  
2.b.a. If you find a row and its LegacyClaimedIdentifier is set to true, set the
ClaimedIdentifier for that user row to the new one in
IAuthenticationResponse.ClaimedIdentifier, set the LegacyClaimedIdentifier = false,
and you're done.  
2.b.b. If you don't find a row or its LegacyClaimedIdentifier is set to false, you
don't have a match and should treat this authentication as a new user.
3. When all your user rows have LegacyClaimedIdentifier = false, all your users have
been evaluated for upgrading to the new ClaimedIdentifier and you can remove this
column and your special-case handling code.

Yes this is a pain, but we need to fix it now rather than leave it alone to prevent
against identity spoofing using recycled URLs.

Another solution for web sites that maintain usernames & passwords along with their
OpenIDs would be to skip the above suggestion altogether and just advise users who
log in with a URI with a fragment on it, that you cannot find in your database, that
before they create a new account they should consider logging into their existing
account via their username/password if they have one, and then re-establishing their
OpenID once they are logged in via your original OpenID matching mechanism.