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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


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

Reply via email to