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

[Dick Hardt <[e-mail]>]

Given how simple the JSON response object would be, I don't think it would be much harder to write a parser than  application/x-www-form-urlencoded.

If the embedded software is going to call Facebook's Open Graph API or many other modern API's, it will need a JSON parser anyway.

-- Dick

On 2010-04-21, at 11:36 AM, Gaurav Rastogi wrote:

> +1 on not requiring JSON exclusively. There are enough number of small embedded software stack where JSON is not an option. 
> 
> On Apr 20, 2010, at 12:45 PM, David Recordon wrote:
> 
>> Having written an implementation last night against the web server
>> flow, I'm worried about adding JSON as a requirement for the response.
>> While it might be easier for environments with JSON libraries, it's
>> drastically more complex for environments (like embedded hardware)
>> which doesn't support JSON. And writing basic form encoded parsing
>> code really isn't that hard – especially if I can do it!
>> 
>> 
>> 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
>>> 
>>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth