I find the combination of the web server and user agent flows for end user authorization unnatural -- particularly poignant in the success response, which has 4 parameters -- but one flow MUST have no more than 2, and the other must have 3. And apparently now the user-agent flow can receive a verification code as well as an access token? It's unclear what that's for or how that's used.
I suggest the spec break the two flows back up to make it easier to parse what message shapes exist. -- 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 1:11 PM, Eran Hammer-Lahav <[email protected]>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. > > The spec is now 36 pages, 19 pages shorter than -05. > > EHL > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
