Non-recoverable auth failure?

Carl Howells chowells at
Tue Jun 28 16:26:01 PDT 2005

Brad Fitzpatrick wrote:

> Changing post_grant I'm still debating: perhaps it just needs to be
> documented that post_grant=return is implied in checkid_setup mode,
> which just leaves post_grant=close for closing new windows.  And it
> seems a little silly to redirect the UA to another URL whose sole
> responsibliity is doing "window.close()" when that'll be such a common
> request from consumers.  HOWEVER-- I like the possibility of a
> post_grant_url being able to complete the final click of an AJAX-style
> login box without the login box having to do checkid_immediate
> polling.  But I think you can do that with postgrant=return anyway, so
> I have to think about this more.

This is the one part of this still worth debating, and I'm more sure 
that the current approach is wrong than ever.

As for the silliness you mention, having the consumer serve a page just 
for window.close(), isn't really an accurate description of what 
happens.  First, there's a full id_res response in the returned value. 
That means that the consumer can finish logging in the user before 
returning any page, and without any extra redirects or requests. 
Second, since the login has completed, the page served can include 
javascript to inform window.opener that the login has *already* 
completed, and to move on, as well as closing the new window.  That 
seems like a great deal more than just serving a page containing a 
window.close() command.

Furthermore, there are huge code complexity issues involved with 
supporting the post_grant parameter.  It's trivial for the server to 
craft a user_setup_url that is exactly the same as the checkid_setup 
request url would be.  Doing so leads to maximal code-reuse in the 
implementation of the server...  No special cases need to be for 
handling the user_setup_url, and everything stays nice and generic.

Unfortunately, it isn't that simple.  The behavior of constructing such 
a URL is only correct if your openid server deviates mildly from the 
spec, and allows the post_grant field to be set on any checkid_setup 
request.  That's plainly silly, though it still seems a better approach 
than duplicating a lot of code just for the user_setup_url.

Get rid of the post_grant parameter.  Please.  It adds complexity to the 
spec.  (In fact, it might currently be the least well defined part of 
the spec.)  It adds complexity to implementations.  It encourages bad UI 
design.  It just doesn't make sense to have it around.

Carl Howells
(begging on this issue)

More information about the yadis mailing list