[OpenID] Migrating User Identifier URL re: Connect

[Nat]

If it is the same RP and the RP authenticates itself, then the old OP  
can provide the migration information.

To make the new OP capable of making an authoritative assertion is  
much more tricky but it could be done. One way of doing it is for the  
old OP to sign the old user identifier / new op identifier pair by its  
private key and new op including it in the assertion so that the  
receiving RP can verify that the migration info is authoritative. This  
would allow the old OP shutting down almost immediately as well.

=nat @ Tokyo via iPhone

On 2010/05/30, at 9:32, John Bradley <ve7jtb at ve7jtb.com> wrote:

> To do that with openID 2.0 we would need to create a new attribute  
> to communicate the old claimed_id.
>
> There is no reason that would't work.
>
> Two things are required:
>
> 1 a old claimed_id attribute.  (In connect the profile page could be  
> used for that, but it might be better to be more specific)
> 2 a discovery document at the old claimed_id that has a service or  
> link  pointing to the new claimed_id.
>
> That won't work for some services using PPID like identifiers,   
> however the solution for them is to not change the claimed_id if  
> migrating to Connect.
>
> John B.
> On 2010-05-29, at 4:48 AM, Nat Sakimura wrote:
>
>> So, who is going to draft the spec?
>>
>> As I have stated earlier, I would like to generalize it a little  
>> bit more than
>> just openid2/connect.
>>
>> This would be very useful to solve "the openid2 provider shutting  
>> down
>> problem" as well.
>>
>> =nat
>>
>> On Sat, May 29, 2010 at 2:51 PM, David Recordon  
>> <recordond at gmail.com> wrote:
>>> +1 Allen/John
>>>
>>> On Fri, May 28, 2010 at 11:35 AM, Allen Tom <atom at yahoo-inc.com>  
>>> wrote:
>>>>
>>>> Hi Nat -
>>>>
>>>> The high level strawman proposal that John Bradley and I briefly  
>>>> discussed
>>>> was:
>>>>
>>>> 1) return the user's OpenID 2.0 identifier as an attribute in the  
>>>> Connect
>>>> assertion (along with the new Connect ID)
>>>>
>>>> 2) Update the OpenID 2.0 discovery document for the identifier to  
>>>> list the
>>>> to OpenID Connect endpoint as a "connect/openid2" migration  
>>>> service.
>>>> Connect
>>>> RPs are supposed to perform OpenID 2.0 discovery on the OpenID 2.0
>>>> identifier to make sure that the Connect OP is also authorative  
>>>> for the
>>>> OpenID 2.0 identifier
>>>>
>>>> Implementing #1 and #2 will allow an existing OpenID 2.0 RP that  
>>>> already
>>>> has
>>>> OpenID 2.0 users to migrate their existing users to Connect without
>>>> requiring users to auth twice during the migration process.
>>>>
>>>> Does anyone see a problem with this approach?
>>>>
>>>> Allen
>>>>
>>>>
>>>> On 5/27/10 7:06 PM, "Nat Sakimura" <sakimura at gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> 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?
>>>>
>>>> _______________________________________________
>>>> general mailing list
>>>> general at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>
>>>
>>
>>
>>
>> -- 
>> Nat Sakimura (=nat)
>> http://www.sakimura.org/en/
>> http://twitter.com/_nat_en
>> _______________________________________________
>> general mailing list
>> general at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-general
>