One of the modifications I concluded to do to WRAP was to add in the type parameter. I was happy to see if in David's draft.
Even though redundant in some ways, it make it very clear to both the client and server what is intended. +1 for putting it back in. On Mon, Jun 14, 2010 at 11:23 AM, Brian Eaton <bea...@google.com> wrote: > 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
