I meant, "it is userful when the user is moving the idp as well."
iPad typing is not always as easy as it should be ... =nat On Sat, May 29, 2010 at 11:16 AM, Nat Sakimura <[email protected]> wrote: > It is useful when the use is moving the idp as well. > RP doing the check would be also interesting though the RP has to be somehow > authenticated, I suppose, to thwart the identifier harvesting for the > correlation. It would also be good to define a bulk check protocol. We did > some experiment around that back in February by the Ministry of Internal > Affairs and Communication. Perhaps we can do some international R&D/pilot > on this topic this year? > =nat via iPad > On 2010/05/29, at 3:13, George Fletcher <[email protected]> wrote: > > This is similar to the IIW talk I did about migrating HTTP OpenIDs to HTTPS > OpenIDs. In general, it would be great if there was a standard way for RPs > to know and deal with OPs changing the identifiers. Using discovery (over > SSL?) to determine the two identifiers "point" to the same Authorization > server makes sense to me. > > If it's possible to discover the new identifier from the old one, then RPs > can just go through their DB and do the mapping out-of-band (meaning the > user doesn't have to be present). This can easy migration efforts from a > deployment perspective. > > Thanks, > George > > On 5/27/10 10:06 PM, Nat Sakimura wrote: > > The Connect proposal has put forward the new discovery and new > identifier for the user. > The RP will get the old identifier only through the request to the new > identifier. > It is done pretty cleanly though there are some downsides. Namely: > > 1) User is now bound to the authentication service. > 2) Current RP will be screwed up because there is no strong link > between the current and new identifiers. > > Among the two, 1) is relatively benign. Most of the current OpenID 2.0 > providers are like that. > (Though I would still want to seek more user centric way of doing things.) > In contrast, 2) is a disaster for the current RPs. > > What the RPs needs to do then is to authenticate the user that has > come in with connect proposal > with the good old OpenID 2.0 again to make the identity linking, which > in general is not a very > good user experience. > > 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
