Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON

[Marius Scurtescu <[e-mail]>]

How about encoding requests as well. The request json blob could be
then URL encoded and added to the endpoint/callback URL with a
parameter like "oauth_json_request". This would solve the
prefix/collision problem.

Marius



On Tue, Apr 20, 2010 at 9:27 AM, Joseph Smarr <[e-mail]> wrote:
> ...and of course by "request format", I mean "response format". :)
> BTW, note that the "trailing newline problem" with url-encoding is
> particularly pernicious because a) it messes up the signature, and b) you
> often can't see it when you print out your variables, so everything looks ok
> and yet the signature is garbled. I've seen this multiple times, and IMO
> that alone is reason enough to get rid of this serialization format in favor
> of something more robust and widely implemented like JSON.
>
> On Tue, Apr 20, 2010 at 9:24 AM, Joseph Smarr <[e-mail]> wrote:
>>
>> +1 to including JSON format, and perhaps making it the required format. In
>> my experience helping numerous developers debug their OAuth implementations,
>> url-encoding/decoding was often a source of bugs, since a) the libraries are
>> usually hand-built, b) url-encoding is known to be funky/inconsistent wrt +
>> vs. %20 and other such things, and c) it's very sensitive to things like a
>> trailing newline at the end of the response, which can easily be tokenized
>> as part of the the last value (since the normal implementations just split
>> on & and =). In contrast, I've never heard of any problems parsing JSON, nor
>> any encoding/decoding bugs related to working with JSON in other APIs
>> (something I *cannot* say about XML, which is way more finicky about
>> requiring its values to be properly encoded or escaped in CDATA etc.; I've
>> also seen way more inconsistency in support of XML parsers and their output
>> formats, whereas JSON always works exactly the same way and always "just
>> works").
>> So in conclusion, url-encoding has caused a lot of pain in OAuth 1.0, and
>> JSON is already widely supported (presumably including by most APIs that
>> you're building OAuth support to be able to access!), so I think it would
>> simplify the spec and increase ease/success of development to use JSON as a
>> request format. In fact, I think I'd like to push for it to be the
>> default/required format, given the positive attributes above. Does anyone
>> object, and if so, why?
>> Thanks, js
>>
>> On Tue, Apr 20, 2010 at 8:10 AM, Eran Hammer-Lahav <[e-mail]>
>> wrote:
>>>
>>> There seems to be support for this idea with some concerns about
>>> complexity. Someone needs to propose text for this including defining the
>>> request parameter and schema of the various reply formats.
>>>
>>> EHL
>>>
>>> > -----Original Message-----
>>> > From: Torsten Lodderstedt [mailto:[e-mail]]
>>> > Sent: Monday, April 19, 2010 4:48 AM
>>> > To: Eran Hammer-Lahav
>>> > Cc: Dick Hardt; OAuth WG
>>> > Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
>>> >
>>> >
>>> > > We can also offer both and define a client request parameter (as long
>>> > > as the server is required to make at least one format available).
>>> >
>>> > +1 on this
>>> >
>>> > regards,
>>> > Torsten.
>>> >
>>> > >
>>> > > EHL
>>> > >
>>> > >> -----Original Message-----
>>> > >> From: [e-mail] [mailto:[e-mail]] On
>>> > >> Behalf Of Dick Hardt
>>> > >> Sent: Sunday, April 18, 2010 9:30 PM
>>> > >> To: OAuth WG
>>> > >> Subject: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
>>> > >>
>>> > >> The AS token endpoint response is encoded as application/x-www-form-
>>> > >> urlencoded
>>> > >>
>>> > >> While this reuses a well known and understood encoding standard, it
>>> > >> is uncommon for a client to receive a message encoded like this.
>>> > >> Most
>>> > >> server responses are encoded as XML or JSON. Libraries are NOT
>>> > >> reedily available to parse application/x-www-form-urlencoded results
>>> > >> as this is something that is typically done in the web servers
>>> > >> framework. While parsing the name value pairs and URL un-encoding
>>> > >> them is not hard, many developers have been caught just splitting
>>> > >> the
>>> > parameters and forgetting to URL decode the token.
>>> > >> Since the token is opaque and may contain characters that are
>>> > >> escaped, it is a difficult bug to detect.
>>> > >>
>>> > >> Potential options:
>>> > >>
>>> > >> 1) Do nothing, developers should read the specs and do the right
>>> > >> thing.
>>> > >>
>>> > >> 2) Require that all parameters are URL safe so that there is no
>>> > >> encoding issue.
>>> > >>
>>> > >> 3) Return results as JSON, and recommend that parameters be URL
>>> > >> safe.
>>> > >>
>>> > >> -- Dick
>>> > >> _______________________________________________
>>> > >> OAuth mailing list
>>> > >> [e-mail]
>>> > >> https://www.ietf.org/mailman/listinfo/oauth
>>> > > _______________________________________________
>>> > > OAuth mailing list
>>> > > [e-mail]
>>> > > https://www.ietf.org/mailman/listinfo/oauth
>>> > >
>>> >
>>> >
>>> >
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>