> ...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
2-276-4705 (T/L)
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 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

Reply via email to