Same as any SHOULD. Do it unless you have a good reason not to. We have plenty of other SHOULDs without any detailed explanation of the qualifications.
EH > -----Original Message----- > From: Hannes Tschofenig [mailto:[email protected]] > Sent: Monday, June 18, 2012 5:02 AM > To: Mike Jones > Cc: Hannes Tschofenig; Eran Hammer; [email protected] WG ([email protected]) > Subject: Re: [OAUTH-WG] Section 7.2 > > Hi Mike, > > this text below does not prohibit error information to be sent back to the > client (otherwise there would be a MUST NOT). > > So, if a developer reads this below then when should he send an error > response and when not? > > Ciao > Hannes > > PS: (I also believe that the "i.e." should rather be a "e.g." in the text > below.) > > On Jun 15, 2012, at 10:06 PM, Mike Jones wrote: > > > 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:[email protected]] > > Sent: Friday, June 15, 2012 11:28 AM > > To: Mike Jones > > Cc: Hannes Tschofenig; Eran Hammer; [email protected] WG > ([email protected]) > > 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:[email protected]] > >> Sent: Thursday, June 14, 2012 3:29 PM > >> To: Eran Hammer; Mike Jones; [email protected] WG ([email protected]) > >> 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: [email protected] [mailto:[email protected]] On > >>> Behalf Of Eran Hammer > >>> Sent: Thursday, June 14, 2012 3:23 PM > >>> To: Mike Jones; [email protected] WG ([email protected]) > >>> 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 > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/oauth > >> > >> _______________________________________________ > >> OAuth mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
