Adding a verification code to the user-agent flow was suggested on this list and received nothing but support. It was suggested as a solution to a Twitter use case. Once that is added in, the two flows only differ in how the response is delivered and the presence of an access token in the response (which currently is a MUST NOT for web-server but I don't know if this restriction is need).
If we break them up, it is for editorial reasons only, which also means, every change needs to be made twice, as well as every extension needs to spell out which flavor it is for. EHL From: Andrew Arnott [mailto:andrewarn...@gmail.com] Sent: Monday, June 14, 2010 8:24 AM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) 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 <e...@hueniverse.com<mailto: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. The spec is now 36 pages, 19 pages shorter than -05. EHL _______________________________________________ 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