On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > 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).
Yeah, this matters. If you return an access token on the web-server flow, several things break: - you can no longer rely on the client secret to authenticate the callback URL. - you lose all hope of getting to LOA 2 with this protocol, because the access token is visible to the client. - you lose the clarity of how the web server flow is supposed to work. Bike-shed painting: The use-cases for web server and user-agent flow are also different. I'd prefer to have the spec call out different profiles for different use-cases, because it makes it much easier to figure out what a given application should be doing. During the WRAP work I argued that we didn't need a type parameter, and after looking at WRAP implementations I've changed my mind. Please leave it in. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
