Non-recoverable auth failure?

[Martin Atkins]

Carl Howells wrote:
> 
> As it is, there's no reasonable behavior for a "no" button to have, yet
> the lack of a "no" button will greatly disturb many users.  That's the
> reason I believe there should be a way for the server to tell the
> consumer "They didn't authenticate.  They won't.  Continue on without
> authenticating them."
> 

Oh, I understand where you are coming from now. What you are talking
about is less a non-recoverable auth failure and more just a "go back to
whatever you were doing" request. For most consumers, I'd imagine that
this will return to the login form or to whatever page the user clicked
"Log in with OpenID!" on, possibly displaying a generic "OpenID login
cancelled" error message.

I don't really see any reason not to make this part of the spec, with
the proviso that it *only* means "cancel the OpenID login" and not any
other extra stuff like "this login will never work again", "this account
is currently suspended" or any such thing. It just means "user
cancelled". It just requires the ID server to redirect to the return URL
with mode=cancel.

It could also give the consumer an opportunity to clean up any state
it's retaining about that login request, as it has been cancelled and
thus invalidated. This seems like a reasonable idea, in fact, since
leaving a "session" open indefinitely increases the chances that someone
will successfully attack the half-completed login later.

Implementing a "no" button might as well be optional for ID servers,
since there's no way to require it anyway. Users will still have the
option to just close the confirm window or hit the back button, of
course. The "no" button's two purposes are to act as a UI cue to the
user and to allow the consumer to cancel the request if it wishes, but
the consumer should be prepared to eventually clean up old requests even
if a cancel message was never recieved.

Sound reasonable?