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 <[email protected]> wrote: >> +1 Allen/John >> >> On Fri, May 28, 2010 at 11: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? >>> >>> _______________________________________________ >>> general mailing list >>> [email protected] >>> http://lists.openid.net/mailman/listinfo/openid-general >> >> > > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > _______________________________________________ > general mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-general
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
