that ess in 'https'

[Martin Atkins]

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.