Error behavior?

[Martin Atkins]

Carl Howells wrote:
> The one current empty space in the openid spec seems to be what the
> various pieces do for error conditions.
> 
> For example, what is the correct behavior when an openid server is
> contacted with a parameter of "openid.mode=checkid_immediat"?  That's
> not a valid value for the openid.mode parameter, so what should be done?
>  Return a 404?  A 500?
> 
> Assuming the consumer sent that as a typo or coding error, rather than
> some sort of malicious attack, neither of those behaviors seem friendly.
>  Would some sort of redirect including an "openid.error" field be the
> most appropriate?
> 
> Nearly everything so far has focused on the behavior of the system when
> everything works correctly, and the user is authenticated.  There hasn't
> been any recent discussion of error-handling, and how the server should
> handle failure to authenticate in the various check_id modes.
> 
> While those are several entirely separate cases, they need to be
> enumerated, and their behavior should be specified.  Anyone want to make
> a first pass?
> 

There are two broad kinds of error:
* Authentication error. This is already handled by returning the URL to
a "setup page" which gives the user the opportunity to log in or
authorize the session.
* Protocol error, where the consumer has done something wrong.

The first kind of error should be opaque. The consumer is given no
indication of why authentication failed assuming an otherwise-valid request.

The latter can be more granular, since ideally they are only messages to
a consumer developer, who will use them to fix his implementation and
then never see them again.

However, since they are messages to a person for debugging they don't
need to be machine-readable. The machine just needs to see "protocol
error" and some natural language string. Natural language does present
the difficulty that the programmer might not understand the language
that the ID server speaks, but I doubt we can achieve anywhere near the
right amount of granularity through error response codes without
building up an entire library of them which need to be handled... and
they still need to be described in natural language somewhere anyway.

Of course, this is putting the onus on the identity server to return
useful errors, which undoubtedly not all of them will bother to do. Lazy
implementors will just return protocol_error("Protocol Error"). There's
no way to stop that happening, and in fact I'd rather not force
implementors to have a whole load of extra code in there to figure out
what stupid mistake the consumer has made, as that's just going to be
offputting.