I disagree. I don't think it's redundant, I think it's a clarifying piece of information that makes it completely unambiguous what the client is expecting to happen. On the server side, a single switch is a much simpler and less error-prone dispatch structure than a set of "if this-and-that parameter else if this-other parameter else if that-other-and-something-else parameter" statements. If one of our goals of OAuth2 is easing the implementation for developers, dropping the "type" field is a big lose.
Also, as has already been pointed out, if a new flow comes in that wants to use existing parameters in a different way, then it won't fit into this framework or an extension. Decreasing ambiguity for a small price (a few extra required characters for the auth flow) is a good thing. Incidentally, I agree that the refresh flow should fit in with all of the other flows, but with "type=refresh". Maybe "type" is the wrong word for this parameter? Because I was envisioning the rescope and revoke operations to be similar to the refresh operation. Using HTTP DELETE is a bad idea since it would require each token to have a URL associated with it, and you can no longer manipulate the OAuth API with just query parameters. A "type=revoke" call with the refresh token as authentication and the token-to-be-revoked as parameter makes a whole lot more sense to me. It keeps these three operations parallel to the other authorization flows -- part of the whole "how to get a token" side of OAuth. -- Justin On Fri, 2010-06-11 at 17:25 -0400, Eran Hammer-Lahav wrote: > It doesn’t really. It is completely clear what kind of authorization > grant the client is providing simply by looking at the parameter. It > might make the code a few lines longer (a few if-else instead of a > switch-case) but because these are all post parameters, you access > them the same way (i.e. this is not a case where header information is > moved to post body, etc.). > > As for the rescope and revoke operations, we still need to figure out > how to accomplish that. For example, revoking can be done using an > HTTP DELETE operation which is more consistent with HTTP, and > rescoping (which is still tricky because scope can only be decreased) > is more a function of a refresh operation (asking for a new access > token using a refresh token and simply providing a new, lesser scope). > > EHL > > > On 6/11/10 2:05 PM, "Justin Richer" <[email protected]> wrote: > > I agree with Marius: I think we should keep the explicit flow > name in > there (in the 'type' parameter or equivalent), as it (among > other > things) opens the possibility for the rescope and revoke > operations. It > makes it very clear how both client and server expect things > to behave. > > -- Justin > > On Fri, 2010-06-11 at 16:47 -0400, Marius Scurtescu wrote: > > On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav > <[email protected]> wrote: > > > Draft -07 represents a major rearrangement of the > document. I still have a lot of work to do but wanted to share > my progress and get some general feedback. The draft includes > a few normative language changes but the main focus is on the > document structure and how the architecture is explained. > > > > > > Changes include: > > > > > > o Removed device profile. > > > o Added verification code support to user-agent flow. > > > o Removed multiple formats support, leaving JSON as the > only format. > > > o Changed assertion "assertion_format" parameter to > "assertion_type". > > > o Removed "type" parameter from token endpoint. > > > > It would be really useful if each request had a unique type, > now we > > are back to guessing what is requested, like in WRAP. > > > > One small error that I noticed: section "5.1.4. Refresh > Token" is not > > listing client_id and client_secret as optional parameters. > > > > In general I found previous versions much easier to read and > > understand, but maybe I just need more time... > > > > > > Marius > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
