Subject: [OAUTH-WG] draft-ietf-oauth-revocation

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 03 Feb 2013 14:01:41 +0100

Hi all,

before I publish a new revision of the draft, I would like to sort out 
the following issues and would like to ask you for your feedback.

- Authorization vs. access grant vs. authorization grant: I propose to 
use "authorization grant".
- invalid_token error code: I propose to use the new error code 
"invalid_parameter" (as suggested by Peter and George). I don't see the 
need to register it (see 
http://www.ietf.org/mail-archive/web/oauth/current/msg10604.html) but 
would like to get your advice.
- Donald F. Coffin raised the need for a token_type parameter to the 
revocation request. Shall we re-consider this topic?

best regards,
Torsten.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 03 Feb 2013 15:10:03 +0200

Hi Torsten,

> would like to get your advice.

If you define a new error code (which 'invalid_parameter' is) then it 
would make sense to register it.
The mail exchange you reference refers to re-using an existing error 
code (namely invalid_request).

Ciao
Hannes

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 03 Feb 2013 14:12:45 +0100

Hi Hannes,

> would make sense to register it.

ok.

> code (namely invalid_request).

You also mention registering a new error code there. I was not sure what 
way you prefer, reusing invalid_request or introducing a new error code.

regards,
Torsten.

---

From: William Mills <[email-masked]>
Date: Sun, 3 Feb 2013 07:25:53 -0800 (PST)

Why do we need invalid_token as an error code at all?  To me it only introduces a way to get information about tokens.  Invalid parameter I can see as a use case, but if the token is invalid just return 200/OK because there is nothing to do.

-bill

________________________________
 From: Torsten Lodderstedt <[email-masked]>
To: OAuth WG <[email-masked]> 
Sent: Sunday, February 3, 2013 5:01 AM
Subject: [OAUTH-WG] draft-ietf-oauth-revocation
 
Hi all,

before I publish a new revision of the draft, I would like to sort out the following issues and would like to ask you for your feedback.

- Authorization vs. access grant vs. authorization grant: I propose to use "authorization grant".
- invalid_token error code: I propose to use the new error code "invalid_parameter" (as suggested by Peter and George). I don't see the need to register it (see http://www.ietf.org/mail-archive/web/oauth/current/msg10604.html) but would like to get your advice.
- Donald F. Coffin raised the need for a token_type parameter to the revocation request. Shall we re-consider this topic?

best regards,
Torsten.
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Sergey Beryozkin <[email-masked]>
Date: Sun, 03 Feb 2013 18:28:23 +0000

> revocation request. Shall we re-consider this topic?

Yes please if possible (I'm assuming 'access token' should be default, 
with an option to say it is refresh token)

Cheers, Sergey

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 4 Feb 2013 01:56:15 +0000

Yes on token_type

Sent from my Windows Phone
________________________________
From: Torsten Lodderstedt<mailto:[email-masked]>
Sent: ‎2/‎3/‎2013 6:02 AM
To: OAuth WG<mailto:[email-masked]>
Subject: [OAUTH-WG] draft-ietf-oauth-revocation

Hi all,

best regards,
Torsten.

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 4 Feb 2013 20:41:49 +0000

> - Authorization vs. access grant vs. authorization grant: I propose to use "authorization grant".

+1 to authorization grant

> - invalid_token error code: I propose to use the new error code "invalid_parameter" (as suggested by Peter and George). I don't see the need to register it (see http://www.ietf.org/mail-archive/web…

something more like "invalid_token_parameter" would maybe make sense, since it's not just *any* parameter, it's the special "token" parameter that we're talking about, but it's distinct from the invalid_token response. The introspection endpoint uses the same pattern of a token= parameter, but since the whole point of the introspection endpoint is determining token validity it doesn't actually throw an error here. 

I agree that it doesn't need to be registered (since it's on a different endpoint).

> - Donald F. Coffin raised the need for a token_type parameter to the revocation request. Shall we re-consider this topic?

Only if it's optional, and informational from the client's behalf. Would you define "access" and "refresh" values here, with a means for other specs (like OIDC) to put in their own values (like "id_token")?

 -- Justin

---

From: George Fletcher <[email-masked]>
Date: Mon, 04 Feb 2013 15:57:55 -0500

> I agree that it doesn't need to be registered (since it's on a different endpoint).
For what it's worth my thinking was that if we have an 
'invalid_parameter' error, then the description can define which 
parameter is invalid. I don't think we should create a bunch of specific 
error values that are endpoint specific and could overlap which is where 
the whole error return value started.

Thanks,
George

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 4 Feb 2013 21:10:23 +0000

On Feb 4, 2013, at 3:57 PM, George Fletcher <[email-masked]>
 wrote:

> For what it's worth my thinking was that if we have an 'invalid_parameter' error, then the description can define which parameter is invalid. I don't think we should create a bunch of specific error values that are endpoint specific and could overlap which is where the whole error return value started.
> 

Hm, I see what you're saying, but the error response is already endpoint specific. Though there is value in not having conflicting and/or confusing responses from different endpoints that use the same error code for different things. 

What it really comes down to is: what can the client do with this error? Could it do something with invalid_parameter that it couldn't do with invalid_token_parameter (among others), or vice versa? As I'm writing this out, I'm not convinced that it could, really, so this may be a bike shedding argument.

 -- Justin

---

From: Todd W Lainhart <[email-masked]>
Date: Mon, 4 Feb 2013 16:20:21 -0500

> Only if it's optional, and informational from the client's behalf. Would 
you define "access" and "refresh" values here, with a means for other 
specs (like OIDC) to put in their own values (like "id_token")?

I'd also like to see token_type explicitly called out, as we've also 
extended the spec for a token type.  Arguably the type could be encoded in 
the token itself, but it seems better to not require this of the 
implementation.

That said, the introspection endpoint doesn't disambiguate the incoming 
token via a token_type parameter.  Is there any reason to believe that it 
wouldn't see the same types of tokens that revocation would?

Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
[email-masked]

From:   "Richer, Justin P." <[email-masked]>
To:     Torsten Lodderstedt <[email-masked]>, 
Cc:     OAuth WG <[email-masked]>
Date:   02/04/2013 03:42 PM
Subject:        Re: [OAUTH-WG] draft-ietf-oauth-revocation
Sent by:        [email-masked]

something more like "invalid_token_parameter" would maybe make sense, 
since it's not just *any* parameter, it's the special "token" parameter 
that we're talking about, but it's distinct from the invalid_token 
response. The introspection endpoint uses the same pattern of a token= 
parameter, but since the whole point of the introspection endpoint is 
determining token validity it doesn't actually throw an error here. 

I agree that it doesn't need to be registered (since it's on a different 
endpoint).

Only if it's optional, and informational from the client's behalf. Would 
you define "access" and "refresh" values here, with a means for other 
specs (like OIDC) to put in their own values (like "id_token")?

 -- Justin

---

From: Todd W Lainhart <[email-masked]>
Date: Tue, 5 Feb 2013 11:46:28 -0500

> Could it do something with invalid_parameter that it couldn't do with 
invalid_token_parameter (among others), or vice versa? 

I'm not imagining a client doing anything programmatically useful with the 
distinction.

Todd Lainhart
Rational software
IBM Corporation

From:   "Richer, Justin P." <[email-masked]>
To:     George Fletcher <[email-masked]>, 
Cc:     OAuth WG <[email-masked]>
Date:   02/04/2013 04:10 PM
Subject:        Re: [OAUTH-WG] draft-ietf-oauth-revocation
Sent by:        [email-masked]

> For what it's worth my thinking was that if we have an 
'invalid_parameter' error, then the description can define which parameter 
is invalid. I don't think we should create a bunch of specific error 
values that are endpoint specific and could overlap which is where the 
whole error return value started.

Hm, I see what you're saying, but the error response is already endpoint 
specific. Though there is value in not having conflicting and/or confusing 
responses from different endpoints that use the same error code for 
different things. 

What it really comes down to is: what can the client do with this error? 
Could it do something with invalid_parameter that it couldn't do with 
invalid_token_parameter (among others), or vice versa? As I'm writing this 
out, I'm not convinced that it could, really, so this may be a bike 
shedding argument.

 -- Justin

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 5 Feb 2013 20:41:18 +0100

Why not adopting Bill's suggestion and just return HTTP status code 200 for (already) invalid tokens?

regards,
Torsten.

Am 05.02.2013 um 17:46 schrieb Todd W Lainhart <[email-masked]>:

> > Could it do something with invalid_parameter that it couldn't do with invalid_token_parameter (among others), or vice versa? 
> 
> I'm not imagining a client doing anything programmatically useful with the distinction.
> 
> 
> 
> 
> Todd Lainhart
> Rational software
> IBM Corporation

---

From: Justin Richer <[email-masked]>
Date: Tue, 5 Feb 2013 14:49:13 -0500

You know, that works as well. From the client's perspective, the token 
isn't good anymore. The client shouldn't care if the token was good in 
the first place if it's revoking it.

  -- Justin

On 02/05/2013 02:41 PM, Torsten Lodderstedt wrote:
> Am 05.02.2013 um 17:46 schrieb Todd W Lainhart <[email-masked] 
> <mailto:[email-masked]>>:
>
>> > Could it do something with invalid_parameter that it couldn't do 
>> with invalid_token_parameter (among others), or vice versa?
>>
>> *
>> 550 King Street, Littleton, MA 01460-1250**
>> 1-978-899-4705
>> 2-276-4705 (T/L)
>> [email-masked] <mailto:[email-masked]>*
>>
>>
>>
>>
>>
>>
>> From: "Richer, Justin P." <[email-masked] <mailto:[email-masked]>>
>> To: George Fletcher <[email-masked] <mailto:[email-masked]>>,
>> Cc: OAuth WG <[email-masked] <mailto:[email-masked]>>
>> Sent by: [email-masked] <mailto:[email-masked]>
>> ------------------------------------------------------------------------
>>
>>
>>
>>
>> On Feb 4, 2013, at 3:57 PM, George Fletcher <[email-masked] 
>> <mailto:[email-masked]>>
>> wrote:
>>
>> >
>> >> On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>> >>
>> >>
>> "invalid_parameter" (as suggested by Peter and George). I don't see 
>> the need to register it (see 
>> >> something more like "invalid_token_parameter" would maybe make 
>> sense, since it's not just *any* parameter, it's the special "token" 
>> parameter that we're talking about, but it's distinct from the 
>> invalid_token response. The introspection endpoint uses the same 
>> pattern of a token= parameter, but since the whole point of the 
>> introspection endpoint is determining token validity it doesn't 
>> actually throw an error here.
>> >>
>> parameter is invalid. I don't think we should create a bunch of 
>> specific error values that are endpoint specific and could overlap 
>> which is where the whole error return value started.
>> >
>>
>> Hm, I see what you're saying, but the error response is already 
>> endpoint specific. Though there is value in not having conflicting 
>> and/or confusing responses from different endpoints that use the same 
>> error code for different things.
>>
>> What it really comes down to is: what can the client do with this 
>> error? Could it do something with invalid_parameter that it couldn't 
>> do with invalid_token_parameter (among others), or vice versa? As I'm 
>> writing this out, I'm not convinced that it could, really, so this 
>> may be a bike shedding argument.
>>
>> -- Justin
>>
>>
>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 5 Feb 2013 21:45:20 +0100

I know, that's why I asked. I think this is the simplest way to deal with this type of error. I therefore prefer it.

Am 05.02.2013 um 20:49 schrieb Justin Richer <[email-masked]>:

> You know, that works as well. From the client's perspective, the token isn't good anymore. The client shouldn't care if the token was good in the first place if it's revoking it.
> 
>  -- Justin
> 
>

---

From: George Fletcher <[email-masked]>
Date: Tue, 05 Feb 2013 16:35:09 -0500

I'm fine with this solution as well.  --George

On 2/5/13 3:45 PM, Torsten Lodderstedt wrote:
> I know, that's why I asked. I think this is the simplest way to deal 
> with this type of error. I therefore prefer it.
>
> Am 05.02.2013 um 20:49 schrieb Justin Richer <[email-masked] 
> <mailto:[email-masked]>>:
>
>> You know, that works as well. From the client's perspective, the 
>> token isn't good anymore. The client shouldn't care if the token was 
>> good in the first place if it's revoking it.
>>
>>  -- Justin
>>
>>
>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg10604.html) 
>>>> but would like to get your advice.
>>>> sense, since it's not just *any* parameter, it's the special 
>>>> "token" parameter that we're talking about, but it's distinct from 
>>>> the invalid_token response. The introspection endpoint uses the 
>>>> same pattern of a token= parameter, but since the whole point of 
>>>> the introspection endpoint is determining token validity it doesn't 
>>>> and/or confusing responses from different endpoints that use the 
>>>> same error code for different things.
>>>>
>>>> error? Could it do something with invalid_parameter that it 
>>>> couldn't do with invalid_token_parameter (among others), or vice 
>>>> versa? As I'm writing this out, I'm not convinced that it could, 
>>>> really, so this may be a bike shedding argument.
>>>>
>>>> -- Justin
>>>>
>>>>

---

From: Todd W Lainhart <[email-masked]>
Date: Tue, 5 Feb 2013 16:39:52 -0500

+1

Todd Lainhart
Rational software
IBM Corporation

From:   George Fletcher <[email-masked]>
To:     Torsten Lodderstedt <[email-masked]>, 
Cc:     "[email-masked]" <[email-masked]>, OAuth WG 
<[email-masked]>
Date:   02/05/2013 04:35 PM
Subject:        Re: [OAUTH-WG] draft-ietf-oauth-revocation
Sent by:        [email-masked]

On 2/5/13 3:45 PM, Torsten Lodderstedt wrote:
I know, that's why I asked. I think this is the simplest way to deal with 
this type of error. I therefore prefer it.

You know, that works as well. From the client's perspective, the token 
isn't good anymore. The client shouldn't care if the token was good in the 
first place if it's revoking it.

 -- Justin

On 02/05/2013 02:41 PM, Torsten Lodderstedt wrote:
Why not adopting Bill's suggestion and just return HTTP status code 200 
for (already) invalid tokens?

regards,
Torsten.

Todd Lainhart
Rational software
IBM Corporation

-- Justin