That is very similar. However, I would rather position it not as "openid2/connect" migration but "oldid/newid" migration service. That way, we can use it even for openid2 idp to openid2 idp migration or connect idp to connect idp migration.
=nat On Sat, May 29, 2010 at 3:35 AM, Allen Tom <[email protected]> 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" <[email protected]> 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? > > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
