Subject: [OAUTH-WG] Section 7.2

From: Eran Hammer <[email-masked]>
Date: Thu, 14 Jun 2012 21:58:23 +0000

One simple solution is to define the new error location as an opt-in registry for oauth-centric token authentication methods. Instead of requiring new schemes to use it and deal with all the confusing qualifications, just narrowly define the new registry as a service for new token authentication methods seeking to share a common error representation format with the Bearer and other schemes. This removes the explicit 'error' parameter name issue, as well as any other restrictions or limitations. It also removes the MUST.

IOW, the new text will establish a common registry for sharing error codes across oauth-centric token authentication schemes and can recommend that such schemes opt into the registry if they return error status beyong HTTP codes. Such a resolution will be simple to explain and will make the registry intentions very clear and straigh forward.

If this is acceptable, I can propose new text for 7.2 based on the latest draft.

Just an idea.

EH

---

From: Mike Jones <[email-masked]>
Date: Thu, 14 Jun 2012 22:01:46 +0000

That sounds fine to me.  If you want to take a stab at proposed text, have at it!

-- Mike

________________________________
From: Eran Hammer
Sent: 6/14/2012 2:59 PM
To: [email-masked] WG ([email-masked])
Subject: [OAUTH-WG] Section 7.2

Just an idea.

EH

---

From: Eran Hammer <[email-masked]>
Date: Thu, 14 Jun 2012 22:23:20 +0000

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

---

From: Eran Hammer <[email-masked]>
Date: Thu, 14 Jun 2012 22:29:10 +0000

Mike - if you want to add the other error parameters as suggestions, that would be fine by me.

EH

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Eran Hammer
> Sent: Thursday, June 14, 2012 3:23 PM
> To: Mike Jones; [email-masked] WG ([email-masked])
> Subject: Re: [OAUTH-WG] Section 7.2
> 
> 7.2.  Error Response
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Mike Jones <[email-masked]>
Date: Fri, 15 Jun 2012 01:15:13 +0000

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

   authentication schemes.

   New authentication schemes designed primarily for OAuth token

   authentication SHOULD define a mechanism for providing an

   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-masked]]
Sent: Thursday, June 14, 2012 3:29 PM
To: Eran Hammer; Mike Jones; [email-masked] WG ([email-masked])
Subject: RE: [OAUTH-WG] Section 7.2

EH

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf

> To: Mike Jones; [email-masked]<mailto:[email-masked]> WG ([email-masked]<mailto:[email-masked]>)

> [email-masked]<mailto:[email-masked]>

---

From: Eran Hammer <[email-masked]>
Date: Fri, 15 Jun 2012 06:32:25 +0000

WFM.

This will be the new text for 7.2 unless someone has any additional feedback or concerns.

This closes my issue with the new error registry changes.

EH

From: Mike Jones [mailto:[email-masked]]
Sent: Thursday, June 14, 2012 6:15 PM
To: Eran Hammer; [email-masked] WG ([email-masked])
Subject: RE: [OAUTH-WG] Section 7.2

7.2.  Error Response

   authentication schemes.

                                                            -- Mike

               desgined -> designed

-----Original Message-----
From: Eran Hammer [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Thursday, June 14, 2012 3:29 PM
To: Eran Hammer; Mike Jones; [email-masked]<mailto:[email-masked]> WG ([email-masked]<mailto:[email-masked]>)
Subject: RE: [OAUTH-WG] Section 7.2

EH

---

From: William Mills <[email-masked]>
Date: Fri, 15 Jun 2012 11:06:14 -0700 (PDT)

+1

> From: Eran Hammer <[email-masked]>
>To: Mike Jones <[email-masked]>; "[email-masked] WG ([email-masked])" <[email-masked]> 
>Sent: Thursday, June 14, 2012 11:32 PM
>From:Mike Jones [mailto:[email-masked]]

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 15 Jun 2012 21:28:07 +0300

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

---

From: Mike Jones <[email-masked]>
Date: Fri, 15 Jun 2012 19:06:33 +0000

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-masked]] 
Sent: Friday, June 15, 2012 11:28 AM
To: Mike Jones
Cc: Hannes Tschofenig; Eran Hammer; [email-masked] WG ([email-masked])
Subject: Re: [OAUTH-WG] Section 7.2

Hi Mike, 

Ciao
Hannes

On Jun 15, 2012, at 4:15 AM, Mike Jones wrote:

> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Eran Hammer

---

From: Mike Jones <[email-masked]>
Date: Sat, 16 Jun 2012 19:17:06 +0000

While adding the new text into a proposed draft, I realized that no character set restrictions on the error code values were defined in the agreed text.  Therefore, I've added the following sentence (which was already present in -27):
                 Values for these error codes MUST NOT include
                 characters outside the set %x20-21 / %x23-5B / %x5D-7E.

This is the same restriction that is referenced every other place that the "error" parameter is used in the draft.

                                                            -- Mike

WFM.

EH

From: Mike Jones [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Thursday, June 14, 2012 6:15 PM
To: Eran Hammer; [email-masked]<mailto:[email-masked]> WG ([email-masked]<mailto:[email-masked]>)
Subject: RE: [OAUTH-WG] Section 7.2

7.2.  Error Response

   authentication schemes.

                                                            -- Mike

               desgined -> designed

-----Original Message-----
From: Eran Hammer [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Thursday, June 14, 2012 3:29 PM
To: Eran Hammer; Mike Jones; [email-masked]<mailto:[email-masked]> WG ([email-masked]<mailto:[email-masked]>)
Subject: RE: [OAUTH-WG] Section 7.2

EH

---

From: Eran Hammer <[email-masked]>
Date: Sat, 16 Jun 2012 19:43:37 +0000

I would rather these restrictions be in the error registry section below and add a forward reference from 7.2.

EH

From: Mike Jones [mailto:[email-masked]]
Sent: Saturday, June 16, 2012 12:17 PM
To: Eran Hammer; [email-masked] WG ([email-masked])
Subject: RE: [OAUTH-WG] Section 7.2

                                                            -- Mike

WFM.

EH

7.2.  Error Response

   authentication schemes.

                                                            -- Mike

               desgined -> designed

-----Original Message-----
From: Eran Hammer [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Thursday, June 14, 2012 3:29 PM
To: Eran Hammer; Mike Jones; [email-masked]<mailto:[email-masked]> WG ([email-masked]<mailto:[email-masked]>)
Subject: RE: [OAUTH-WG] Section 7.2

EH

---

From: Mike Jones <[email-masked]>
Date: Sat, 16 Jun 2012 19:54:18 +0000

OK - will do.

Sent: 6/16/2012 12:43 PM

EH

While adding the new text into a proposed draft, I realized that no character set restrictions on the error code values were defined in the agreed text.  Therefore, I’ve added the following sentence (which was already present in -27):
                 Values for these error codes MUST NOT include
                 characters outside the set %x20-21 / %x23-5B / %x5D-7E.

This is the same restriction that is referenced every other place that the “error” parameter is used in the draft.

                                                            -- Mike

WFM.

EH

7.2.  Error Response

   authentication schemes.

                                                            -- Mike

               desgined -> designed

-----Original Message-----
From: Eran Hammer [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Thursday, June 14, 2012 3:29 PM
To: Eran Hammer; Mike Jones; [email-masked]<mailto:[email-masked]> WG ([email-masked]<mailto:[email-masked]>)
Subject: RE: [OAUTH-WG] Section 7.2

EH

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 18 Jun 2012 15:01:45 +0300

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.)

---

From: Eran Hammer <[email-masked]>
Date: Mon, 18 Jun 2012 17:13:47 +0000

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

> Sent: Monday, June 18, 2012 5:02 AM
> To: Mike Jones
> this text below does not prohibit error information to be sent back to the
> client (otherwise there would be a MUST NOT).
> 
> > 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:
> >
> > 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
> >
> >> 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
> >>