[OpenID] Migrating User Identifier URL re: Connect

[John Bradley]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20100529/e34e8c20/attachment.bin>