Inferring return_to

[Brad Fitzpatrick]

On Mon, 13 Jun 2005, Paul Crowley wrote:

> Martin Atkins wrote:
> > I seem to remember that in the old version the original return URL was
> > passed back in a parameter, but the consumers I wrote never used it. I
> > just built the URL again the same way as I had the first time.
>
> You're right - another clerical error.  I'd be grateful if people could
> check for more such errors.
>
> But there's a security reason to leave it that way.  Checking that the
> return_to URL is correct is a vital part of building a secure consumer.
>   Making them infer it, rather than trusting what they get along with
> the token, is one way to ensure that.
>
> It also avoids a double-URL-encoding problem and makes the URL markedly
> shorter.

It's a royal pain in the ass to reliably infer it, especially generically
from a library, which is criticial to adoption.  Plus it imposes
additional restrictions on server implementators about how they append URL
arguments (which they may have no control over, if they're using a URL
object).  People aren't going to hand-code implementations of OpenID like
mart and us.  It's so much easier to just get the return_to URL back,
parse it, and do checks on the hostname.  Same security, but more
flexibility of implementation.

I'm going to have to pull rank here and say it's more of a protocol and
implementation issue and less a security issue and request it stay in.

- Brad

P.S. emailing this from +0100... what up WEST?