<html><body bgcolor="#FFFFFF"><div>It is useful when the use is moving the idp as well. </div><div><br></div><div>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? </div><div><br>=nat via iPad</div><div><br>On 2010/05/29, at 3:13, George Fletcher <<a href="mailto:gffletch@aol.com">gffletch@aol.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>
<font face="Helvetica, Arial, sans-serif">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.</font><br>
<br>
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.<br>
<br>
Thanks,<br>
George<br>
<br>
On 5/27/10 10:06 PM, Nat Sakimura wrote:
<blockquote cite="mid:AANLkTimQqRmkBts9sCItATk76xP3v0DtS4ZxJYc-rNWM@mail.gmail.com" type="cite">
<pre wrap="">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?
</pre>
</blockquote>
</div></blockquote></body></html>