Re: [OAUTH-WG] Registration: JSON Encoded Input
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
Re: [OAUTH-WG] Registration: JSON Encoded Input
Parameters that can be JSON lists rather than space separated sting s probably should be unless there is some compelling reason as in scopes to keep them space separated. May as well save unnecessary string parsing. John B. On 2013-02-15, at 11:58 AM, Justin Richer jric...@mitre.org wrote: 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Registration: JSON Encoded Input
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.orgmailto:OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Registration: JSON Encoded Input
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] 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
Re: [OAUTH-WG] Registration: JSON Encoded Input
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 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] 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
Re: [OAUTH-WG] Registration: JSON Encoded Input
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
Re: [OAUTH-WG] Registration: JSON Encoded Input
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 wrote:
On Tue, Feb 12, 2013 at 11:44 AM, John Bradley 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 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] 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
-
Re: [OAUTH-WG] Registration: JSON Encoded Input
Just POST the JSON as the HTTP payload with mime-type application/json:
$ curl -v -H Content-Type: application/json -X POST -d '{Hello: World}'
http://requestb.in/19qit4u1
* About to connect() to requestb.in port 80 (#0)
* Trying 107.20.236.186... connected
* Connected to requestb.in (107.20.236.186) port 80 (#0)
POST /19qit4u1 HTTP/1.1
User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7
OpenSSL/0.9.8r zlib/1.2.3
Host: requestb.in
Accept: */*
Content-Type: application/json
Content-Length: 18
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Date: Tue, 12 Feb 2013 20:03:39 GMT
Content-Length: 3
Connection: keep-alive
ok
* Connection #0 to host requestb.in left intact
* Closing connection #0
Cheers,
Pat
--
Pat Patterson | Principal Developer Evangelist | 408-849-4681 |
http://about.me/patpatterson
On Feb 12, 2013, at 11:58 AM, 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.commailto:twb...@google.com wrote:
On Tue, Feb 12, 2013 at 11:44 AM, John Bradley
ve7...@ve7jtb.commailto: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.orgmailto: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.
Re: [OAUTH-WG] Registration: JSON Encoded Input
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 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 wrote:
On Tue, Feb 12, 2013 at 11:44 AM, John Bradley 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 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] On Behalf Of
Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject:
Re: [OAUTH-WG] Registration: JSON Encoded Input
+1 to what Pat and Justin said.
On Tue, Feb 12, 2013 at 12:59 PM, Justin Richer 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 wrote:
On Tue, Feb 12, 2013 at 11:44 AM, John Bradley 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 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.orgoauth-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
Re: [OAUTH-WG] Registration: JSON Encoded Input
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
Re: [OAUTH-WG] Registration: JSON Encoded Input
I am OK with that language.
On 2013-02-12, at 5:16 PM, Justin Richer jric...@mitre.org wrote:
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 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 wrote:
On Tue, Feb 12, 2013 at 11:44 AM, John Bradley 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 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:
Re: [OAUTH-WG] Registration: JSON Encoded Input
If we are sending JSON, then the content-type should be application/json, or
some variant of it if needed be (e.g. application/oauthreg+json etc.
-- I do not think we need it, though.)
I do not like posting it with other content-type unless we explicitly
create a variable and
define a serialization method (such as JWT).
My original comment was just asking to get some feedback from the developers.
Depending on the answer, we may want to put some explanatory notes on it.
My preference is to send JSON.
BTW, would there be a need for signing the registration data?
Nat
2013/2/13 John Bradley ve7...@ve7jtb.com:
I am OK with that language.
On 2013-02-12, at 5:16 PM, Justin Richer jric...@mitre.org wrote:
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 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 wrote:
On Tue, Feb 12, 2013 at 11:44 AM, John Bradley 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 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
