Subject: Re: [OAUTH-WG] Registration: JSON Encoded Input

From: Justin Richer <[email-masked]>
Date: Fri, 15 Feb 2013 09:58:31 -0500

In case people missed a subtle change, I wanted to bring it to the 
group's attention:

The metadata parameters "request_uri" and "grant_type" are now JSON 
lists instead of space-separated lists of strings. The "scope" parameter 
remains a space-separated string, taking its definition from RFC6749 
section 3.3. This is due to a conversation that came up around the use 
of the "scope" parameter in the introspection endpoint, and folks 
generally thought that the definitions should match.

If we do JSON input (which there seems to be overwhelming support for), 
then I believe we should at the very least split up lists that are lists 
instead of forcing clients and servers to do string parsing.

  -- Justin

On 02/11/2013 04:14 PM, Justin Richer wrote:
> Draft -05 of OAuth Dynamic Client Registration [1] switched from a 
> form-encoded input that had been used by drafts -01 through -04 to a 
> JSON encoded input that was used originally in -00. Note that all 
> versions keep JSON-encoded output from all operations.
>
> Pro:
>  - JSON gives us a rich data structure so that things such as lists, 
> numbers, nulls, and objects can be represented natively
>  - Allows for parallelism between the input to the endpoint and output 
> from the endpoint, reducing possible translation errors between the two
>  - JSON specifies UTF8 encoding for all strings, forms may have many 
> different encodings
>  - JSON has minimal character escaping required for most strings, 
> forms require escaping for common characters such as space, slash, 
> comma, etc.
>
> Con:
>  - the rest of OAuth is form-in/JSON-out
>  - nothing else in OAuth requires the Client to create a JSON object, 
> merely to parse one
>  - form-in/JSON-out is a very widely established pattern on the web today
>  - Client information (client_name, client_id, etc.) is conflated with 
> access information (registration_access_token, _links, expires_at, 
> etc.) in root level of the same JSON object, leaving the client to 
> decide what needs to (can?) be sent back to the server for update 
> operations.
>
>
> Alternatives include any number of data encoding schemes, including 
> form (like the old drafts), XML, ASN.1, etc.
>
>
>  -- Justin
>
> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: John Bradley <[email-masked]>
Date: Fri, 15 Feb 2013 12:11:04 -0300

Parameters that can be JSON lists rather than space separated sting s probably should be unless there is some compelling reason as in scopes to keep them space separated.   May as well save unnecessary string parsing.
 
John B.

On 2013-02-15, at 11:58 AM, Justin Richer <[email-masked]> wrote:

> In case people missed a subtle change, I wanted to bring it to the group's attention:
> 
> The metadata parameters "request_uri" and "grant_type" are now JSON lists instead of space-separated lists of strings. The "scope" parameter remains a space-separated string, taking its definition from RFC6749 section 3.3. This is due to a conversation that came up around the use of the "scope" parameter in the introspection endpoint, and folks generally thought that the definitions should match.
> 
> If we do JSON input (which there seems to be overwhelming support for), then I believe we should at the very least split up lists that are lists instead of forcing clients and servers to do string parsing.
> 
> -- Justin
> 
>> Draft -05 of OAuth Dynamic Client Registration [1] switched from a form-encoded input that had been used by drafts -01 through -04 to a JSON encoded input that was used originally in -00. Note that all versions keep JSON-encoded output from all operations.
>> 
>> Pro:
>> - JSON gives us a rich data structure so that things such as lists, numbers, nulls, and objects can be represented natively
>> - Allows for parallelism between the input to the endpoint and output from the endpoint, reducing possible translation errors between the two
>> - JSON specifies UTF8 encoding for all strings, forms may have many different encodings
>> - JSON has minimal character escaping required for most strings, forms require escaping for common characters such as space, slash, comma, etc.
>> 
>> Con:
>> - nothing else in OAuth requires the Client to create a JSON object, merely to parse one
>> - Client information (client_name, client_id, etc.) is conflated with access information (registration_access_token, _links, expires_at, etc.) in root level of the same JSON object, leaving the client to decide what needs to (can?) be sent back to the server for update operations.
>> 
>> 
>> Alternatives include any number of data encoding schemes, including form (like the old drafts), XML, ASN.1, etc.
>> 
>> 
>> -- Justin
>>