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 <[email protected]> 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 <[email protected]> >>> 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:[email protected]] >>>>> 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: [email protected] [mailto:[email protected]] 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 >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
