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

> 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)
lainhart@us.ibm.com

From:   "Richer, Justin P." <jricher@mitre.org>
To:     Torsten Lodderstedt <torsten@lodderstedt.net>, 
Cc:     OAuth WG <oauth@ietf.org>
Date:   02/04/2013 03:42 PM
Subject:        Re: [OAUTH-WG] draft-ietf-oauth-revocation
Sent by:        oauth-bounces@ietf.org

On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt <torsten@lodderstedt.net> 
wrote:

> 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".

+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/oauth/current/msg10604.html) but 
would like to get your advice.

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

> best regards,
> Torsten.
> _______________________________________________
> 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