Subject: Re: [OAUTH-WG] Draft13: What are the possible OAuth related access errors for section 7?

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 24 Mar 2011 14:53:08 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Phil Hunt
> Sent: Monday, February 21, 2011 4:49 PM
> To: OAuth WG
> Subject: [OAUTH-WG] Draft13: What are the possible OAuth related access
> errors for section 7?
> 
> When accessing a protected resource with what a client believes to be an
> valid token, what errors are possible/valid?  Is this specifically out of scope?

Made this clear (added parenthesis):

     "The methods used by the resource server
        to validate the access token (as well as any error responses) are beyond the scope of this
        specification, but generally involve an interaction or coordination between the resource
        server and the authorization server."

> Section 7 doesn't seem to cover possible error conditions.  E.g. the one that
> hit me just now, is how is an expired token indicated if at all (vs. invalid
> authorization).

A specific error for expired token (in the various steps of the protocol) was discussed multiple times and each one concluded with such an error code not being that valuable. I don't have a position on the matter but there is no consensus to define one for v2.

> Obviously in some cases, most sites won't give details. But still I found the
> issue of an expired token causing someone to try a refresh (section 6) to be a
> little unclear in draft 13.

What is unclear? If you have a valid refresh token and an invalid access token (for whatever reason), try it.
 
> Also, would/should more specific errors be defined in the various Bearer,
> Mac, etc specifications?

I have taken the position that the HTTP error codes (400, 401, and 403) sufficiently cover any error state related to the MAC protocol. I am not going to define any additional error codes in the response.

EHL