Inferring return_to

[Martin Atkins]

Paul Crowley wrote:
> When the consumer comes to verify a token, it must know the value of
> return_to used to build the token.  This won't be the URL of the request
> that passes the token to the client - that URL includes extra GET
> parameters like the signature itself.  So how should they infer it?
> 
> * if they don't add GET parameters before sending it, it's just the URL
> with no parameters
> * if they do, they could include a special "sentinel" parameter, say
> "sentinel=true", and search for the first occurence of it
> * The server could tell them the length of the return_to in the reply
> and they could truncate to that, but I worry about possible security
> implications of that strategy

I would think that the consumer knows what its return_url is because it
was the one that sent it in the first place. Most of them will just have
a hardcoded string for the return URL anyway, and those that don't can
just do whatever they did in the first place to make the string.

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.

Forgive me if something in the new spec makes this impossible. I've not
really been paying attention this last couple of weeks as I've had other
commitments, and I've not yet read up on the new stuff in any amount of
detail.