Eran, While the flows in the spec today may have unique sets of required parameters, other flows may exist with overlapping initial parameters (why? perhaps the flows have different rules that don't come into effect until later in the flow). Keeping the type parameter in there would help differentiate those. Yes, the new flows could include a type parameter while the originals did not, but then a token endpoint not prepared for the unexpected flow would mistake the new flow for the old one.
-- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Fri, Jun 11, 2010 at 2:25 PM, Eran Hammer-Lahav <e...@hueniverse.com>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
