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

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 <t.broyer@gmail.com> wrote:

> FWIW, we return unauthorized_client.
> Le 31 janv. 2014 18:06, "Todd W Lainhart" <lainhart@us.ibm.com> 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) lainhart@us.ibm.com
>> <lainhart@us.ibm.com>*
>>
>>
>>
>>
>> From:        Brian Campbell <bcampbell@pingidentity.com>
>> To:        oauth <oauth@ietf.org>,
>> Date:        01/31/2014 11:58 AM
>> Subject:        [OAUTH-WG] Another question on RFC 7009
>> Sent by:        "OAuth" <oauth-bounces@ietf.org>
>> ------------------------------
>>
>>
>>
>> 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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>