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

Joseph Smarr <jsmarr@gmail.com> Thu, 06 May 2010 15:57 UTC

Return-Path: <jsmarr@gmail.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 54D953A6C09 for <oauth@core3.amsl.com>; Thu, 6 May 2010 08:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.027
X-Spam-Level:
X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[AWL=-1.029, BAYES_50=0.001, 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 qhZWzgdDPZ6z for <oauth@core3.amsl.com>; Thu, 6 May 2010 08:57:08 -0700 (PDT)
Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id AEEC73A6D79 for <oauth@ietf.org>; Thu, 6 May 2010 08:47:25 -0700 (PDT)
Received: by pxi19 with SMTP id 19so44966pxi.31 for <oauth@ietf.org>; Thu, 06 May 2010 08:47:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:reply-to :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; bh=rZtBEviAAc36WENKa1Ya9UgqlbodzARWy6NO2SkVp+o=; b=KTw0jDV37iPn/371OOAFbAZtzK7CRtpeOz1NLN5Y5mRynwUuiuF9BTf7Gnhnr/hM/U irUqB9D/v1VgCL6rbCWdh8sTsNUMsTfQJ41Qc21rHwkgbhgk5FLOI3ee9SXEJbmkrNPK xJm1QuMzWiwzdaX+jC7iCziGgYUf7YliM/0r4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; b=GjL75tF2TSqY/OfUPSX1dWO4PfQS0V5YKxt9iu5eTLQmaV3Jsr/S2i0/gdWRfNhUUs Zp/+bqwAfxyRS406r04Bx2/4qjwnRUFd/fhS6jXpOjZLpUgV1zt5YDwGwSStmaUAr8XX 4ZcmvCHeC4dxiRmBoCtISRxkYjrFtoMhuubuo=
Received: by 10.142.59.10 with SMTP id h10mr442252wfa.284.1273160830353; Thu, 06 May 2010 08:47:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.143.164.14 with HTTP; Thu, 6 May 2010 08:46:50 -0700 (PDT)
In-Reply-To: <4BE1F2A1.9040707@pidster.com>
References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTik3NSJynWfiNWovruPEOT2Y6G1zcWPFOaS_pHdy@mail.gmail.com> <4BE1AF25.7000308@lodderstedt.net> <AANLkTil2_9KOm1eRoC0jxvH99E55K3BEW-T5cgWLay9H@mail.gmail.com> <AANLkTilWV3VVBROXZuky5OLNzM2hz27pEqwG1l6W2Uc1@mail.gmail.com> <4BE1BB10.7060009@lodderstedt.net> <w2v77facc501005051149pca35de47tfcca515a3b557c81@mail.gmail.com> <4BE1F2A1.9040707@pidster.com>
From: Joseph Smarr <jsmarr@gmail.com>
Date: Thu, 06 May 2010 08:46:50 -0700
Message-ID: <s2mc334d54e1005060846k10f446b4r5f907acf237f8735@mail.gmail.com>
To: pid@pidster.com
Content-Type: multipart/alternative; boundary="00504502af980903650485eedb20"
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: jsmarr@stanfordalumni.org
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: Thu, 06 May 2010 15:57:10 -0000

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

On Wed, May 5, 2010 at 3:35 PM, Pid <pid@pidster.com> wrote:

> On 05/05/2010 19:49, DeWitt Clinton wrote:
> > 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
>
> 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
> > <torsten@lodderstedt.net <mailto:torsten@lodderstedt.net>> wrote:
> >
> >     Am 05.05.2010 20:01, schrieb Evan Gilbert:
> >>
> >>
> >>     On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert <uidude@google.com
> >>     <mailto:uidude@google.com>> wrote:
> >>
> >>
> >>
> >>         On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt
> >>         <torsten@lodderstedt.net <mailto:torsten@lodderstedt.net>>
> wrote:
> >>
> >>             Even if not supported directly by the platform there are
> >>             many JSON libraries available these days.
> >>
> >>
> >>         It's not hard to add JSON support, but it's a factor in the
> >>         choice.
> >>
> >>
> >>
> >>             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.
> >>
> >>
> >>         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.
> >
> >     _______________________________________________
> >     OAuth mailing list
> >     OAuth@ietf.org <mailto:OAuth@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>