Didn't see consensus on making any of these changes. Dropping from my queue.
EHL -----Original Message----- From: Justin Richer [mailto:jric...@mitre.org] Sent: Wednesday, July 14, 2010 8:38 AM To: Eran Hammer-Lahav Cc: Brian Eaton; oauth@ietf.org Subject: Re: [OAUTH-WG] POST-only on token endpoint? [was: temperature check: json input to token endpoint] Again, it's a good security optimization, and it makes sense for large internet providers. But I don't think this argument holds for small intranet providers, where there won't be proxies in the middle and many of the clients will largely be non-browser-based and cacheless anyway. At least, that's how it will be in most of my deployments. I think it would be better to call out the cache/proxy/leakage issues directly, recommend POST for most instances to address these concerns, but say that a server MAY accept GET requests with query parameters on the token endpoint. -- Justin On Mon, 2010-07-12 at 09:56 -0400, Eran Hammer-Lahav wrote: > Proxies and caches. > > EHL > > > > On Jul 12, 2010, at 8:48, "Justin Richer" <jric...@mitre.org> wrote: > > > I'd like to keep form-encoded inputs. I think it makes sense to use > > a well-established key-value mechanism, and the asymmetry at play > > here is what the web is made of (post a form, get HTML/XML/JSON/whatever). > > > > Along those lines, I'd actually like to relax the restriction of > > using "POST" and allow for query arguments on the token endpoint as > > well. Long ago it was argued that the POST requirement was to keep > > query parameters from leaking into server logs. That's a fine > > implementation-specific security optimization, but I don't think it > > belongs mandated in the spec. As a practical matter, I know that for > > most of my implementations (on small single servers), anyone who's > > got access to the web server logs have access to the tokens in the database. > > > > Were there other reasons for mandating POST here that I'm forgetting? > > > > -- Justin > > > > On Sun, 2010-07-11 at 00:31 -0400, Brian Eaton wrote: > >> Hey folks - > >> > >> Today, the token endpoint takes form-encoded inputs, and sends JSON > >> outputs. This requires developers to use both form encoding and a > >> json parser. > >> > >> Many services expose symmetric APIs for non-browser endpoints. For > >> example, an API call normally takes JSON input and returns JSON > >> output. > >> > >> What do people think about having the token endpoint accept and return > >> JSON? > >> > >> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
