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