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.bro...@gmail.com> wrote: > FWIW, we return unauthorized_client. > Le 31 janv. 2014 18:06, "Todd W Lainhart" <lainh...@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) lainh...@us.ibm.com >> <lainh...@us.ibm.com>* >> >> >> >> >> From: Brian Campbell <bcampb...@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-boun...@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 >> >>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
