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

[George Fletcher <[e-mail]>]

+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] 
> <mailto:[e-mail]>> wrote:
>
>     FWIW, we return unauthorized_client.
>
>     Le 31 janv. 2014 18:06, "Todd W Lainhart" <[e-mail]
>     <mailto:[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 <tel:[phone]>
>         2-276-4705 (T/L)
>         [e-mail] <mailto:[e-mail]>*
>
>
>
>
>
>
>         From: Brian Campbell <[e-mail]
>         <mailto:[e-mail]>>
>         To: oauth <[e-mail] <mailto:[e-mail]>>,
>         Date: 01/31/2014 11:58 AM
>         Subject: [OAUTH-WG] Another question on RFC 7009
>         Sent by: "OAuth" <[e-mail]
>         <mailto:[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_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] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/oauth
>
>
>         _______________________________________________
>         OAuth mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth

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