<div dir="ltr">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 <span class="Apple-style-span" style="font-style: italic;">and</span> a following immediate request, as the setup_url request results in an auth.<div>
<br></div><div>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><div class="gmail_quote">On Sun, Sep 7, 2008 at 3:16 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">
Does anyone who helped with the V2 spec know why user_setup_url was removed from negative immediate auth response messages? I like the overall changes, including that id_res is no longer sent in negative cases, which just confused the question of whether an auth was good, but user_setup_url was still helpful to some clients.<br>
<br>
I wondered if it had to do with the identifier_select case, where OPs might have a privacy leak that might expose the logged in user's claimed/local IDs in the setup_needed message if the request was sent with identifier_select.<br>
<br>
</blockquote>
<br></div>
I believe this was just for simplicity's sake. The 1.1 flow was:<br>
<br>
* RP does immediate request.<br>
* OP responds with failure and setup URL.<br>
* RP sends user to setup URL.<br>
* OP does some setup.<br>
* RP repeats immediate request.<br>
* OP responds with positive assertion.<br>
<br>
(or something along those lines.)<br>
<br>
The equivalent flow in 2.0 is something like:<br>
<br>
* RP does immediate request.<br>
* Server responds with failure.<br>
* RP does non-immediate request.<br>
* OP does some setup.<br>
* OP responds with positive assertion.<br>
<br>
The second non-immediate request functions as the setup step and the repeated immediate request rolled into one.<br>
<br>
<br>
</blockquote></div><br></div></div>