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

Eran Hammer-Lahav <eran@hueniverse.com> Sat, 01 May 2010 02:33 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 196C63A6830 for <oauth@core3.amsl.com>; Fri, 30 Apr 2010 19:33:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.537
X-Spam-Level:
X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9pfsShvk6hN for <oauth@core3.amsl.com>; Fri, 30 Apr 2010 19:33:57 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 9C5C43A680D for <oauth@ietf.org>; Fri, 30 Apr 2010 19:33:57 -0700 (PDT)
Received: (qmail 24068 invoked from network); 1 May 2010 02:33:44 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 May 2010 02:33:43 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 30 Apr 2010 19:33:43 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: OAuth WG <oauth@ietf.org>
Date: Fri, 30 Apr 2010 19:33:26 -0700
Thread-Topic: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
Thread-Index: Acro0NT7IR9jk8IeTJ2NUbh5WSydqAABbofw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723439323D0533@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723438E30A379B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20100419134825.134951nuzvi35hk4@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723438E5C7F45E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <t2wc334d54e1004200924ja0e7786u9b349a1931098f2a@mail.gmail.com> <50802E3D-2578-409C-92BC-B5C47EBE6C21@gmail.com>
In-Reply-To: <50802E3D-2578-409C-92BC-B5C47EBE6C21@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723439323D0533P3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 May 2010 02:33:59 -0000

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.

EHL

From: Dick Hardt [mailto:dick.hardt@gmail.com]
Sent: Friday, April 30, 2010 6:52 PM
To: jsmarr@stanfordalumni.org
Cc: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON

+1 to JSON being the only format.

On 2010-04-20, at 9:24 AM, Joseph Smarr 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 <eran@hueniverse.com<mailto:eran@hueniverse.com>> 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:torsten@lodderstedt.net<mailto:torsten@lodderstedt.net>]
> 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: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org>] 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
> >> OAuth@ietf.org<mailto:OAuth@ietf.org>
> >> https://www.ietf.org/mailman/listinfo/oauth
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org<mailto:OAuth@ietf.org>
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
>
>

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth