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

["Paul C. Bryan" <[e-mail]>]

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 <[e-mail]>
To: Paul C. Bryan <[e-mail]>
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 <[e-mail]> 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 <[e-mail]>
        Reply-to: [e-mail]
        To: OAuth WG <[e-mail]>
        Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs
        JSON
        (Proposal)
        Date: Fri, 07 May 2010 15:19:54 +0100
        
        On 06/05/2010 18:29, Torsten Lodderstedt wrote:
        > +1 , we've got really strong support for JSON and I'm also
        looking
        > 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.
        
        > 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.
        
        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.
        
        > 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.
        
        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
        > securly. If all the other services use JSON, applications need
        JSON
        > 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.
        
        JSON is better than the above because:
        
        
        
        
        (Please fill in the blank)
        
        
        
        p
        
        > regards,
        > Torsten.
        >
        > Am 06.05.2010 17:46, schrieb Joseph Smarr:
        >> 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 <[e-mail]
        >> <mailto:[e-mail]>> 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
        >>     > <[e-mail]
        <mailto:[e-mail]>
        >>     <mailto:[e-mail]
        <mailto:[e-mail]>>>
        >>     wrote:
        >>     >
        >>     >     Am 05.05.2010 20:01, schrieb Evan Gilbert:
        >>     >>
        >>     >>
        >>     >>     On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert
        >>     <[e-mail] <mailto:[e-mail]>
        >>     >>     <mailto:[e-mail]
        <mailto:[e-mail]>>> wrote:
        >>     >>
        >>     >>
        >>     >>
        >>     >>         On Wed, May 5, 2010 at 10:47 AM, Torsten
        Lodderstedt
        >>     >>         <[e-mail]
        >>     <mailto:[e-mail]>
        <mailto:[e-mail]
        >>     <mailto:[e-mail]>>> 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
        >>     >     [e-mail] <mailto:[e-mail]>
        >>     <mailto:[e-mail] <mailto:[e-mail]>>
        >>     >     https://www.ietf.org/mailman/listinfo/oauth
        >>     >
        >>     >
        >>     >
        >>     >
        >>     > _______________________________________________
        >>     > OAuth mailing list
        >>     > [e-mail] <mailto:[e-mail]>
        >>     > https://www.ietf.org/mailman/listinfo/oauth
        >>
        >>
        >>
        >>     _______________________________________________
        >>     OAuth mailing list
        >>     [e-mail] <mailto:[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