+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:
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 <[email protected]
<mailto:[email protected]>> 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
> <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
wrote:
>
> Am 05.05.2010 20:01, schrieb Evan Gilbert:
>>
>>
>> On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert
<[email protected] <mailto:[email protected]>
>> <mailto:[email protected] <mailto:[email protected]>>> wrote:
>>
>>
>>
>> On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt
>> <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
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
> [email protected] <mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected] <mailto:[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
