I would argue that if a new flow doesn't fit into the existing framework, it should define a new endpoint. For example, the device flow doesn't fit with the 2 endpoints model since the first call is really an half-authorization with a custom URI returned. The second flow uses a verification code.
The problem with the type parameter is that is break the clean abstraction because it allows turning the endpoint into anything really. I rather make it less appealing. Note that the new model unifies the refresh token flow with other types of authorization grants. I think that shows how well this abstraction works. A type parameter is nothing but a duplication of the information sent. EHL From: Andrew Arnott [mailto:andrewarn...@gmail.com] Sent: Sunday, June 13, 2010 9:58 AM To: Eran Hammer-Lahav Cc: Justin Richer; Marius Scurtescu; OAuth WG Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) 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<mailto: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<http://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<http://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<http://OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
