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
