[OpenID] Migrating User Identifier URL re: Connect

[George Fletcher]

This is similar to the IIW talk I did about migrating HTTP OpenIDs to 
HTTPS OpenIDs. In general, it would be great if there was a standard way 
for RPs to know and deal with OPs changing the identifiers. Using 
discovery (over SSL?) to determine the two identifiers "point" to the 
same Authorization server makes sense to me.

If it's possible to discover the new identifier from the old one, then 
RPs can just go through their DB and do the mapping out-of-band (meaning 
the user doesn't have to be present). This can easy migration efforts 
from a deployment perspective.

Thanks,
George

On 5/27/10 10:06 PM, Nat Sakimura wrote:
> The Connect proposal has put forward the new discovery and new
> identifier for the user.
> The RP will get the old identifier only through the request to the new
> identifier.
> It is done pretty cleanly though there are some downsides. Namely:
>
> 1) User is now bound to the authentication service.
> 2) Current RP will be screwed up because there is no strong link
> between the current and new identifiers.
>
> Among the two, 1) is relatively benign. Most of the current OpenID 2.0
> providers are like that.
> (Though I would still want to seek more user centric way of doing things.)
> In contrast, 2) is a disaster for the current RPs.
>
> What the RPs needs to do then is to authenticate the user that has
> come in with connect proposal
> with the good old OpenID 2.0 again to make the identity linking, which
> in general is not a very
> good user experience.
>
> My suggestion here is to include both the old and new identifier in a
> signed assertion,
> with a sunset set for the old identifier. It could be either OpenID
> assertion or XRDS.
> If it is in the OpenID assertion, it is done.
>
> If it got the old identifier as an attribute of the identity that the
> new identifier points to,
> RP can then do the Discovery on the old known
> identifier and get back the XRDS which includes both the old and new
> identifier.
>
> What do you think?
>
>    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100528/45931cc2/attachment.html>