Subject: [OAUTH-WG] What error codes do you need?

From: David Recordon <[email-masked]>
Date: Mon, 22 Mar 2010 10:56:46 -0700

In drafting OAuth 2.0 I removed a lot of the error codes throughout
the flows and in this draft encouraged people to use HTTP status codes
(like 1.0a does).  I've heard the feedback from multiple people that
they'd like more specific error codes than what can be expressed in
HTTP.  I'd like to use this thread – or ideally a wiki page that
someone creates – to build consensus around the error codes needed
throughout protocol responses.

Is someone willing to take the lead on this?  http://wiki.oauth.net/
should be easy enough to create a new page on.

Thanks,
--David

---

From: Chris Messina <[email-masked]>
Date: Mon, 22 Mar 2010 13:26:48 -0700

We've had this page on the wiki for some time... perhaps it could be updated
to actually offer all the appropriate error codes (including those from
HTTP) that are relevant?

http://wiki.oauth.net/ErrorCases

Chris

On Mon, Mar 22, 2010 at 10:56 AM, David Recordon <[email-masked]>wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Chris Messina
Open Web Advocate, Google

Personal: http://factoryjoe.com
Follow me on Buzz: http://buzz.google.com/chrismessina
...or Twitter: http://twitter.com/chrismessina

This email is:   [ ] shareable    [X] ask first   [ ] private

---

From: Justin Hart <[email-masked]>
Date: Mon, 22 Mar 2010 16:02:05 -0600

Was there early discussion that had much of the work in the ProblemReporting
extension included for 2.0?

http://wiki.oauth.net/ProblemReporting

On Mon, Mar 22, 2010 at 2:26 PM, Chris Messina <[email-masked]>wrote:

> We've had this page on the wiki for some time... perhaps it could be
> updated to actually offer all the appropriate error codes (including those
> from HTTP) that are relevant?
>

---

From: Paul Lindner <[email-masked]>
Date: Mon, 22 Mar 2010 15:42:04 -0700

+1 to the problem reporting codes.  We've found them very useful at
LinkedIn.

I'd also like to see throttling error codes, since many APIs support this
concept.

On Mon, Mar 22, 2010 at 3:02 PM, Justin Hart <[email-masked]> wrote:

> Was there early discussion that had much of the work in the
> ProblemReporting extension included for 2.0?
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Mar 2010 22:02:45 -0700

In case it's helpful, BCP 56 / RFC 3205 provides recommendations for  
using HTTP as a substrate for other protocols:
<https://tools.ietf.org/html/bcp56>
... in particular with respect to status codes:
<https://tools.ietf.org/html/bcp56#section-8>

It's worth thinking about how that document applies to OAuth, since  
the goal here isn't really necessariliy to use HTTP as a substrate,  
but rather to extend HTTP in certain ways.

--Richard

---

From: John Panzer <[email-masked]>
Date: Tue, 23 Mar 2010 09:54:15 -0700

That's an interesting and informative RFC, but it recommends using the 500
response code for all errors (unless I'm misreading).  Errors due to
incorrect input should be 4xx.

On Mon, Mar 22, 2010 at 10:02 PM, Richard Barnes <[email-masked]> wrote:

> In case it's helpful, BCP 56 / RFC 3205 provides recommendations for using
> HTTP as a substrate for other protocols:
>
> It's worth thinking about how that document applies to OAuth, since the
> goal here isn't really necessariliy to use HTTP as a substrate, but rather
> to extend HTTP in certain ways.
>
> --Richard
>
>
>
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 23 Mar 2010 10:09:19 -0700

Well, the relevant part says "200 or 500"; the basic message is that  
if your HTTP-using application has an error, but the HTTP was OK, then  
you shouldn't have an HTTP-layer error.  So for instance, in the  
GEOPRIV HELD protocol [1], every request returns 200 unless the HTTP  
is screwed up, and there's an <errorResponse> element that provides  
application-layer codes and explanations.

Again, this model might not make sense for OAuth, since OAuth is more  
tied into the HTTP layer than layered on top of it.  You could  
probably make a case for using 401/403 in this space, and maybe for  
some new codes.

--Richard

[1] http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery

On Mar 23, 2010, at 9:54 AM, John Panzer wrote:

> That's an interesting and informative RFC, but it recommends using  
> the 500 response code for all errors (unless I'm misreading).   
> Errors due to incorrect input should be 4xx.
>

---

From: John Panzer <[email-masked]>
Date: Tue, 23 Mar 2010 10:18:08 -0700

Ah, ok.  I disagree with this as blanket recommendation though it can make
sense in some cases.

Agreed that OAuth is more of a plug-in for HTTP than a separate protocol
layered on top.

On Tue, Mar 23, 2010 at 10:09 AM, Richard Barnes <[email-masked]> wrote:

> Well, the relevant part says "200 or 500"; the basic message is that if
> your HTTP-using application has an error, but the HTTP was OK, then you
> shouldn't have an HTTP-layer error.  So for instance, in the GEOPRIV HELD
> protocol [1], every request returns 200 unless the HTTP is screwed up, and
> there's an <errorResponse> element that provides application-layer codes and
> explanations.
>
> Again, this model might not make sense for OAuth, since OAuth is more tied
> into the HTTP layer than layered on top of it.  You could probably make a
> case for using 401/403 in this space, and maybe for some new codes.
>
> --Richard
>