[OpenID] Migrating User Identifier URL re: Connect

John Bradley ve7jtb at ve7jtb.com
Sat May 29 22:00:50 UTC 2010


It still seems like the most promising approach to me.

The Connect RP needs to keep supporting openID 2.0 discovery,  but they are likely going to anyway to continue to support openID 2.0 users who are not migrating.

John B.

On 2010-05-28, at 2:35 PM, Allen Tom 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

-------------- 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-specs/attachments/20100529/c5f4ffcc/attachment.bin>


More information about the specs mailing list