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

From: Robert Sayre <[email-masked]>
Date: Sat, 1 May 2010 18:24:15 -0400

On Fri, Apr 30, 2010 at 10:33 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> If we end up with JSON as the only *core* format, we can still extend the
> protocol in another spec to add a format request parameter with other
> serializations.

I think that's the right way to look at it.

The fact that JSON is always Unicode and the character encoding is
easily determined by examining the first few bytes should be enough to
make the group jump for it.[1] You can skip all the inaccurate
metadata in the HTTP headers for both requests and responses. And even
kind of hobbled embedded implementations can do ASCII only and we'll
pretend it's UTF-8. :)

But maybe none of this is a problem for existing implementations? The
spec seems strangely silent on internationalization.

- Rob

[1] noooooo: http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#url-encoded-form-data

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 5 May 2010 08:28:05 -0700

I'll add something to the draft and we'll discuss it. There is enough consensus on a single JSON response format.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Torsten Lodderstedt
> Sent: Friday, April 30, 2010 2:00 AM
> To: Brian Eaton
> Cc: [email-masked]
> Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
> (Proposal)
> 
> 
> Zitat von Brian Eaton <[email-masked]>:
> 
> > On Thu, Apr 29, 2010 at 2:40 PM, Mike Moore <[email-masked]>
> wrote:
> >> On Thu, Apr 29, 2010 at 2:49 PM, Yaron Goland <[email-masked]>
> wrote:
> >>>
> >>> Can we please just have one format, not 3? The more choices we give
> >>> the more interoperability suffers.
> >
> > Yes.  The number of parsers needed to make a working system is
> > important.  The spec has too many already.
> >
> > I'd like to see authorization servers returning JSON or XML, since
> > that's what the resource servers are doing.
> >
> > ...and given a choice between JSON and XML, I'd pick JSON.
> >
> 
> I agree. At Deutsche Telekom, we try to align our authorization APIs with the
> APIs provided by the resource servers. Authorization is "just" a small, but
> important, portion of the overall process and aligning it with the rest
> increases acceptance and decreases error rate.
> 
> None of the APIs we provide uses form encoding, most of them use JSON,
> some XML.
> Based on that observation I would like to see at least JSON support in OAuth.
> So JSON as the only would be fine with me.
> 
> My proposal is based on the observation that the WG did not come to a
> consensus about the one and only format.
> 
> I have collected the following opinions from the thread:
> 
> pro additional support for JSON and XML - Marius Scurtescu, John Jawed,
> Richard Barnes, Brian Eaton, Torsten Lodderstedt pro additional support for
> JSON - Dick Hardt (initiated the thread), Joseph Smarr still support
> application/x-www-form-urlencoded (unclear whether
> exclusively) - David Recordon, Gaurav Rastogi one format only (preference
> unclear) - Yaron Goland JSON as the only format (if forced to decide for a
> single format) - Brian Eaton, Torsten Lodderstedt JSON as the only format -
> James Manger, Robert Sayre application/x-www-form-urlencoded as the
> only format - Mike Moore JSON for responses as well - Marius Scurtescu
> 
> Here are some representative comments from the thread:
> 
> Joseph Smarr - "JSON is already widely supported (presumably including by
> most APIs that you're building OAuth support to be able to access!"
> 
> David Recordon - "it's drastically more complex for environments (like
> embedded hardware) which doesn't support JSON."
> 
> Paul C. Bryan - "I'm struggling to imagine hardware that on the one hand
> would support OAuth, but on the other would be incapable of supporting
> JSON..."
> 
> Gaurav Rastogi - "There are enough number of small embedded software
> stack where JSON is not an option."
> 
> So we have at least 9 votes pro JSON, but also 1 vote for application/x-www-
> form-urlencoded only.
> 
> How shall we proceed? Can we come to a consensus?
> 
> regards,
> Torsten.
> 
> > Cheers,
> > Brian
> > _______________________________________________
> > OAuth mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> 
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 5 May 2010 08:42:31 -0700

> I'll add something to the draft and we'll discuss it. There is enough consensus on a single JSON response format.

Yesterday I got the following feedback:

On Tue, May 4, 2010 at 5:43 PM, Greg Robbins <[email-masked]> wrote:
> Using JSON on the iPhone requires developers to drag in source code for a
> third-party library.
>
> If their app isn't already relying on JSON for some other purpose, then
> adding a third-party library is a somewhat substantial annoyance,
> particularly for a mobile app where code size is important.
>
> If OAuth 2 is only intended for use with JSON APIs, then returning all
> responses as JSON is reasonable. Otherwise, it's not so reasonable. A full
> JSON parser is non-trivial, and seems like overkill for simple responses.
>
> The iPhone OS does have libxml2 and an event-style XML parser, but no really
> easy way to extract data from XML, either.
>
> Form-style responses are much more straightforward to worth with given
> simple string-manipulation utilities.

If the above is true, then I am not so sure about JSON anymore. Lots
of phones and devices will have problems with it.

Marius

---

From: David Recordon <[email-masked]>
Date: Wed, 5 May 2010 09:16:51 -0700

As long as we spec that the response can only contain one parameter (either
"error" or "access_token") then the code to parse it in PHP is as follows:

list($param, $value) = explode('=', $response, 2);
if ($param == 'access_token') {
} elseif ($param == 'error') {
}

If it can contain more than one value, then parsing becomes more difficult
and JSON starts to make sense.

--David

On Wed, May 5, 2010 at 8:42 AM, Marius Scurtescu <[email-masked]>wrote:

> > I'll add something to the draft and we'll discuss it. There is enough
> consensus on a single JSON response format.
>

---

From: Robert Sayre <[email-masked]>
Date: Wed, 5 May 2010 12:43:03 -0400

On Wed, May 5, 2010 at 11:42 AM, Marius Scurtescu <[email-masked]> wrote:
>> third-party library
...
> of phones and devices will have problems with it.

It is true that some devices do not ship with JSON libraries, but I
think the concern is overblown. A JSON library is going to be
something like 1000 lines of code, and orders of magnitude faster and
smaller than an XML parser. For instance, a Blackberry developer would
need to include the org.json packages that come bundled with Android,
but they are tiny: http://www.json.org/java/index.html

Besides that, the group should skate to where the puck will be, as it
were. Every platform that can handle Unicode can and will have a JSON
library in short order. I once saw a WG waste tons of time debating
the capabilities of J2ME handsets that are now basically irrelevant in
terms of Internet traffic share.

-- 

Robert Sayre

---

From: Evan Gilbert <[email-masked]>
Date: Wed, 5 May 2010 10:06:33 -0700

> consensus on a single JSON response format.

Responses that are returned via a browser URL should
be application/x-www-form-urlencoded. These parameters are standard to parse
in any HTTP handling library and JSON only adds complexity and external
library requirements.

I'm not positive we need to support JSON at all.

 But if we support both JSON and application/x-www-form-urlencoded, I think
the pattern should be:
- application/x-www-form-urlencoded for requests/responses in a browser
- JSON otherwise (including requests)

---

From: Robert Sayre <[email-masked]>
Date: Wed, 5 May 2010 13:24:59 -0400

On Wed, May 5, 2010 at 1:06 PM, Evan Gilbert <[email-masked]> wrote:
> be application/x-www-form-urlencoded.

I'm not sure I understand here, could you explain in more detail?

> These parameters are standard to parse
> in any HTTP handling library

Any HTTP handling library will claim to support it, but I doubt very
many non-browser libraries match the HTML5 spec. Don't you find the
requirements there to be complex relative to JSON?

> and JSON only adds complexity and external
> library requirements.

Anything in a browser won't care either way. And won't other HTTP
clients likely end up talking to a JSON API anyway?

>
>  But if we support both JSON and application/x-www-form-urlencoded

That is design-by-committee. Let's not do that.

-- 

Robert Sayre

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 05 May 2010 19:47:17 +0200

Even if not supported directly by the platform there are many JSON 
libraries available these days.

http://www.json.org/ lists 3 libraries for Objective-C alone.

Moreover, the JSON documents we are discussing now are simple, something 
like

{ "access_token": "SlAV32hkKG", "expires_in": "3600", "refresh_token": 
"8xLOxBtZp8" }

Parsing such a document is not a challenge even without library support.

Regarding code size: What really matters on mobile devices from my point 
of view is the size of data to be transmitted. Here, JSON is much more 
compact than XML.

regards,
Torsten.

Am 05.05.2010 17:42, schrieb Marius Scurtescu:
> On Wed, May 5, 2010 at 8:28 AM, Eran Hammer-Lahav<[email-masked]>  wrote:
>    
> On Tue, May 4, 2010 at 5:43 PM, Greg Robbins<[email-masked]>  wrote:
>

---

From: Evan Gilbert <[email-masked]>
Date: Wed, 5 May 2010 10:57:20 -0700

> I'm not sure I understand here, could you explain in more detail?

Sorry, should have been clearer here. Think that any response sent to a
redirect_uri should be form encoded.

The "via a browser" comment was to clarify the goal - it's because this is
sent via HTTP GET to a web server (or other client - JS, installed app -
reading the browser path).

JSON only adds complexity for these cases - the client needs to understand
how to parse URL parameters anyway to get the JSON content, so you're adding
a separate encoding layer.

Non-redirect responses and HTTP POST requests are more interesting.

> requirements there to be complex relative to JSON?

See notes above - all clients need to know how to parse URL parameters
anyway. So we just have to decide on whether we want an additional JSON
requirement.

> That is design-by-committee. Let's not do that.

All requests and HTTP redirect responses probably need to be HTTP GET
(unless we change the spec significantly) - think this means that we are
supporting form encoding.

For responses, think that sending JSON would be OK. Web serving is often
asymmetrical this way (url params in, HTML out)

---

From: Evan Gilbert <[email-masked]>
Date: Wed, 5 May 2010 10:59:26 -0700

> libraries available these days.

It's not hard to add JSON support, but it's a factor in the choice.

> Parsing such a document is not a challenge even without library support.

Per notes above - the client needs to do understand form encoding anyway.
The client needs to parse the redirect_uri and also needs to generate form
encoded requests.

>
> Regarding code size: What really matters on mobile devices from my point of
> view is the size of data to be transmitted. Here, JSON is much more compact
> than XML.
>
> regards,
> Torsten.
>

---

From: Evan Gilbert <[email-masked]>
Date: Wed, 5 May 2010 11:01:23 -0700

> The client needs to parse the redirect_uri and also needs to generate form

Also, for the User-Agent flow, parsing potentially untrusted JSON in
JavaScript is difficult. The normal path of using eval() is unsafe and leads
to XSS holes - you need to run regex matcher to verify that the JSON content
has no executable code.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 5 May 2010 11:09:11 -0700

Consensus is that JSON is the right format for token responses in the message body. As for the User Agent flow, that should remain form-encoded in the fragment (I think).

EHL

From: Evan Gilbert [mailto:[email-masked]]
Sent: Wednesday, May 05, 2010 10:07 AM
To: Eran Hammer-Lahav
Cc: Torsten Lodderstedt; [email-masked]
Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal)

On Wed, May 5, 2010 at 8:28 AM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
I'll add something to the draft and we'll discuss it. There is enough consensus on a single JSON response format.

Responses that are returned via a browser URL should be application/x-www-form-urlencoded. These parameters are standard to parse in any HTTP handling library and JSON only adds complexity and external library requirements.

 But if we support both JSON and application/x-www-form-urlencoded, I think the pattern should be:
- application/x-www-form-urlencoded for requests/responses in a browser
- JSON otherwise (including requests)

EHL

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> Of Torsten Lodderstedt
> Cc: [email-masked]<mailto:[email-masked]>
> Zitat von Brian Eaton <[email-masked]<mailto:[email-masked]>>:
>
> > On Thu, Apr 29, 2010 at 2:40 PM, Mike Moore <[email-masked]<mailto:[email-masked]>>
> wrote:
> >> On Thu, Apr 29, 2010 at 2:49 PM, Yaron Goland <[email-masked]<mailto:[email-masked]>>
> wrote:
> >>>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 5 May 2010 11:10:03 -0700

> and JSON starts to make sense.

I's not that hard to convert the whole name/value pairs string to a hash.

Parsing JSON by hand is much harder.

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 5 May 2010 11:14:02 -0700

On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> Even if not supported directly by the platform there are many JSON libraries
> available these days.
>

I never written such code, but I imagine it would be quite complicated
and error prone. You have to deal with escaping, white spaces and
nested data structures.

Marius

---

From: Evan Gilbert <[email-masked]>
Date: Wed, 5 May 2010 11:14:52 -0700

On Wed, May 5, 2010 at 11:09 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> Consensus is that JSON is the right format for token responses in the
> message body. As for the User Agent flow, that should remain form-encoded in
> the fragment (I think).
>

I'm fine with JSON in the message body.

I assume we would also use URL parameters for the Web App flow when
redirecting with the verification code.

>
>
> EHL
>
>
>
> *From:* Evan Gilbert [mailto:[email-masked]]
> *Sent:* Wednesday, May 05, 2010 10:07 AM
> *To:* Eran Hammer-Lahav
> *Cc:* Torsten Lodderstedt; [email-masked]
>
> *Subject:* Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
> (Proposal)
>
>
>
>
>

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 5 May 2010 11:17:40 -0700

On Wed, May 5, 2010 at 10:06 AM, Evan Gilbert <[email-masked]> wrote:
>
> ... and JSON only adds complexity and external
> library requirements.
>

Tend to agree.

Other than being nice, what other advantages does JSON provide?

Keep in mind that most people voted for one format only, and that is
clearly not possible, at a minimum we have to support both
application/x-www-form-urlencoded and JSON.

Marius

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 05 May 2010 20:19:20 +0200

> and error prone. You have to deal with escaping, white spaces and

we don't need nested data structure (at least currently). Where do you 
see a need for escaping?

regards,
Torsten.

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 5 May 2010 11:25:29 -0700

On Wed, May 5, 2010 at 11:19 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> we don't need nested data structure (at least currently). Where do you see a
> need for escaping?

How do you represent " { } , and : inside names and values? You
probably need full blown lexer and parser for JSON.

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 5 May 2010 11:35:52 -0700

On Wed, May 5, 2010 at 11:29 AM, John Jawed <[email-masked]> wrote:
> JSON markup is lighter than XML markup.

Yes, but I don't think XML was an option anymore.

The question is between:
1. application/x-www-form-urlencoded
2. application/x-www-form-urlencoded and JSON

Marius

>
> On Wed, May 5, 2010 at 11:17 AM, Marius Scurtescu <[email-masked]> wrote:

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 05 May 2010 20:38:08 +0200

Am 05.05.2010 20:01, schrieb Evan Gilbert:
>
>
> On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Even if not supported directly by the platform there are many
>         JSON libraries available these days.
>
>
>         Moreover, the JSON documents we are discussing now are simple,
>         something like
>
>
>         { "access_token": "SlAV32hkKG", "expires_in": "3600",
>         "refresh_token": "8xLOxBtZp8" }
>
>     Per notes above - the client needs to do understand form encoding
>     anyway. The client needs to parse the redirect_uri and also needs
>     to generate form encoded requests.
>
>
> JavaScript is difficult. The normal path of using eval() is unsafe and 
> leads to XSS holes - you need to run regex matcher to verify that the 
> JSON content has no executable code.

You are right, using eval to parse JSON is dangerous and thus as far as 
I understand, the recommended way is to use a JSON parser (aka native 
JSON support)?

regards,
Torsten.

---

From: DeWitt Clinton <[email-masked]>
Date: Wed, 5 May 2010 11:49:58 -0700

Having written more than one compliant JSON parser myself, it is most
certainly not "trivial", and not something that can be safely done with a
regular expression or other hacks.

That said, it's not *hard*, and that alone is no reason not to mandate JSON,
but I do want people to be clear about what mandating JSON means.  Clients
will need a fully compliant parser.  Period.  If the OAuth spec requires
JSON, then it should require it by reference to RFC 4627, not just by giving
some examples that demonstrate the curly braces.

-DeWitt

On Wed, May 5, 2010 at 11:38 AM, Torsten Lodderstedt <
[email-masked]> wrote:

> You are right, using eval to parse JSON is dangerous and thus as far as I
> understand, the recommended way is to use a JSON parser (aka native JSON
> support)?
>
> regards,
> Torsten.
>

---

From: Pid <[email-masked]>
Date: Wed, 05 May 2010 23:35:13 +0100

On 05/05/2010 19:49, DeWitt Clinton wrote:
> certainly not "trivial", and not something that can be safely done with
> a regular expression or other hacks.
> 
> That said, it's not /hard/, and that alone is no reason not to mandate
> JSON, but I do want people to be clear about what mandating JSON means.
>  Clients will need a fully compliant parser.  Period.  If the OAuth spec
> requires JSON, then it should require it by reference to RFC 4627, not
> just by giving some examples that demonstrate the curly braces.
> 
> -DeWitt

I know it's late, but can I add my 2 cents - as a developer who'll be
implementing this?

In the original post, Dick suggested that developers were having trouble
with the URL encoding format - but I respectfully suggest that JSON is
going to be more problematic.

There's no guarantee that an external JSON parser will be available for
a given platform/language/business, (perhaps because of licensing, if
not other more technical reasons).  So that means writing one.

Writing a JSON parser just to cover the simple usage proposed won't be
too tricky, but if the JSON response is so simple why bother adding this
dependency at all?  I'm slightly baffled...

URL encoding is required for at least one flow, so IMHO it might as well
stay for the rest.  Simplicity is important.

Can someone from the pro-JSON side offer a clearer explanation as to the
benefits, so I can stop scratching my head about it all, please?

Respectfully,

Pid

> On Wed, May 5, 2010 at 11:38 AM, Torsten Lodderstedt
>>             Even if not supported directly by the platform there are
>>             many JSON libraries available these days.
>>
>>
>>             Moreover, the JSON documents we are discussing now are
>>             simple, something like
>>
>>
>>         Per notes above - the client needs to do understand form
>>         encoding anyway. The client needs to parse the redirect_uri
>>         and also needs to generate form encoded requests.
>>
>>
>>     Also, for the User-Agent flow, parsing potentially untrusted JSON
>>     in JavaScript is difficult. The normal path of using eval() is
>>     unsafe and leads to XSS holes - you need to run regex matcher to
>>     verify that the JSON content has no executable code.
> 
>     You are right, using eval to parse JSON is dangerous and thus as far
>     as I understand, the recommended way is to use a JSON parser (aka
>     native JSON support)?
> 
>     regards,
>     Torsten.
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Joseph Smarr <[email-masked]>
Date: Thu, 6 May 2010 08:46:50 -0700

I'm hearing a lot of confusion on this thread.

Evan-of course when attributes are sent *on-the-url* then they get parsed
automatically by the HTTP stack, but we're talking about the response body,
which every OAuth 1.0 library I've seen writes their own (usually buggy)
parser for, and that's where we're proposing to use JSON.

I've seen good JSON library support on every platform I've needed to work
for, and it's becoming more and more common (look at Facebook's new Graph
API, for instance), so I doubt many platforms will be without JSON parsers
for much longer. That being said, it's prudent to look at the
state-of-the-art and verify that requiring JSON is not a practical hindrance
for iPhone developers, etc., but I still think it's "betting on the right
horse" and it's going to be a lot simpler and less error-prone than either
url-encoded values or XML.

Eran-thanks for agreeing to write something up, and I agree we've got strong
support for JSON being the primary/only format for the response body. I look
forward to the proposed text and will happily review it.

Thanks, js

---

From: Greg Brail <[email-masked]>
Date: Thu, 6 May 2010 12:13:17 -0400

I agree that JSON is the long-term winner. However, at least for Java and
Python I know that JSON parsers are not part of the standard library,
whereas everything needed to decode a url-formencoded library is in the
standard libraries and has been there for a long, long time. Keep in mind
that the overhead of using third-party code is not just in finding and using
the right library, but getting legal clearance if it's open source and you
work for a big company.

I also realize that there was some confusion around URL encoding and OAuth
1.0, but do we understand what the issues were? Can we make the 2.0 spec
simpler in that respect.

*From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
*Joseph Smarr
*Sent:* Thursday, May 06, 2010 11:47 AM
*To:* [email-masked]
*Cc:* [email-masked]
*Subject:* Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
(Proposal)

Thanks, js

Respectfully,

Pid

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 06 May 2010 19:29:04 +0200

+1 , we've got really strong support for JSON and I'm also looking 
forward to review Erans proposal.

I checked back today with some of our service and client application 
developers. All of our services offer JSON and XML as transport format, 
no one even considered using application/x-www-form-urlencoded for 
encoding web services responses.

On the client side, things look even simpler. Our own client application 
generally use JSON on all platforms, incl. smartphones (Android, 
iPhone), handsets (J2ME), home entertainment, and home automation 
devices. Especially the later are really special since they use only a 
small subest of Java (no Java 5, no generics, ..) but JSON is apparently 
not a problem. It is mainly prefered because it combines small 
resource/bandwitdh consumption with ease of use. Our iPhone applications 
are built using external libraries, the experiences are good.

As Joseph said, JSON is the "right horse to bet on". Platform support is 
getting better in my observation. For example, J2ME supports it and 
JavaScript is getting native JSON support as well.

 From my point of view, the Oauth API should fit well into the world of 
HTTP-based services and choosing a completly different encoding 
(application/x-www-form-urlencoded) for OAuth might appear somehow weird 
to developers. Moreover, what do developers really gain from that 
constraint? OAuth just provides the tokens for invoking other services 
securly. If all the other services use JSON, applications need JSON 
libraries anyway. So why bother with that question with respect to OAuth?

regards,
Torsten.

Am 06.05.2010 17:46, schrieb Joseph Smarr:
> Evan-of course when attributes are sent *on-the-url* then they get 
> parsed automatically by the HTTP stack, but we're talking about the 
> response body, which every OAuth 1.0 library I've seen writes their 
> own (usually buggy) parser for, and that's where we're proposing to 
> use JSON.
>
> I've seen good JSON library support on every platform I've needed to 
> work for, and it's becoming more and more common (look at Facebook's 
> new Graph API, for instance), so I doubt many platforms will be 
> without JSON parsers for much longer. That being said, it's prudent to 
> look at the state-of-the-art and verify that requiring JSON is not a 
> practical hindrance for iPhone developers, etc., but I still think 
> it's "betting on the right horse" and it's going to be a lot simpler 
> and less error-prone than either url-encoded values or XML.
>
> Eran-thanks for agreeing to write something up, and I agree we've got 
> strong support for JSON being the primary/only format for the response 
> body. I look forward to the proposed text and will happily review it.
>
> Thanks, js
>
> On Wed, May 5, 2010 at 3:35 PM, Pid <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     wrote:
>     >
>     >>     On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert
>     <[email-masked] <mailto:[email-masked]>
>     >> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >>
>     >>
>     >>
>     >> <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     wrote:
>     >>
>     > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: Luke Shepard <[email-masked]>
Date: Thu, 6 May 2010 22:48:12 -0700

On May 6, 2010, at 9:13 AM, Greg Brail wrote:

I agree that JSON is the long-term winner. However, at least for Java and Python I know that JSON parsers are not part of the standard library, whereas everything needed to decode a url-formencoded library is in the standard libraries and has been there for a long, long time. Keep in mind that the overhead of using third-party code is not just in finding and using the right library, but getting legal clearance if it's open source and you work for a big company.

Python includes a JSON parser in Python 2.6: http://docs.python.org/library/json.html

Java has JSONObject available. Are there cases where it would be difficult to use a library like this?

---

From: Pid <[email-masked]>
Date: Fri, 07 May 2010 15:19:54 +0100

> forward to review Erans proposal.

Sorry but I am going to continue being Devil's Advocate and keep asking
why JSON is better.  Just saying "we all want it" isn't a positive
argument in favor of the change.

> not a problem. 

How is it supported, out of interest?

> It is mainly prefered because it combines small
> resource/bandwitdh consumption with ease of use. 

Compared to what? XML obviously, but not x-www-form-urlencoded, I think.

> Our iPhone applications are built using external libraries, the
> experiences are good. As Joseph said, JSON is the "right horse to bet on". 

Why?

> Platform support is getting better in my observation. For example, 
> J2ME supports it and JavaScript is getting native JSON support as well.

Which is good, but doesn't explain why the format is better.

> to developers. 

Eh?  It's hardly a 'completely different' encoding, it's a key component
of most HTTP-based services.  POST?!

Ampersand separated name/value pairs are a familiar format to web
developers, it's not at all an intellectual challenge to consider their
use in a response.

> Moreover, what do developers really gain from that constraint? 

One can ask the same of JSON.  In fact I am asking that.  Still.

> OAuth just provides the tokens for invoking other services

It's a stretch to make that argument.  There's no guarantee that all
OAuth applications will use JSON unless it's mandated as part of the spec.

application/x-www-form-urlencoded is easy to understand, extremely
simple to implement & parse, has no dependencies and is comprehensively
supported already.

JSON is better than the above because:

(Please fill in the blank)

p

>>     >>         <[email-masked]
>>     <mailto:[email-masked]> <mailto:[email-masked]
>>     <mailto:[email-masked]>>> wrote:
>>     >>
>>     <mailto:[email-masked] <mailto:[email-masked]>>

---

From: "Paul C. Bryan" <[email-masked]>
Date: Fri, 07 May 2010 08:01:37 -0700

Here's my 2¢ worth...

Criteria: If the structure of encoded data is guaranteed to be a flat
list of name-value pairs, x-www-form-urlencoded seems sufficient. If the
structure could be (arbitrarily) complex (e.g. nesting lists or
associative arrays), then definitely use JSON.

Why JSON instead of, say, XML? JSON unambiguously translates to and from
commonly used (usually native) data structures in virtually every common
scripting and programming language in existence.

Paul

-----Original Message-----
From: Pid <[email-masked]>
Reply-to: [email-masked]
To: OAuth WG <[email-masked]>
Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
(Proposal)
Date: Fri, 07 May 2010 15:19:54 +0100

Why?

p

---

From: "Paul C. Bryan" <[email-masked]>
Date: Fri, 07 May 2010 08:09:24 -0700

Well, if the response is guaranteed to be a flat list of name-value
pairs, then JSON seems like overkill.

-----Original Message-----
From: Mike Moore <[email-masked]>
To: Paul C. Bryan <[email-masked]>
Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
(Proposal)
Date: Fri, 7 May 2010 09:04:30 -0600

On Fri, May 7, 2010 at 9:01 AM, Paul C. Bryan <[email-masked]> wrote:
        Here's my 2¢ worth...
        
        Criteria: If the structure of encoded data is guaranteed to be a
        flat
        list of name-value pairs, x-www-form-urlencoded seems
        sufficient. If the
        structure could be (arbitrarily) complex (e.g. nesting lists or
        associative arrays), then definitely use JSON.

As I understand it, there was agreement that the responses would be a
flat list of name-value pairs.
 
        Why JSON instead of, say, XML? JSON unambiguously translates to
        and from
        commonly used (usually native) data structures in virtually
        every common
        scripting and programming language in existence.
        
        Paul

        -----Original Message-----
        From: Pid <[email-masked]>
        Reply-to: [email-masked]
        To: OAuth WG <[email-masked]>
        Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs
        JSON
        (Proposal)
        Date: Fri, 07 May 2010 15:19:54 +0100
        
        > forward to review Erans proposal.
        
        Sorry but I am going to continue being Devil's Advocate and keep
        asking
        why JSON is better.  Just saying "we all want it" isn't a
        positive
        argument in favor of the change.

        
        > resource/bandwitdh consumption with ease of use.
        
        Compared to what? XML obviously, but not x-www-form-urlencoded,
        I think.

        Why?

        
        > (application/x-www-form-urlencoded) for OAuth might appear
        somehow weird
        
        Eh?  It's hardly a 'completely different' encoding, it's a key
        component
        of most HTTP-based services.  POST?!
        
        Ampersand separated name/value pairs are a familiar format to
        web
        developers, it's not at all an intellectual challenge to
        consider their
        use in a response.

        > libraries anyway. So why bother with that question with
        respect to OAuth?
        
        It's a stretch to make that argument.  There's no guarantee that
        all
        OAuth applications will use JSON unless it's mandated as part of
        the spec.

        application/x-www-form-urlencoded is easy to understand,
        extremely
        simple to implement & parse, has no dependencies and is
        comprehensively
        supported already.

        

        
        p
        
        >>     > Having written more than one compliant JSON parser
        myself, it is
        >>     most
        >>     > certainly not "trivial", and not something that can be
        safely
        >>     done with
        >>     > That said, it's not /hard/, and that alone is no reason
        not to
        >>     mandate
        >>     > JSON, but I do want people to be clear about what
        mandating JSON
        >>     means.
        >>     >  Clients will need a fully compliant parser.  Period.
         If the
        >>     OAuth spec
        >>     > requires JSON, then it should require it by reference
        to RFC
        >>     4627, not
        >>     In the original post, Dick suggested that developers were
        having
        >>     trouble
        >>     too tricky, but if the JSON response is so simple why
        bother
        >>     adding this
        >>     URL encoding is required for at least one flow, so IMHO
        it might
        >>     as well
        >>     Can someone from the pro-JSON side offer a clearer
        explanation as
        >>     to the
        <mailto:[email-masked]>
        >>     >>             Even if not supported directly by the
        platform
        >>     there are
        >>     >>         It's not hard to add JSON support, but it's a
        factor in the
        >>     >>         choice.
        >>     >>             Parsing such a document is not a challenge
        even without
        >>     >>             library support.
        >>     >>     unsafe and leads to XSS holes - you need to run
        regex
        >>     matcher to
        >>     >     You are right, using eval to parse JSON is
        dangerous and
        >>     thus as far
        >>     >     as I understand, the recommended way is to use a
        JSON parser
        >>     (aka

---

From: Simone Gianni <[email-masked]>
Date: Fri, 7 May 2010 17:24:38 +0200

+2¢ :D

There are hundreds of formats for a flat key->value "map", expecially when
you already know the native type of the value given the key. Http headers
are a format, HTTP form encoding is a well known and supported format and
already required by OAuth in other places.

JSON is nice, but to invoke a JSON parser (not to mention an XML parser) to
parse a simple map of key->value is overkill .. you can afford it if you are
just dealing with a javascript based client (exec('resp=' + json), and risk
injection) cause the javascript interpreter kicks in and the CPU you are
wasting is not yours :D

On the opposite, if the client is not a javascript based device and the CPU
is yours (for example, you are authenticating your own servers each on each
other) then it's uselessly overkill.

Another problem is generating JSON data. Again, encoding a key->value in
HTTP form encoding is quite CPU trivial and will have to be done anyway in
other parts of OAuth, serializing JSON is not (from a performance POV, not
from a programmer POV), unless you write the json string yourself which
gives JSON no benefit for the server guys.

Couldn't the specification mandate support for HTTP form encoding and
optionally use the HTTP header Content-type to provide alternative encodings
for the same key->value map? Some implementations will then support JSON
cause many clients will be JavaScript, some others may not cause are
specialized in other environments, some others may support YAML or other
representations to better suit their clients or optimize performances or
whatever.

Obviously, it changes if data is structured, in which case JSON or XML are
required, but it does not seem to be the case.

Simone

2010/5/7 Paul C. Bryan <[email-masked]>

> >>     >>         It's not hard to add JSON support, but it's a factor in
> the
> >>     >>         choice.
> >>     >>
> >>     >>
> >>     >>
> >>     >>             Parsing such a document is not a challenge even
> without
> >>     >>             library support.
> >>     >>
> >>     >>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 7 May 2010 08:28:55 -0700

This approach seems the most reasonable to me.

Server MUST support all three formats.
Client MUST support one but MAY support more formats.

This puts a little extra work on the server but since this is on the serializing side, no parser is needed. On the client side it adds no additional complexity - it reduces it because it allows the client to work in its native format (XML, JSON, text).

Those arguing for a single format have not made a compelling argument why having a default format with 2 other optional formats, where the client gets complete flexibility on the parsing side is bad or too complex.

Again, for the server, this is just a single printf() statement per format:

printf("{\"access_token\":\"%s\",\"expires_in\":%d}", token, expires);
printf("<oauth><access_token>%s</access_token><expires_in>%d</expires_in></oauth>", token, expires);

For the client, if they don't like the default, you can use the Accept header or a 'format' query parameter.

Show me where this is more complex!

EHL

> Sent: Thursday, April 29, 2010 12:46 PM
> To: Robert Sayre
> Cc: [email-masked]; [email-masked]
> Hi all,
> please find below a proposal for adding support for multiple response
> formats to the specification. I have taken the current version of the draft
> http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-
> oauth.txt
> and added some modifications indicated by dashed lines. Proposed changes
> to section 3.5.2 should be applied to 3.5.3, 3.6.1., 3.7.1., 3.7.2, and 4., too.
> 
> Basically, the idea is that clients indicate the desired format using Accept
> headers (default) or request parameters (User-Agent flow) and the
> response is delivered accordingly. The formats considered are
> application/json, text/xml, and application/x-www-form-urlencoded. And as
> suggested by Joseph, parameters are encoded straight-forward as flat JSON
> object or XML document, respectively.
> 
> I would appriciate
> regards,
> Torsten.
> 
> 3.5.2.  Web Server Flow
> 3.5.2.2.  Client Requests Access Token
> 
>     The client obtains an access token from the authorization server by <snip>
>     secret_type
>           OPTIONAL.  The access token secret type as described by
>           Section 5.3.  If omitted, the authorization server will issue a
>           bearer token (an access token without a matching secret) as
>           described by Section 5.2.
> 
> --------
> A client may indicate the desired response format using an Accept-Header
> specifying one of the following mime types: application/x-www-form-
> urlencoded,
> application/xml,
> or application/json. If not specified, the default response format is
> application/json.
> (Alternatively, the response format could be specified by a query parameter)
> --------
> 
>     For example, the client makes the following HTTPS request (line
>     breaks are for display purposes only):
> 
>       POST /token HTTP/1.1
>       Host: server.example.com
>       Content-Type: application/x-www-form-urlencoded
> --------
>       Accept: application/json
> --------
> 
>       type=web_server&client_id=s6BhdRkqt3&
>       client_secret=gX1fBat3bV&code=i1WsRn1uB1&
>       redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
> 
> 
>     The authorization server MUST verify that the verification code,
>     client identity, client secret, and redirection URI are all valid and
>     match its stored association.  If the request is valid, the
>     authorization server issues an access token and delivers it to the
>     client in the HTTP response body using
> --------
>     the mime type as requested by the client or "application/json"
> --------
> with a 200 status code (OK).
> 
>     The response contains the following parameters:
> 
>     access_token
>           REQUIRED.  The access token issued by the authorization server.
> 
>     expires_in
>           OPTIONAL.  The duration in seconds of the access token
>           lifetime.
> 
>     refresh_token
>           OPTIONAL.  The refresh token used to obtain new access tokens
>           using the same end user access grant as described in Section 4.
> 
>     access_token_secret
>           REQUIRED if requested by the client.  The corresponding access
>           token secret as requested by the client.
> 
> --------
>     The response format depends on the requested mime type. The
>     content-type header field indicates mime type and may optionaly
>     indicate charset.
> 
>     "application/json": All parameters are encoded as one flat JSON object
> with one key/value pair per parameter.
> 
>     For example:
> 
>       HTTP/1.1 200 OK
>       Content-Type: application/json
> 
>     "text/xml": All parameters are encoded as one XML document with the
> root element <token_response>. For each parameter there is a
> corresponding sub-element with the parameter name containing the
> respectives parameters value.
> 
>     For example:
> 
>       HTTP/1.1 200 OK
>       Content-Type: text/xml
> 
> <token_response>
> <access_token>SlAV32hkKG
> <expires_in>3600</expires_in>
> <refresh_token>8xLOxBtZp8</refresh_token>
> </token_response>
> 
>     "application/x-www-form-urlencoded": parameters are encoded as
> name/value pairs
> --------
>     For example:
> 
>       HTTP/1.1 200 OK
>       Content-Type: application/x-www-form-urlencoded
> 
> 
> access_token=SlAV32hkKG&expires_in=3600&refresh_token=8xLOxBtZp8
> 
> 
>     If the request is invalid, the authorization server returns an error
>     message in the HTTP response body using the
> --------
>     the mime type as requested by the client or "application/json"
> --------
>     with a 400 status code (Bad Request).
> 
>     The response contains the following parameter:
> 
>     error
>           OPTIONAL.  The parameter value MUST be set to either
>           "redirect_uri_mismatch" or "expired_verification_code" (case
>           sensitive).
> 
> --------
>     The response format depends on the requested mime type. The response
> rendering follows the rules as specified above.
> --------
> For example:
> 
> --------
>       HTTP/1.1 400 Bad Request
>       Content-Type: application/json
> 
>       { "error"="expired_verification_code" }
> 
> --------
> 3.5.1.  User-Agent Flow
> 3.5.1.1.  Client Requests Authorization
> 
>     In order for the end user to grant the client access, the client
>     sends the end user to the authorization server.  The client
>     constructs the request URI by adding the following URI query
>     parameters to the user authorization endpoint URI:
> <snip>
> --------
> response_format
>           OPTIONAL. Indicates the format used to deliver token data and
>           errors to the client. The parameter value MUST be set to "text/xml",
>           "application/json", or "application/x-www-form-urlencoded".
> Defaults
>           to "application/json" if omitted.
> 
> --------
> 3.5.1.1.1.  End User Grants Authorization
> 
>     If the end user authorizes the access request, the authorization
>     server issues an access token and delivers it to the client by adding
>     the following parameters, using the
> --------
>     mime type as indicated by "response_format"
> --------
> to the redirection URI fragment:
> 
>     access_token
>           REQUIRED.  The access token.
> 
>     expires_in
>           OPTIONAL.  The duration in seconds of the access token
>           lifetime.
> 
>     refresh_token
>           OPTIONAL.  The refresh token.
> 
>     state
>           REQUIRED if the "state" parameter was present in the client
>           authorization request.  Set to the exact value received from
>           the client.
> 
>     access_token_secret
>           REQUIRED if requested by the client.  The corresponding access
>           token secret as requested by the client.
> --------
>     The way and format parameters are added to the fragment depend on the
> requested mime type.
> 
>     "application/json": All parameters are encoded as one flat JSON object
> with one key/value pair per parameter. This document is URL encoded and
> added as parameter "oauth_response" to the fragment.
> 
>     For example, the authorization server redirects the end user's user-
>     agent by sending the following HTTP response:
> 
>      HTTP/1.1 302 Found
>      Location:
> http://example.com/rd#oauth_response=%7B+%22access_token%22%3A+
> %22SlAV32hkKG%22%2C+%22expires_in%22%3A+%223600%22%2C+%22refr
> esh_token%22%3A+%228xLOxBtZp8%22+%7D
> 
>     "text/xml": All parameters are encoded as one XML document with the
> root element <token_response>. For each parameter there is a
> corresponding sub-element with the parameter name containing the
> respectives parameters value. The XML document is URL encoded and added
> as parameter "oauth_response" to the fragment.
> 
>      For example:
> 
>      HTTP/1.1 302 Found
>      Location:
> http://example.com/rd#oauth_response=%3Ctoken_response%3E%3Cacce
> ss_token%3ESlAV32hkKG%3Cexpires_in%3E3600%3C%2Fexpires_in%3E%3Cr
> efresh_token%3E8xLOxBtZp8%3C%2Frefresh_token%3E%3C%2Ftoken_resp
> onse%3E
> 
>     "application/x-www-form-urlencoded": All parameter are directly added as
>     parameters to the redirection URI fragment.
> --------
>     For example:
> 
>      HTTP/1.1 302 Found
>      Location:
> http://example.com/rd#access_token=FJQbwq9&expires_in=3600
> 
> 3.5.1.1.2.  End User Denies Authorization
> 
>     If the end user denied the access request, the authorization server
>     responds to the client by adding the following parameters, using the
> --------
>     mime type as indicated by "response_format"
> --------
> to the redirection URI fragment:
> 
>     error
>           REQUIRED.  The parameter value MUST be set to "user_denied"
>           (case sensitive).
> 
>     state
>           REQUIRED if the "state" parameter was present in the client
>           authorization request.  Set to the exact value received from
>           the client.
> --------
>      The way and format parameters are added to the fragment depend on the
> requested mime type and follows the same rules as specified above.
> --------
>     For example, the authorization server responds with the following:
> 
>       HTTP/1.1 302 Found
>       Location:
> http://example.com/rd#oauth_response=%7b+%22error%22%3d%22user%
> 5fdenied%22%7d
>

---

From: Pid <[email-masked]>
Date: Fri, 07 May 2010 16:46:14 +0100

> Show me where this is more complex!

+1  Fair enough.

Flexibility via multiple formats is an entirely different proposal and
one that I think is very reasonable.

I just can't find a way to justify JSON as the only permitted format for
response body content.

p

---

From: Yaron Goland <[email-masked]>
Date: Fri, 7 May 2010 16:49:21 +0000

Every format we add increases the probability of failing to interoperate. 

I believe as a working group we need to specify exactly one format and only one format. That doesn't preclude later extensions that support more formats but if our goal is interoperability then the fewer options the more likely we get interoperability.

So please, just one format.

	Yaron

P.S. My personal vote for that format is urlencoded but I see that as a secondary issue to supporting exactly one format.

> Of Pid
> Sent: Friday, May 07, 2010 8:46 AM
> To: [email-masked]
> > This puts a little extra work on the server but since this is on the serializing
> side, no parser is needed. On the client side it adds no additional complexity -
> it reduces it because it allows the client to work in its native format (XML,
> JSON, text).
> >
> > Those arguing for a single format have not made a compelling argument
> why having a default format with 2 other optional formats, where the client
> gets complete flexibility on the parsing side is bad or too complex.
> >
> printf("<oauth><access_token>%s</access_token><expires_in>%d</expire
> s_
> > in></oauth>", token, expires);
> >
> Flexibility via multiple formats is an entirely different proposal and one that I
> think is very reasonable.
> 
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Torsten Lodderstedt
> >> and added some modifications indicated by dashed lines. Proposed
> >> changes to section 3.5.2 should be applied to 3.5.3, 3.6.1., 3.7.1., 3.7.2, and
> 4., too.
> >>
> >> Basically, the idea is that clients indicate the desired format using
> >> Accept headers (default) or request parameters (User-Agent flow) and
> >> the response is delivered accordingly. The formats considered are
> >> application/json, text/xml, and application/x-www-form-urlencoded.
> >> And as suggested by Joseph, parameters are encoded straight-forward
> >> as flat JSON object or XML document, respectively.
> >>
> >> I would appriciate
> >> regards,
> >> Torsten.
> >>
> >> 3.5.2.  Web Server Flow
> >> A client may indicate the desired response format using an
> >> Accept-Header specifying one of the following mime types:
> >> application/x-www-form- urlencoded, application/xml, or
> >> application/json. If not specified, the default response format is
> >> application/json.
> >>     "application/json": All parameters are encoded as one flat JSON
> >> object with one key/value pair per parameter.
> >>
> >>     For example:
> >>
> >>       HTTP/1.1 200 OK
> >>     "text/xml": All parameters are encoded as one XML document with
> >> the root element <token_response>. For each parameter there is a
> >> response rendering follows the rules as specified above.
> >> --------
> >> For example:
> >>
> >> --------
> >>       HTTP/1.1 400 Bad Request
> >>     The way and format parameters are added to the fragment depend on
> >> the requested mime type.
> >>
> >>     "application/json": All parameters are encoded as one flat JSON
> >> object with one key/value pair per parameter. This document is URL
> >> encoded and added as parameter "oauth_response" to the fragment.
> >>
> >>     "text/xml": All parameters are encoded as one XML document with
> >> the root element <token_response>. For each parameter there is a
> >> respectives parameters value. The XML document is URL encoded and
> >>      The way and format parameters are added to the fragment depend
> >> on the requested mime type and follows the same rules as specified
> above.
> >> --------

---

From: Robert Sayre <[email-masked]>
Date: Fri, 7 May 2010 13:24:10 -0400

> Show me where this is more complex!

You can't actually use printf to produce this output in any quality
implementation, especially if you want to support extension
parameters. Using printf will get you at least three varieties of
escaping bugs, so you'll need special libraries to generate each
format.

I think form-encoding is OK if the WG knows that these response bodies
will never need to be complex, and never contain more than ASCII.

If these need more than ASCII, you'll be relying on everyone to use
the same (unspecified, btw) input encoding before they produce their
form-encoded string. You're still going to have to spec an encoding
param or make all implementations promise to use UTF-8 prior to URL
encoding. Neither of those strategies will work very well. That said,
the spec already has this problem elsewhere, so using JSON here won't
fix it entirely.

Also, adding something complex to a form-encoded response will get
pretty ugly, since you'll need a namespace-like thing prepended to
each field name.

-- 

Robert Sayre

---

From: Greg Brail <[email-masked]>
Date: Fri, 7 May 2010 14:29:44 -0400

JSONObject is fine. I imagine that any development organization could use it
in their project as long as their legal staff is willing to forgo the option
of doing Evil. (That's what the license says ;-)

My point is that pulling in *any* third party code is always a bigger
barrier to adoption to using something that's already built in to the
environment and has been for many years, so it even works in organizations
that have not yet adopted the latest releases of things. (With that said,
having JSON support in Python 2.6 is a good thing and it's too bad that the
Java platform is moving so slowly these days.)

As others have said more eloquently, if need to ever support non-string data
types, arrays, or nested structures, then JSON is the best choice, over XML
or something hand-rolled. But if the need is to just handle a short list of
single name-value pairs, then using form-urlencoded, to me, is the simplest
choice that places the fewest barriers in front of developers on all
platforms.

*From:* Luke Shepard [mailto:[email-masked]]
*Sent:* Friday, May 07, 2010 1:48 AM
*To:* Greg Brail
*Cc:* [email-masked]
*Subject:* Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
(Proposal)

Python includes a JSON parser in Python 2.6:
http://docs.python.org/library/json.html

Java has JSONObject available. Are there cases where it would be difficult
to use a library like this?

---

From: Brian Eaton <[email-masked]>
Date: Mon, 10 May 2010 14:45:47 -0700

> of doing Evil. (That's what the license says ;-)

If the issue is purely the quirky licensing of the org.json code, gson
should be an option:

http://code.google.com/p/google-gson/

Cheers,
Brian