There are cases where the OAuth specs specifically *prohibit* returning an
error code or other error information, for security reasons. For instance,
http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-20#section-3.1 contains
the language:
If the request lacks any authentication information (i.e. the client
was unaware authentication is necessary or attempted using an
unsupported authentication method), the resource server SHOULD NOT
include an error code or other error information.
Hence, the SHOULDs, rather than MUSTs.
-- Mike
-----Original Message-----
From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
Sent: Friday, June 15, 2012 11:28 AM
To: Mike Jones
Cc: Hannes Tschofenig; Eran Hammer; oauth@ietf.org WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Section 7.2
Hi Mike,
I personally would find it better to have fewer SHOULDs. Most of them have been
there for a long time and so it is a bit late to complain but the challenge for
protocol architectures is to figure out under what conditions they should do
certain things.
Additionally, I don't buy the argument that a server should not provide error
responses (or to be only very brief, or even misleading) for a security point
of view because attackers typically know more than ordinary developers or users
and so you end up with a system that the normal user is unable to work with (in
a failure case) but adversaries nevertheless get what they want. This comment
relates to the first sentence that gives me the impression that the server may
not send any error message in case of a failure, which sounds strange to me.
Ciao
Hannes
On Jun 15, 2012, at 4:15 AM, Mike Jones wrote:
> Thanks for writing the text below. It looks fine to me. About adding the
> other error parameters as suggestions, that seems like a reasonable thing to
> do. How about the text at the end below, which adds mentions of
> error_description and error_uri?
>
> 7.2. Error Response
>
> If a resource access request fails, the resource server SHOULD inform
> the client of the error. While the specifics of such error responses
> are beyond the scope of this specification, this documents establishes
> a common registry for error values to be shared among OAuth token
> authentication schemes.
>
> New authentication schemes designed primarily for OAuth token
> authentication SHOULD define a mechanism for providing an
> error status code to the client, in which the error values allowed are
> registered in the error registry established by this specification. Such
> schemes MAY limit the set of valid error codes to a subset of the
> registered values. If the error code is returned using a named parameter,
> the parameter name SHOULD be "error".
>
> Other schemes capable of being used for OAuth token authentication, but
> not primarily designed for that purpose, MAY bind their error values to the
> registry in the same manner.
>
> New authentication schemes MAY choose to also specify the use of the
> "error_description" and "error_uri" parameters to return error information
> in a manner parallel to their usage in this specification.
>
>
> -- Mike
>
> P.S. If you already have the text you wrote in a copy of the draft, you
> should apply these spelling corrections:
> desgined -> designed
> authentiction -> authentication
>
> -----Original Message-----
> From: Eran Hammer [mailto:e...@hueniverse.com]
> Sent: Thursday, June 14, 2012 3:29 PM
> To: Eran Hammer; Mike Jones; oauth@ietf.org WG (oauth@ietf.org)
> Subject: RE: [OAUTH-WG] Section 7.2
>
> Mike - if you want to add the other error parameters as suggestions, that
> would be fine by me.
>
> EH
>
> > -----Original Message-----
> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
> > Behalf Of Eran Hammer
> > Sent: Thursday, June 14, 2012 3:23 PM
> > To: Mike Jones; oauth@ietf.org WG (oauth@ietf.org)
> > Subject: Re: [OAUTH-WG] Section 7.2
> >
> > 7.2. Error Response
> >
> > If a resource access request fails, the resource server SHOULD inform
> > the client of the error. While the specifics of such error responses
> > are beyond the scope of this specification, this documents establishes
> > a common registry for error values to be shared among OAuth token
> > authentication schemes.
> >
> > New authentication schemes desgined primarily for OAuth token
> > authentiction SHOULD define a mechanism for providing an
> > error status code to the client, in which the error values allowed are
> > registered in the error registry established by this specification. Such
> > schemes MAY limit the set of valid error codes to a subset of the
> > registered values. If the error code is returned using a named parameter,
> > the parameter name SHOULD be "error".
> >
> > Other schemes capable of being used for OAuth token authentication, but
> > not primarily designed for that purpose, MAY bind their error values to
> > the
> > registry in the same manner.
> >
> > EH
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
