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
