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
