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 Dron
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. (feedbac
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
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 coll
ay, January 7, 2013 4:08 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt
Hi,
the new revision is based on the WGLC feedback and incorporates the following
changes:
- renamed "access grant" to "authorization" and reworded parts of
really not authorization that is being revoked it's the grant
>
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
> Torsten Lodderstedt
> Sent: Monday, January 7, 2013 4:08 AM
> To: oauth@ietf.org
> Subject: Re: [OAU
auth-boun...@ietf.org>
[mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt
Sent: Monday, January 7, 2013 4:08 AM
To: oauth@ietf.org <mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt
Hi,
the new revision is based on the WGLC fee
.@ietf.org>
[mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt
Sent: Monday, January 7, 2013 4:08 AM
To: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt
Hi,
the new revision is based on the WGLC feedback and incorporat
rer
>
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
> Justin Richer
> Sent: Monday, January 07, 2013 11:36 AM
> To: Torsten Lodderstedt
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt
>
> "Acces
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
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.
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 e
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 o
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, sc
14 matches
Mail list logo
