Non-recoverable auth failure?

[Carl Howells]

One thing currently absent in the protocol is some form of 
non-recoverable authentication failure.  The only response for failing 
to authenticate that's in the spec is to give the user some chance to 
authenticate.  But that doesn't seem like it will always be sufficient.

Consider the case of an ID server that locks an account for 24 hours 
after three consecutive failed logins.  I'm sure everyone is familiar 
with that kind of behavior, and can see it as being appropriate in some 
cases.  When such an ID server has locked an account and someone tries 
to log in with that account, the current behavior doesn't quite make 
sense.  It is effectively telling the consumer "it didn't work, but if 
you go here, you might be able to fix it."  That's a misleading 
statement, as it's just not true.  Going to that url won't fix it.  This 
is a case where it would be clearly better to tell the consumer "that 
login is denied."

Having such a message still doesn't reveal any information about why the 
login has been denied.  It just lets the consumer know that it should 
present an error message to the user, rather than trying to get the user 
to complete a login sequence that won't be completed.



Also...  While looking at the version 0 specs to see the flow for 
recoverable auth failure, it seems very strange in checkid_immediate mode.

* auth fails
* send back a response, openid.mode=id_res&openid.user_setup_url=blah. 
Well, that feels a bit strange on its own, as id_res seems to be a 
heavily overloaded mode.  But that's not the point I'm trying to 
demonstrate.
* consumer pops up a window (or something) going to user_setup_url.

That's where things don't quite make sense.  It seems like instead of 
having an openid.post_grant argument added, it should instead use 
another openid.return_to=url argument.  First, it would remove the 
current necessity of having the server encode the URL into the 
user_setup_url in case the consumer sets openid.post_grant=return. 
Second, it covers all the cases just as well.  The return_to url can 
easily generate javascript to close a popup, as well as notifying its 
parent frame that the authentication attempt has concluded so the parent 
can then take whatever behavior it sees fit.


Thanks for reading through this.  Let me know what you all think.

Carl Howells