Re: [OAUTH-WG] Section 7.2

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:hannes.tschofenig@gmx.net]
> Sent: Monday, June 18, 2012 5:02 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,
> 
> 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:hannes.tschofenig@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:eran@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-bounces@ietf.org [mailto:oauth-bounces@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
> >
> >
> >