While this can work, it
seems like it's mixing semantics a little as well. 'invalid_request'
normally mean that the request is malformed in some way. Even
'unsupported parameter value' is really addressing a malformed
request (e.g. a parameter only allows values of 'true' and 'false'
and the invocation uses the value 'maybe').
What about registering an error code of 'invalid_parameter_value'.
Then the description could explain which parameter value is
invalid and possibly why. We might even be able to shorten this to
'invalid_parameter' as 'invalid_request' handles the case of an
unsupported/invalid parameter name.
I did a quick check of the OpenID Connect specs and they also
don't define an 'invalid_parameter' error code.
Thanks,
George
On 1/9/13 8:34 AM, Peter Mauritius
wrote:
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
includes an unsupported parameter value
Perhaps we should drop the error-code and use invalid-request with
a error-description explaining the token parameter is not usable.
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 OAuth Extensions Error Registration sections
according to 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-299 peter.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
--
 |
