[OpenID] Migrating User Identifier URL re: Connect

[Nat Sakimura]

It is useful when the use is moving the idp as well. 

RP doing the check would be also interesting though the RP has to be somehow authenticated, I suppose, to thwart the identifier harvesting for the correlation. It would also be good to define a bulk check protocol. We did some experiment around that back in February by the Ministry of Internal Affairs and Communication. Perhaps we can do some international  R&D/pilot on this topic this year? 

=nat via iPad

On 2010/05/29, at 3:13, George Fletcher <gffletch at aol.com> wrote:

> 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-general/attachments/20100529/e2d14d8e/attachment.html>