that ess in 'https'

[Martin Atkins]

David Strauss wrote:
> 
> 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.
> 

Really, other than the "ick!" factor I've not got no major objections to 
your proposal of just disregarding the scheme. However, I'm attempting 
to show that generalizing it to a rename isn't that hard and we get 
renaming functionality along with it, which in my opinion is more 
important than this SSL upgrade business.

It also keeps the existing model that says that two identities are the 
same only if they are byte-for-byte identical, which would ease 
upgrading for existing RPs that would otherwise have to transform their 
existing whole-URL data into a (URL-less-scheme, Is_SSL) tuple.

Given the choice between implied and explicit connections between these 
things, I'd rather pick explicit as long as explicit is easy, which I 
believe it is.

As for identity hijacking, I think that's both not much better than and 
not much more likely than forging the identity document to point at a 
different identity provider. People who are using HTTP are already 
taking a risk (though in my opinion, not much of one); people who care 
can use HTTPS, once we say that RPs are required to support it and make 
it take precedence.