silly classic path

[Brad Fitzpatrick]

In discussing the path of the "classic" (non-"AJAX") auth path, we noticed
something silly.

Consider this fragment from helper.bml:

    if (my $setup = $csr->user_setup_url) {
        if ($classic_mode) {
            return BML::redirect($setup);
        } else {
            my $e_url = js_dumper($setup);
            return $js_page->("if (parent.location.host == location.host) parent.OpenID_callback_fail($e_url);\n");
        }
    }

That says:

   if (we got a negative assertion from the identity server) {
      if (non-AJAX mode) {
            redirect the user where the identity server said they should go
      }

      if (AJAX mode) {
            propogate the user_setup_url up from the 1 pixel iframe up to
            the parent page, so the upper UI/javascript can do smoething
            with it
      }
   }

See how silly that non-AJAX mode is?  The identity server gives us a URL
and we just go to it.

My first thought (which was bad) was to add a new "post_grant" option in
addition to "return" and "close".  But then I realized I hated post_grant
because it was too much action-a-distance:  you're telling the ID server
the behavior you want it to take, so it gives you a user_setup_url with
that, then you return to it, then it takes the action you asked for.

But still, we have 3 valid modes in need of names/modes:

1) AJAX case with pop-up window:
   return negative assertion immediately, returning a user_setup_url
   that will take the user to a page which will setup permissions,
   and then "close" the brower

2) AJAX case where the setup link is a normal, non-popup link:
   return negative assertion immediately, returning a user_setup_url
   that will take the user to a page which will setup permissions,
   and then "redirect" the browser back where it came from

3) Clasic case where setup pages are done by identity server, then
   returned later with a positive assertion.

So I'm kinda thinking to not send openid.post_grant in the initial
is_identity request, and instead have "openid.return_immediately" set to
either 0 or 1, which tells the identity server whether it has to redirect
back to our return_to URL with a negative assertion (the user_setup_url)
or whether it's free to send the user there itself, or render the
permission page right there in-place instead of doing a redirect.

But post_grant survives:  in the case where the consumer sent
openid.return_immediately=1 and the identity server redirected back with a
user_setup_url, then _at that point_ can the consumer include a new
official openid.post_grant argument appended to the user_setup_url, which
is the same as before:  "return" or "close".

Thoughts?

In particular, mart:  this doesn't break your dual ajax/classic OpenID
client, does it?  Since the old behavior is still possible?

- Brad