On Sat, Feb 26, 2011 at 5:16 AM, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > thank you for your feedback. > > Am 03.02.2011 02:01, schrieb Marius Scurtescu: >> >> Following up on the Token Revocation extension proposed at: >> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >> >> I am suggesting three changes to this extension: >> >> 1. Either drop client authentication or make it optional. If clients >> want to revoke tokens, more power to them. If it is a malicious >> client, why would the authorization server deny revoking tokens? > > The impact of an unauthorized revocation is merely inconvenience since the > client has the go through the authorization process again. Nevertheless, I > would like to add some protection here.
If this inconvenience is done on purpose then the token is in the wrong hands. In which case you really want this token revoked, why would you make that more difficult? If the inconvenience is some error, then it will happen with or without credentials. I think client authentication should be optional at best. > My suggestion: the authorization server should require authentication for > clients having such credentials. > >> 2. Can we drop the "token_type" parameter, as suggested before? > > yes, we can. I will modify this in the next revision of the I-D. Great, thanks. >> 3. "authorization server MUST also invalidate all access tokens issued >> for that refresh token." can we change this MUST to a SHOULD? > > Why? The server is only required to revoke the access tokens if it is > capable to do so. Because it could be expensive, or impossible, for the authorization server to track down all access tokens associated with a refresh token. >> In case of success, why is the server supposed to return 204 instead >> of 200? Just worried that this will confuse clients. > > because there is no response body (required). I'm open to change it to 200 > but what data shall be contained in the response? An empty response body with 200 is illegal? A couple more suggestions: 1. Allow GET requests as well. This helps JavaScript clients. 2. Allow JSONP requests, for JavaScript clients as well. Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
