In this case, I believe that it really is a fairly straightforward case
of replacing the form-based key-value hash with a JSON-based key-value
hash. So all the existing parameters are converted into top-level JSON
objects, and the parameter values become the values of those members.
This is the exact same form that the JSON output from the endpoint
already was. The data model remains essentially identical between the
two. Is there another reasonable way to do this? I haven't seen another
proposal put forward, yet, though I'm sure we could dream up all kinds
of unreasonable ones. :)
The only extra structured in the discussion draft (-05) are most of the
lists, like redirect_uri and grant_type. An extension would want to use
JSON numbers or booleans where it makes sense. Note that the "scope"
parameter is still defined as a space-separated list of strings, a
definition taken directly from OAuth Core. This is largely from feedback
I got in regard to the Introspection draft, which tried to add JSON list
structure to "scope" and confused folks.
-- Justin
On 02/12/2013 02:44 PM, John Bradley wrote:
Nat and I hashed out the pro's and cons of JSON requests.
If we POST or PUT a JSON object we need to be specific as there rare
several ways to do it that may work better or worse depending on the
receiver.
This needs to be looked over and one picked.
In the other thread about the server returning the update URI and
being able to encode the client in that if it needs to takes care of
Servers that need that info in query parameters or the path to do the
routing.
The use of structure can be used to enhance readability and parsing of
the input, and output.
However we need to temper our urge to apply structure to everything.
IT needs to be applied carefully otherwise we start looking like crazies.
If we do it cautiously I am in favour of JSON as input.
John B.
On 2013-02-12, at 4:32 PM, Justin Richer <jric...@mitre.org
<mailto:jric...@mitre.org>> wrote:
Thanks for forwarding that, Mike. I'll paste in my response to Nat's
concern here as well:
It's an increasingly well known pattern that has reasonable
support on the server side. For PHP, I was able to find the above
example via the top hit on Stack Overflow. In Ruby, it's a matter
of something like:
JSON.parse(request.body.read)
depending on the web app framework. On Java/Spring, it's a matter
of injecting the entity body as a string and handing it to a
parser (Gson in this case):
public String doApi(@RequestBody String jsonString) { JsonObject
json = new JsonParser().parse(jsonString).getAsJsonObject();
It's a similar read/parse setup in Node.js as well.
It's true that in all of these cases you don't get to make use of
the routing or data binding facilities (though in Spring you can
do that for simpler domain objects using a ModelBinding), so you
don't get niceities like the $_POST array in PHP handed to you.
This is why I don't think it's a good idea at all to switch
functionality based on the contents of the JSON object. It should
be a domain object only, which is what it would be in this case.
I think that the positives of using JSON from the client's
perspective and the overall protocol design far outweigh the
slightly increased implementation cost at the server.
-- Justin
On 02/12/2013 02:11 PM, Mike Jones wrote:
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' <php://input%27>); $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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
