Re: [OAUTH-WG] temperature check: json input to token endpoint

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