silly classic path

[Brad Fitzpatrick]

After talking to Randy,

Another way (that's always upwards compatible) is to add an openid.mode
argument on the initial request (the one with is_identity) that's either:

  openid.mode = idcheck_immediate
  openid.mode = idcheck_setup

(There's currently no mode parameter specified there)

The implied default being "idcheck_immediate".  The immediate mode would
do what things currently do:  redirect to return_to with either the
assertion signature or the user_setup_url.

The idcheck_setup mode, on the other hand, would signal that's it's okay
for the identity server to take control of the user for awhile, bouncing
them around its own pages for awhile if needed, and then finally return
them to the return_to URL.

Classic mode would use idcheck_setup.  AJAX mode with an iframe would use
idcheck_immediate, in which case the consumer can augment
the server-supplied user_setup_url with either openid.post_grant having
value "return" or "close" (or nothing).

I'm liking this.  Any objections?

- Brad


On Tue, 24 May 2005, Brad Fitzpatrick wrote:

> 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
>
> _______________________________________________
> yadis mailing list
> yadis at lists.danga.com
> http://lists.danga.com/mailman/listinfo/yadis
>
>