+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 >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
