that ess in 'https'

[David Strauss]

Martin Atkins wrote:
> 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.

Please explain the security problem you see because I can't see them. If
an https URL asserts both the old and new identities, then it's
completely safe. Especially if both the old and new IDs are https, it's
a really safe transfer.

I'd be more worried about identity hijacking. You could forge an http
identity page to not only take the current identity but also rename the
account to use a server you actually control.

> 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.

Consolidation would be a great feature, but it's probably too much of a
burden for RPs.