Non-recoverable auth failure?

[Carl Howells]

Quoting Brad Fitzpatrick <brad at danga.com>:

> On Thu, 23 Jun 2005, Carl Howells wrote:
> > And any thoughts (from anyone) on on my proposed change to the use of
> > the user_setup_url after using checkid_immediate?
>
> I'll admit I didn't quite follow.  What can't you do with the existing
> modes?

I don't believe that what I'm proposing actually adds any new functionality.
What it does is simplify things without any loss of functionality.

I'm suggesting replacing the openid.post_grant field.  Replace it with an
openid.post_setup_url field.  After setup actions are completed, the server
will send the UA a redirect to the post_setup_url with either openid.mode=res
or openid.mode=cancel.  It's then the consumer's responsibility to do whatever
cleanup action (like closing popups, collapsing iframes, etc.) is necessary.

This has a few advantages over the current system:

* The current system requires that the original return_to url be encoded in the
user_setup_url somehow, and this change would remove that requirement.

* In the current system, if the consumer wants to clean up popups, iframes, etc.
that it's created to visit the user_setup_url, it has to be rather clever about
it.  As the same return_to URL is used for both the response to the initial
checkid_immediate call and the later response to visiting the user_setup_url,
it has to distinguish between them somehow.  And while it's not hard to do
that, it's harder than simply giving them two different URLs.

* The examples of using AJAX login I've seen so far have required the user to
perform whatever setup action is necessary, and then after they've closed the
popup, click "login" again.  While it's possible to not require that extra
click with the current system, it's harder than it needs to be, because of the
problem explained in my last point.  This proposal makes it much easier to
immediately see how to not require that extra click.  (Well, to me, anyway.
Everyone's intuitiveness level about web interfaces is highly variable.)

* It's conceptually simpler, as the party responsible for creating the popups,
etc. is the same party that's responsible for cleaning them up.  The consumer
is responsible for whatever AJAX magic it wants to use, and the server just
serves normal HTML pages and sends redirects.

Really, I don't think it's a functional improvement overall.  I think it's a
significant improvement in terms of ease of use though, and I think it should
be considered on those terms.

Carl

PS

It would still be required that the trust_root, identity, and assoc_handle be
encoded in the user_setup_url.  It feels kind of silly for the server to be
telling itself those things.  I'm starting to believe the whole user_setup_url
thing is a really confusing idea as currently designed, and Paul had exactly
the right idea.  Instead of taking the one small step I've described here to
simplify things, maybe it would be better to go all-out, and say that the
correct behavior is to just make a full checkid_setup call using the
user_setup_url as the server url.

This would still preserve all existing functionality, and probably be simpler
yet, conceptially.  It is a bit more of a radical change, though.