|
Hi George,
I am with you and support your suggestion. An "invalid_parameter"
error code would be a practical solution that would allow to
distinguish between token usage and token as parameter.
Regards
Peter
Am 09.01.13 16:40, schrieb George Fletcher:
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
--
--
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
|
smime.p7s