Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt

From: [email-masked]
Date: Mon, 07 Jan 2013 04:00:57 -0800

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/

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 07 Jan 2013 13:08:16 +0100

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 07 Jan 2013 17:18:48 +0100

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,
>>
>> - relaxed the expected behavior regarding revocation of related 
>> tokens and the authorization itself in order to remove unintended 
>> constraints on implementations (feedback by Mark)

---

From: George Fletcher <[email-masked]>
Date: Mon, 07 Jan 2013 11:25:22 -0500

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

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 7 Jan 2013 17:21:50 +0000

Is "authorization" the best  choice here over "access grant" since it's really not authorization that is being revoked it's the grant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Torsten Lodderstedt
Sent: Monday, January 7, 2013 4:08 AM
To: [email-masked]
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 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.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 7 Jan 2013 20:24:45 +0100

Access grant might be the better term. That's why previous revisions used it. But as Amanda correctly pointed out, the core spec does not define a concept of an access grant. There is just the term authorization implicitly introduced via other definitions.

section 1.3 introduces authorization grants:
"An authorization grant is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token."

and section 1.4 defines access tokens as follows:
"An access token is a string representing an authorization issued to the client. The string is usually opaque to the client."

I tried to align the draft with this terminology.

---

From: Justin Richer <[email-masked]>
Date: Mon, 7 Jan 2013 14:35:59 -0500

"Access grant" was the old term that Eran came up with, and it has been 
replaced by "authorization grant", which I agree is also not as well 
defined as it could be. Both of these refer to the conceptual act of the 
resource owner saying "it is OK for this client to do these things". I 
objected to the language calling it a "credential", since that's 
misleading and has led to several developers I've run into thinking that 
it was the same thing as the access code, which it's not.

To best align the terminology, "authorization grant" as defined in 1.3 
is probably the best bet.

  -- Justin

On 01/07/2013 02:24 PM, Torsten Lodderstedt wrote:
> Access grant might be the better term. That's why previous revisions 
> used it. But as Amanda correctly pointed out, the core spec does not 
> define a concept of an access grant. There is just the term 
> authorization implicitly introduced via other definitions.
>
> "An authorization grant is a credential representing the resource
>     owner's authorization (to access its protected resources) used by the
>     client to obtain an access token."
>
> "An
>     access token is a string representing an authorization issued to the
>     client.  The string is usually opaque to the client."
>
> Am 07.01.2013 um 18:21 schrieb Anthony Nadalin <[email-masked] 
> <mailto:[email-masked]>>:
>
>> Is "authorization" the best  choice here over "access grant" since 
>> it's really not authorization that is being revoked it's the grant
>>
>> From: [email-masked] <mailto:[email-masked]> 
>> [mailto:[email-masked]] On Behalf Of Torsten Lodderstedt
>> To: [email-masked] <mailto:[email-masked]>
>> Am 07.01.2013 13:00, schrieb [email-masked] 
>> <mailto:[email-masked]>:
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Mike Jones <[email-masked]>
Date: Mon, 7 Jan 2013 20:12:36 +0000

+1 for using the same terminology as OAuth Core and Bearer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Monday, January 07, 2013 11:36 AM
To: Torsten Lodderstedt
Cc: [email-masked]
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt

"Access grant" was the old term that Eran came up with, and it has been replaced by "authorization grant", which I agree is also not as well defined as it could be. Both of these refer to the conceptual act of the resource owner saying "it is OK for this client to do these things". I objected to the language calling it a "credential", since that's misleading and has led to several developers I've run into thinking that it was the same thing as the access code, which it's not.

To best align the terminology, "authorization grant" as defined in 1.3 is probably the best bet.

 -- Justin

Am 07.01.2013 um 18:21 schrieb Anthony Nadalin <[email-masked]<mailto:[email-masked]>>:
Is "authorization" the best  choice here over "access grant" since it's really not authorization that is being revoked it's the grant

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Torsten Lodderstedt
Sent: Monday, January 7, 2013 4:08 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt

Hi,

regards,
Torsten.

Am 07.01.2013 13:00, schrieb [email-masked]<mailto:[email-masked]>:

   Title           : Token Revocation

Abstract:

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

OAuth mailing list

[email-masked]<mailto:[email-masked]>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 7 Jan 2013 21:31:30 +0100

But what is the same terminology? Authorization grant? I think 1.3 defines the authorization grant as an external representation of the authorization, not the authorization itself.

---

From: Peter Mauritius <[email-masked]>
Date: Tue, 08 Jan 2013 23:07:10 +0100

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:
> 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
>

-- 
Peter Mauritius   Chief Technical Director
Senior Consultant
Tel: +49 721 96448-0   Fax: +49 721 96448-299   [email-masked]

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

---

From: George Fletcher <[email-masked]>
Date: Wed, 09 Jan 2013 08:08:11 -0500

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 
> <http://tools.ietf.org/html/rfc6750#section-6.2>  OAuth Extensions 
> Error Registration sections according to RFC6749 section 11.4. 
>>> 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.
> Tel: +49 721 96448-0   Fax: +49 721 [email-masked]
>

---

From: Peter Mauritius <[email-masked]>
Date: Wed, 09 Jan 2013 14:34:17 +0100

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:
> 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.
>
>>>>>> Abstract and Intro in order to better align with core spec 
>>>>>> wording (feedback by Amanda)

---

From: George Fletcher <[email-masked]>
Date: Wed, 09 Jan 2013 10:40:53 -0500

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
>> In RFC 6750 'invalid_token' means that the authorization token for 
>> the request is invalid.
>>
>>> applicable for refresh tokens as well. Therefore we should not 
>>> simply reference the "invalid-token" of RFC6750.
>>>
>>> <http://tools.ietf.org/html/rfc6749#section-11.4> for the error 
>>> codes defined throughout the document including "invalid-token".
>>>
>>> location and protocol extension to distinguish it from RFC6750 and 
>>> to avoid confusion. Doing this I hope there is no necessity to add a 
>>>> 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
>>>>
>>>>>>> - renamed "access grant" to "authorization" and reworded parts 
>>>>>>> of Abstract and Intro in order to better align with core spec 
>>>>>>> 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)

-- 
George Fletcher <http://connect.me/gffletch>

---

From: Peter Mauritius <[email-masked]>
Date: Thu, 10 Jan 2013 22:37:15 +0100

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:
> 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 
>> 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
>>> 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.
>>>
>>> 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.
>>>
>>>> case for "invalid-token" in the revocation specification. Here it 
>>>> is applicable for refresh tokens as well. Therefore we should not 
>>>> As far as I understand both, the reviewed specification and 
>>>> RFC6750, reference RFC6749. RFC6750 includes in section 6.1 
>>>> 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 
>>>> 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.
>>>>
>>>>> 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
>>>>>

http://www.fun.de
http://blogs.fun.de