Subject: Re: [OAUTH-WG] Another question on RFC 7009

From: Brian Campbell <[email-masked]>
Date: Fri, 7 Feb 2014 12:43:59 -0700

Thanks, Todd and Thomas, for the responses. After some internal debate, I
think we are going to treat it as an invalid token (which it is in that
context) and return a 200.

On Fri, Jan 31, 2014 at 11:19 AM, Thomas Broyer <[email-masked]> wrote:

> FWIW, we return unauthorized_client.
> Le 31 janv. 2014 18:06, "Todd W Lainhart" <[email-masked]> a écrit :
>
> > ...what's the intended way that the "request is refused and the client
>> is informed of the error" when the the token was not issued to the client
>> making the revocation request?
>>
>> We return an error_code of "invalid_request" and an appropriate error
>> message.
>>
>>
>>
>>
>>
>>
>>
>> * Todd Lainhart Rational software IBM Corporation 550 King Street,
>> Littleton, MA 01460-1250*
>>
>>
>> * 1-978-899-4705 <1-978-899-4705> 2-276-4705 (T/L) [email-masked]
>> <[email-masked]>*
>>
>>
>>
>>
>> From:        Brian Campbell <[email-masked]>
>> To:        oauth <[email-masked]>,
>> Date:        01/31/2014 11:58 AM
>> Subject:        [OAUTH-WG] Another question on RFC 7009
>> Sent by:        "OAuth" <[email-masked]>
>> ------------------------------
>>
>>
>>
>> Greetings WG,
>>
>> In section 2.1 of RFC 7009, it says:
>>
>>    "The authorization server first validates the client credentials (in
>>    case of a confidential client) and then verifies whether the token
>>    was issued to the client making the revocation request.  If this
>>    validation fails, the request is refused and the client is informed
>>    of the error by the authorization server as described below."
>>
>> The only error described below is "unsupported_token_type" which doesn't
>> seem appropriate here. The errors in
>> *http://tools.ietf.org/html/rfc6749#section-5.2*<http://tools.ietf.org/html/rfc6749#section-5.2>are referenced too and, while "invalid_client" seems right for failed
>> client authentication, what's the intended way that the "request is refused
>> and the client is informed of the error" when the the token was not issued
>> to the client making the revocation request? None of the defined error
>> codes seem to fit.
>>
>> Furthermore, wouldn't it be better to go ahead and just revoke a token in
>> the case it's presented by the wrong client? I seem to recall some
>> discussion around this when 7009 was just a baby
>> draft-ietf-oauth-revocation and, while I don't recall the outcome, I was
>> surprised to look at the RFC again and see the text that is there.
>>
>> These questions came to me by way of a developer working on implementing
>> the RFC. I didn't have good answers, beyond the prognostication herein, so
>> I thought I'd take the questions to the WG list and the document authors.
>>
>> Thanks for any clarification,
>> Brian
>>
>> _______________________________________________
>> OAuth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>

---

From: George Fletcher <[email-masked]>
Date: Fri, 07 Feb 2014 14:55:54 -0500

+1 for this solution

Is this something that could be clarified in errata as it appears we 
have three different providers with three different solutions:)

Thanks,
George

On 2/7/14 2:43 PM, Brian Campbell wrote:
> Thanks, Todd and Thomas, for the responses. After some internal 
> debate, I think we are going to treat it as an invalid token (which it 
> is in that context) and return a 200.
>
>
> On Fri, Jan 31, 2014 at 11:19 AM, Thomas Broyer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Le 31 janv. 2014 18:06, "Todd W Lainhart" <[email-masked]
>     <mailto:[email-masked]>> a écrit :
>
>         > ...what's the intended way that the "request is refused and
>         the client is informed of the error" when the the token was
>         not issued to the client making the revocation request?
>
>         We return an error_code of "invalid_request" and an
>         appropriate error message.
>
>         *
>
>
>         Todd Lainhart
>         Rational software
>         IBM Corporation
>         550 King Street, Littleton, MA 01460-1250**
>         1-978-899-4705 <tel:1-978-899-4705>
>         2-276-4705 (T/L)
>         [email-masked] <mailto:[email-masked]>*
>
>
>
>
>
>
>         From: Brian Campbell <[email-masked]
>         <mailto:[email-masked]>>
>         To: oauth <[email-masked] <mailto:[email-masked]>>,
>         Sent by: "OAuth" <[email-masked]
>         <mailto:[email-masked]>>
>         ------------------------------------------------------------------------
>
>
>
>         Greetings WG,
>
>         The only error described below is "unsupported_token_type"
>         which doesn't seem appropriate here. The errors in
>         _http://tools.ietf.org/html/rfc6749#section-5.2_are referenced
>         too and, while "invalid_client" seems right for failed client
>         authentication, what's the intended way that the "request is
>         refused and the client is informed of the error" when the the
>         token was not issued to the client making the revocation
>         request? None of the defined error codes seem to fit.
>
>         Furthermore, wouldn't it be better to go ahead and just revoke
>         a token in the case it's presented by the wrong client? I seem
>         to recall some discussion around this when 7009 was just a
>         baby draft-ietf-oauth-revocation and, while I don't recall the
>         outcome, I was surprised to look at the RFC again and see the
>         text that is there.
>
>         These questions came to me by way of a developer working on
>         implementing the RFC. I didn't have good answers, beyond the
>         prognostication herein, so I thought I'd take the questions to
>         the WG list and the document authors.
>
>         [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>

-- 
George Fletcher <http://connect.me/gffletch>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 7 Feb 2014 13:00:04 -0700

I agree it could clarified. But it's also what should be a vary rare
erroneous condition so there's not really an interoperability concern with
the ambiguity that's there now.

On Fri, Feb 7, 2014 at 12:55 PM, George Fletcher <[email-masked]> wrote:

>  +1 for this solution
>
> Is this something that could be clarified in errata as it appears we have
> three different providers with three different solutions:)
>
> Thanks,
> George
>
> On Fri, Jan 31, 2014 at 11:19 AM, Thomas Broyer <[email-masked]>wrote:
>
>>  > ...what's the intended way that the "request is refused and the
>>> client is informed of the error" when the the token was not issued to the
>>> client making the revocation request?
>>>
>>> Furthermore, wouldn't it be better to go ahead and just revoke a token
>>> in the case it's presented by the wrong client? I seem to recall some
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
> --
>  <http://connect.me/gffletch>
>