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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
