I would then request that people come up with a real example of where it
*won't* work. I've seen workable solutions, and even some automagic
ones, on several major platforms in which one would write a web
server/AS: PHP, Java (Spring and raw servlets), Ruby (rails and
sinatra), and Node.js can all do it.
I would suggest the following text (adapted from what's in -05 right
now) to address this:
The Client sends an HTTP POST to the Client Registration Endpoint
with a content type of "application/json". The HTTP Entity Payload is
a JSON document consisting of a JSON object and all parameters as top-
level members of that JSON object.
(Would have to be tweaked for the PUT/PATCH verbs but it's effectively
the same.)
-- Justin
On 02/12/2013 03:07 PM, John Bradley wrote:
I am fine with that as long as all the IdP tools have access to the
entity body in some reasonable way. That seems like the most
sensible thing.
However given the number of people talking about encoding it in a form
to get access to it, we should check that it works for everyone.
John B.
On 2013-02-12, at 4:59 PM, Justin Richer <jric...@mitre.org
<mailto:jric...@mitre.org>> wrote:
If that's the question, then my proposal is the Content-type is
"application/json" and the HTTP Entity Body is the JSON document. No
form posts or parameter names to be had here.
-- Justin
On 02/12/2013 02:58 PM, John Bradley wrote:
Some people apparently encode the JSON as the key in a form POST,
some people do a form POST with a special key and the JSON as the
value.
There appear to be a number of theories in the wild. I am not an
expert I just looked up code examples from several sources stack
overflow and the like.
We probably need to get input from developers who have experience
working with different frameworks. I think the differences have to
do with decoding it at the receiver.
We originally had registration posting JSON but we changed form
encoding as that worked in all environments. We just need to be
sure we are not creating problems for people with the change back.
John B.
On 2013-02-12, at 4:48 PM, Tim Bray <twb...@google.com
<mailto:twb...@google.com>> wrote:
On Tue, Feb 12, 2013 at 11:44 AM, John Bradley <ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>> 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.
Hm? Not following on “several ways”, I’d have thought that POSTing
JSON is just POSTing JSON, must be missing something. -T
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'); $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>
[mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org <mailto: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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
