The exact same argument can be made that the hybrid flow meets all the use cases of the web-server flow... which means we can keep the current single flow specification as is... :-)
What am I missing? (I'm asking). EHL > -----Original Message----- > From: Brian Eaton [mailto:bea...@google.com] > Sent: Tuesday, January 11, 2011 11:54 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Proposal to drop/relocate > response_type=code_and_token > > On Mon, Jan 10, 2011 at 3:42 PM, Eran Hammer-Lahav > <e...@hueniverse.com> wrote: > > These are two very different client profiles. In one, the client is > > completely > authenticated, residing solely in the user-agent. The other is a mix > authenticated and unauthenticated, where parts of the client can keep a > secrets but others can't. > > > > Being able to keep a secret is the primary differentiator when picking which > profile to use. I agree that the hybrid one is an optimization of the web- > server profile (removing the need to wait for the server to send a token back > to the user-agent after exchanging the code). But that only means the > code_and_token really belongs with the web-server profile than with the > user-agent. > > The two paragraphs above didn't make sense to me. > > Once you have the hybrid flow, it meets all of the use cases that the user- > agent flow was trying to solve. The hybrid flow is more powerful, and has > the same or better security characteristics. So the sensible thing to do is > replace the user-agent flow, 100%, with the hybrid flow. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
