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

[Brian Campbell <[e-mail]>]

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 <[e-mail]> 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 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 <[e-mail]>wrote:
>
>> FWIW, we return unauthorized_client.
>> Le 31 janv. 2014 18:06, "Todd W Lainhart" <[e-mail]> 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) [e-mail]
>>> <[e-mail]>*
>>>
>>>
>>>
>>>
>>> From:        Brian Campbell <[e-mail]>
>>> To:        oauth <[e-mail]>,
>>> Date:        01/31/2014 11:58 AM
>>> Subject:        [OAUTH-WG] Another question on RFC 7009
>>> Sent by:        "OAuth" <[e-mail]>
>>> ------------------------------
>>>
>>>
>>>
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
> --
> [image: George Fletcher] <http://connect.me/gffletch>
>