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