Why client developers? How does it make their life easier? An approach I'm more comfortable with is to redefine 'type' as the type of authorization grant provided: refresh_token, user_basic, verification_code, assertion. And if we use the name 'type', I would change the 'type' parameter on the end-user authorization endpoint to something else such as the proposed 'response_type'. Otherwise change it to 'grant_type' or something like that.
EHL > -----Original Message----- > From: Chuck Mortimore [mailto:cmortim...@salesforce.com] > Sent: Monday, June 14, 2010 7:54 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: RE: [OAUTH-WG] Draft -07 (major rewrite) > > +1 for the type parameter. > > Our internal server and client developers would both prefer it. > > -cmort > ________________________________________ > From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of > Justin Richer [jric...@mitre.org] > Sent: Monday, June 14, 2010 7:20 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) > > 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" <jric...@mitre.org> 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 > > <e...@hueniverse.com> 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 > > > 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
