that ess in 'https'
mart at degeneration.co.uk
Thu Jun 29 07:37:22 UTC 2006
David Strauss wrote:
[snip my lengthy paragraph of proposal]
> I like this basic proposal, but read on. Remember that almost every
> OpenID user enters schemeless versions of their URL, so this system
> would likely be the norm rather than the exception.
> I'd still like to prohibit hosting different IDs at URLs that vary only
> by scheme, if only to allow easy migration from http IDs to secure ones.
> Scenario: Bob signs onto OpenIDFlowers, an RP. Because he enters
> bob.mropenid.com, the site tries https first. Unfortunately,
> MrOpenID.com doesn't support https identity pages yet, so Bob is signed
> on as http://bob.mropenid.com/. He sets up preferences, etc. The next
> week, MrOpenID.com starts supporting https identity pages. So, later
> that next week, Bob signs onto OpenIDFlowers with bob.mropenid.com.
> Because his OpenID server supports https identity pages now, he's signed
> on as https://bob.mropenid.com/. He's confused about where all his
> preferences went.
Perhaps we can allow a simple, explicit "upgrade" mechanism:
The HTTP URL returns (either in Yadis or by some other means) an extra
"I agree that I've become ..." parameter. The HTTPS URL includes a
parameter that says "I used to be ...". Relying parties can then check
these to see if they agree and do a one-time rename of the identity.
This keeps it explicit without adding much implementation overhead.
There is an attack vector in the time between changing the identity URLs
to indicate this "upgrade" and doing a signon, but once the upgrade is
completed the URLs are once again distinct. It also allows an identity
to *downgrade* to HTTP by the same mechanism. Note that the relying
party is only required to do all this if it already has an account for
the "old" identity.
This can also, I think, be used for identity renaming. If
http://frank.livejournal.com/ says "I am now http://frankworld.com/" and
http://frankworld.com/ says "I was once http://frank.livejournal.com/",
then relying parties can do that rename on signon. The user would have
to make sure that the old identity works as long as they have
outstanding relying parties that haven't seen the change, but the
identity provider would be doing this for them in most cases anyway.
If you allow multiple "I used to be ..." records this can also be used,
in theory, for identity consolidation, though relying parties would
probably find that harder to implement since they would need to
essentially "merge" two accounts together. This is already an issue in
the above proposal, but as long as consolidation is not allowed we can
simply say that the relying party is only required to do this transform
if there isn't already an account with the new identity.
More information about the yadis