> 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) lainh...@us.ibm.com From: "Richer, Justin P." <jric...@mitre.org> To: Torsten Lodderstedt <tors...@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-boun...@ietf.org On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt <tors...@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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
