that ess in 'https'
mart at degeneration.co.uk
Thu Jun 29 17:38:05 UTC 2006
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.
More information about the yadis