Subject: [OAUTH-WG] Review of Token Revocation draft

From: Peter Mauritius <[email-masked]>
Date: Fri, 21 Dec 2012 23:15:29 +0100

During the last week I had the chance to implement the non optional 
features of the token revokation draft. I would be glad if the document 
would get a closer connection to the refrenced RFC6749 regarding the 
error handling.

The draft states to use HTTP status 401 and 403 for certain error 
conditions. RFC6749 declares this as optional (OK, not for the 
Authorization header). The implemation of the token revokation endpoint 
in conjunction with a tokens endpoint would be much easier if there is a 
single way to handle exceptions which conforms to RFC6749.

Therefore I want to suggest to replace

> Status code 401 indicates a
>     failed client authentication, whereas a status code 403 is used if
>     the client is not authorized to revoke the particular token.  For all
>     other error conditions, a status code 400 is used along with an error
>     response as defined insection 5.2  <http://tools.ietf.org/html/draft-ietf-oauth-revocation-03#section-5.2>. of [RFC6749  <http://tools.ietf.org/html/rfc6749>].
with

    The error presentation conforms to the defintion in section 5.2 of
    [RFC6749].

To express the status code 403 I suggest to use the error code 
"unauthorized_client" of RFC6749 in conjunction with status code 400. 
The additional error codes defined in the draft will remain of course.

Happy apocalypse ;-)
   Peter Mauritius

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 25 Dec 2012 14:19:45 +0100

Hi Peter,

your proposal sounds reasonable.

Since it involves a change to the interface spec (400 instead of 403 in 
case of unauthorized access) I would like to ask the working group for 
feedback.

What do you think? I especially would like to gain feedback from 
implementors of the draft (e.g. Marius, Chuck, Justin).

regards,
Torsten.

Am 21.12.2012 23:15, schrieb Peter Mauritius:
> features of the token revokation draft. I would be glad if the 
> document would get a closer connection to the refrenced RFC6749 
> regarding the error handling.
>
> Authorization header). The implemation of the token revokation 
> endpoint in conjunction with a tokens endpoint would be much easier if 
> there is a single way to handle exceptions which conforms to RFC6749.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Fri, 28 Dec 2012 10:10:13 -0500

Sounds reasonable to me.

  -- Justin

On 12/25/2012 08:19 AM, Torsten Lodderstedt wrote:
> Since it involves a change to the interface spec (400 instead of 403 
> in case of unauthorized access) I would like to ask the working group 
> for feedback.
>
>> endpoint in conjunction with a tokens endpoint would be much easier 
>> if there is a single way to handle exceptions which conforms to RFC6749.
>>
>>     The error presentation conforms to the defintion in section 5.2
>>     of [RFC6749].
>>