FYI, this issue is also being discussed as an OpenID Connect issue at
https://bitbucket.org/openid/connect/issue/747. I think that Nat's recent
comment there bears repeating on this list:
Nat Sakimura:
Not so sure. For example, PHP cannot get the JSON object form application/json
POST in $_POST.
It is OK to have a parameter like "request" that holds JSON. Then, you can get
to it from $_POST['request']. However, if you POST the JSON as the POST body,
then you would have to call a low level function in the form of:
```
#!php
$file = file_get_contents('php://input'); $x = json_decode($file); ```
Not that it is harder, but it is much less known. Many PHP programmers will
certainly goes "???".
We need to check what would be the cases for other scripting languages before
making the final decision.
-- Mike
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: JSON Encoded Input
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<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
