Hi Allen,
We may be looking at different versions of the spec. I'm looking at draft-hardt-oauth-01. Section 6.2.2 and 6.2.5 are the redirect user to Auth Server and request Access Token steps. Both require the callback_url. I'm trying to understand why that is, and what defines the "correct" callback_url to send the second time around.
It sounds from your explanation that perhaps it's not that important because of the other mitigations with verification code, etc. But I suspect it's still important since the second callback_url is still there.
I'm also wondering what the wrap_client_state can be safely used for. I can make some guesses, but I'm sure you all have thought about it more deeply already. To give one (probably bad) example, if the callback URL must be the same for these two requests from the Client, I could (grin) store the callback URL that I used for the first request in the client_state of that same request, so that when I get the response back, I can look up that parameter, and just pass that value in as the callback_url of the second request. That leaves both the callback_url and the client_state wide open to MITM attacks, so probably not so good. I'm guessing anything very useful in client_state probably means it should be signed by the Client.
Thoughts?
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre