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
