Ok,now I understand your intention. In oauth-revocation the token is just a parameter not an authorization token as in RFC6750. RFC6749 uses "invalid_request" for
Perhaps we should drop the error-code and use invalid-request with a error-description explaining the token parameter is not usable.includes an unsupported parameter value
Regards Peter On 09.01.2013 14:08, George Fletcher wrote:
Hi Peter,I do agree that the meanings of 'invalid_token' between the two specs (6750 and revocation) are different. After thinking about this for a while, I've determined, at least for myself, what the difference is between the 'invalid_token' error code in RFC 6750 and the revocation spec.In RFC 6750 'invalid_token' means that the authorization token for the request is invalid.In 'oauth-revocation', 'invalid_token' means that the parameter containing the token to be revoked is invalid.I am very concerned about using the same error string, 'invalid_token', to mean two different things. While the semantic difference is not great in this case, I think it sets a bad precedent for OAuth to have the same error string have two different semantic meanings.I do agree that the error code used in this spec should be registered. Thanks, George On 1/8/13 5:07 PM, Peter Mauritius wrote:Hi George,RFC6750 defines "invalid-token" for access tokens which is not the case for "invalid-token" in the revocation specification. Here it is applicable for refresh tokens as well. Therefore we should not simply reference the "invalid-token" of RFC6750.As far as I understand both, the reviewed specification and RFC6750, reference RFC6749. RFC6750 includes in section 6.1 <http://tools.ietf.org/html/rfc6750#section-6.2> OAuth Extensions Error Registration sections according to RFC6749 section 11.4. <http://tools.ietf.org/html/rfc6749#section-11.4> for the error codes defined throughout the document including "invalid-token".I am not very experienced in the formal process but shouldn't we add such sections for the two error codes defined in the revocation document? Especially for "invalid-token" we should define an error registration section that defines the error code for our error usage location and protocol extension to distinguish it from RFC6750 and to avoid confusion. Doing this I hope there is no necessity to add a reference to RFC6750 or to define a new error code.What do the more experienced reviewers think? Regards Peter Am 07.01.13 17:25, schrieb George Fletcher:My concern with leaving both specs separated is that over time the semantics of the two error codes could diverge and that would be confusing for developers. If we don't want to create a dependency on RFC 6750, then I would recommend a change to the error code name so that there is no name collision or confusion.Thanks, George On 1/7/13 11:18 AM, Torsten Lodderstedt wrote:Hi George,thank you for pointing this out. Your proposal sounds reasonable although the revocation spec does not build on top of RFC 6750.As refering to RFC 6750 would create a new dependency, one could also argue it would be more robust to leave both specs separated.What do others think? regards, Torsten. Am 07.01.2013 17:12, schrieb George Fletcher:One quick comment...Section 2.0: Both RFC 6750 and this specification define the 'invalid_token' error code.Should this spec reference the error code from RFC 6750? Thanks, George On 1/7/13 7:08 AM, Torsten Lodderstedt wrote:Hi,the new revision is based on the WGLC feedback and incorporates the following changes:- renamed "access grant" to "authorization" and reworded parts of Abstract and Intro in order to better align with core spec wording (feedback by Amanda)- improved formatting of section 2.1. (feedback by Amanda)- improved wording of last paragraph of section 6 (feedback by Amanda) - relaxed the expected behavior regarding revocation of related tokens and the authorization itself in order to remove unintended constraints on implementations (feedback by Mark) - replaced description of error handling by pointer to respective section of core spec (as proposed by Peter) - adopted proposed text for implementation note (as proposed by Hannes)regards, Torsten. Am 07.01.2013 13:00, schrieb internet-dra...@ietf.org:A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF.Title : Token Revocation Author(s) : Torsten Lodderstedt Stefanie Dronia Marius Scurtescu Filename : draft-ietf-oauth-revocation-04.txt Pages : 8 Date : 2013-01-07 Abstract:This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to cleanup security credentials.A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-revocation-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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-- Peter Mauritius Chief Technical Director Senior Consultant Tel: +49 721 96448-0 Fax: +49 721 96448-299peter.maurit...@fun.de fun communications GmbH Lorenzstr. 29 D-76135 Karlsruhe Geschaeftsfuehrer Johannes Feulner Amtsgericht Mannheim HRB 106906 http://www.fun.de http://blogs.fun.de http://www.twitter.com/fun_de http://www.facebook.com/funcommunications
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
