<div dir="ltr">Thanks for the explanation. That makes sense.<br><br><div class="gmail_quote">On Sun, Sep 7, 2008 at 11:18 AM, Martin Atkins <span dir="ltr"><<a href="mailto:mart@degeneration.co.uk">mart@degeneration.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d">Andrew Arnott wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Really? I never imagined the flow in 1.x meant anything other than the user_setup_url was anything besides an ordinary non-immediate request. In which case I don't know why the RP would send a setup_url request and a following immediate request, as the setup_url request results in an auth.<br>
<br>
It seems to me that 1.x and 2.0 is the same, except that instead of 1.x formulated the checkid_setup url for the RP, the RP must create it itself.<br>
<br>
</blockquote>
<br></div>
I may be remembering this wrong, I believe that the original design was that the setup URL wouldn't actually return a positive assertion, but rather would simply do the approval step. The intention was that "AJAX-like" implementations would be able to try an immediate request in the background, and if it failed open the setup_url *in a new window* (leaving the original page undisturbed) and finally retry the checkid_immediate in the original window to complete the authentication.<br>
<br>
In practice, I don't think anything except Brad's original demo implemented it this way, and so the setup_url became redundant and was often just the OP's checkid_setup URL.<br>
<br>
However, it's been a long time and I might be remembering this wrong. Nonetheless, if the setup_url results in auth then it is the same as a checkid_setup request, so it's redundant.<br>
<br>
<br>
</blockquote></div><br></div>