> -----Original Message-----
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
