> -----Original Message----- > From: Marius Scurtescu [mailto:[email protected]] > Sent: Wednesday, April 21, 2010 3:05 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] feedback on 4/17 draft > > On Wed, Apr 21, 2010 at 2:34 PM, Eran Hammer-Lahav > <[email protected]> wrote: > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] On > >> Behalf Of Marius Scurtescu > >> Sent: Monday, April 19, 2010 8:04 PM > > > >> 3.5.3.1 > >> > >> "an HTTP GET request to the authorization endpoint", should probably > >> read: "an HTTP POST request to the token endpoint" (POST and token > >> endpoint). > > > > The token endpoint only returns tokens. The authorization endpoint > returns codes... This is half of the authorization step. > > I see how you made the distinction. > > I was assuming that the authorization endpoint will be hit only with browsers > and the token endpoint only with direct calls from the client. This allows a > clean separation of characteristics for the two endpoints and this is the > reason with did not combine them. Following this logic, it is better for the > above to use POST and the token endpoint.
I agree. I need to take a look at POST vs GET throughout the whole spec. It's a bit broken right now. > >> 5.2.2 > >> > >> If the entity body includes other parameters, is it worth requiring > >> that oauth_token be the first one? > > > > Why not last? > > If was just following the same convention as in OAuth 1.0, see RFC 5849, > section 3.5.2. I did get a kick from you referencing RFC 5849. It took me a second... :-) Which BTW says: The entity-body MAY include other request-specific parameters, in which case, the protocol parameters SHOULD be appended following the request-specific parameters, properly separated by an "&" character (ASCII code 38). As in... last. EHL _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
