Subject: [OAUTH-WG] Registration: JSON Encoded Input

From: Justin Richer <[email-masked]>
Date: Mon, 11 Feb 2013 16:14:35 -0500

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

---

From: Mike Jones <[email-masked]>
Date: Tue, 12 Feb 2013 19:11:53 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: [email-masked]
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:

  - nothing else in OAuth requires the Client to create a JSON object, merely to parse one

  - 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

_______________________________________________

OAuth mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Tue, 12 Feb 2013 14:32:46 -0500

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:
>
> 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
>
>   - Allows for parallelism between the input to the endpoint and 
> output from the endpoint, reducing possible translation errors between 
> the two
>
>   - JSON has minimal character escaping required for most strings, 
> forms require escaping for common characters such as space, slash, 
> comma, etc.
>
> Con:
>
>   - 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
>
> [email-masked] <mailto:[email-masked]>
>

---

From: John Bradley <[email-masked]>
Date: Tue, 12 Feb 2013 16:44:56 -0300

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 <[email-masked]> 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:
> 
> 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 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
> 
>> [email-masked]
> [email-masked]

---

From: Tim Bray <[email-masked]>
Date: Tue, 12 Feb 2013 11:48:34 -0800

On Tue, Feb 12, 2013 at 11:44 AM, John Bradley <[email-masked]> wrote:

> 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.

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.
>
> 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:
>
> 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 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
>
> 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****
>
> ** **
>
> From: [email-masked] [mailto:[email-masked]<[email-masked]>]
> On Behalf Of Justin Richer
> ** **
> 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:****
>
> numbers, nulls, and objects can be represented natively****
>
> from the endpoint, reducing possible translation errors between the two***
> *
>
> different encodings****
> require escaping for common characters such as space, slash, comma, etc.**
> **
>
> ** **
>
> Con:****
>
>   - the rest of OAuth is form-in/JSON-out****
>
> merely to parse one****
> ****
> 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.****
>
> ** **
>
> ** **
>
> (like the old drafts), XML, ASN.1, etc.****
>
> ** **
>
> ** **
>
>   -- Justin****
>
> ** **
>
> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05****
>
> _______________________________________________****
>
> OAuth mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 12 Feb 2013 14:52:50 -0500

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:
> 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.
>
> On 2013-02-12, at 4:32 PM, Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>     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:
>>
>>     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):
>>
>>     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.
>>
>>> 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:
>>>
>>> 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); ```
>>>
>>> We need to check what would be the cases for other scripting 
>>> languages before making the final decision.
>>>
>>> -- Mike
>>>
>>>   - JSON gives us a rich data structure so that things such as 
>>> lists, numbers, nulls, and objects can be represented natively
>>>
>>> output from the endpoint, reducing possible translation errors 
>>> between the two
>>>

---

From: John Bradley <[email-masked]>
Date: Tue, 12 Feb 2013 16:58:44 -0300

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 <[email-masked]> wrote:

> Hm?  Not following on “several ways”, I’d have thought that POSTing JSON is just POSTing JSON, must be missing something. -T
>  
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 12 Feb 2013 14:59:24 -0500

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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>
>>
>> On Tue, Feb 12, 2013 at 11:44 AM, John Bradley <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     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.
>> Hm?  Not following on “several ways”, I’d have thought that POSTing 
>> JSON is just POSTing JSON, must be missing something. -T
>>
>>
>>     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.
>>
>>>         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:
>>>
>>>         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 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.
>>>
>>>>     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:
>>>>
>>>>     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
>>>>
>>>>     From: [email-masked] <mailto:[email-masked]>
>>>>     [mailto:[email-masked]] On Behalf Of Justin Richer
>>>>     To: [email-masked] <mailto:[email-masked]>
>>>>     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:
>>>>
>>>>       - Allows for parallelism between the input to the endpoint
>>>>     and output from the endpoint, reducing possible translation
>>>>     errors between the two
>>>>
>>>>       - JSON has minimal character escaping required for most
>>>>     strings, forms require escaping for common characters such as
>>>>     space, slash, comma, etc.
>>>>
>>>>     Con:
>>>>
>>>>       - 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
>>>>

---

From: Pat Patterson <[email-masked]>
Date: Tue, 12 Feb 2013 12:04:19 -0800

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:

John B.

On 2013-02-12, at 4:48 PM, Tim Bray <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Feb 12, 2013 at 11:44 AM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
Nat and I hashed out the pro's and cons of JSON requests.

John B.

On 2013-02-12, at 4:32 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

 -- Justin

Nat Sakimura:

```

#!php

                                                            -- Mike

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [OAUTH-WG] Registration: JSON Encoded Input

Pro:

Con:

  -- Justin

OAuth mailing list

---

From: John Bradley <[email-masked]>
Date: Tue, 12 Feb 2013 17:07:46 -0300

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 <[email-masked]> 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
>

---

From: Brian Campbell <[email-masked]>
Date: Tue, 12 Feb 2013 13:09:10 -0700

+1 to what Pat and Justin said.

On Tue, Feb 12, 2013 at 12:59 PM, Justin Richer <[email-masked]> wrote:

> "application/json" and the HTTP Entity Body is the JSON document. No form
> posts or parameter names to be had here.
>
>  -- Justin
>
>
> 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.
>
> expert I just looked up code examples from several sources stack overflow
> and the like.
>
> 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.
>
>  Hm?  Not following on “several ways”, I’d have thought that POSTing JSON
> is just POSTing JSON, must be missing something. -T
>
>
>>
>> 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:
>>
>> I think that the positives of using JSON from the client's perspective
>> and the overall protocol design far outweigh the slightly increased
>> 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
>>
>>
>>
>> will certainly goes "???".
>>
>>
>>
>> before making the final decision.
>>
>>
>>
>>                                                             -- Mike
>>
>>
>>
>> JSON-encoded output from all operations.
>>
>>
>>
>> Pro:
>>
>> to (can?) be sent back to the server for update operations.
>>
>>
>>
>>
>>

---

From: Justin Richer <[email-masked]>
Date: Tue, 12 Feb 2013 15:16:49 -0500

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 <[email-masked] 
>>> 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.
>>>
>>>>     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.
>>>>
>>>>>         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:
>>>>>
>>>>>         matter of injecting the entity body as a string and
>>>>>         handing it to a parser (Gson in this case):
>>>>>
>>>>>         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
>>>>>         perspective and the overall protocol design far outweigh
>>>>>         the slightly increased implementation cost at the server.
>>>>>
>>>>>
>>>>>
>>>>>      -- Justin
>>>>>
>>>>>>     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
>>>>>>
>>>>>>
>>>>>>     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
>>>>>>

---

From: John Bradley <[email-masked]>
Date: Tue, 12 Feb 2013 17:35:42 -0300

I am OK with that language.

On 2013-02-12, at 5:16 PM, Justin Richer <[email-masked]> 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:
> 
> (Would have to be tweaked for the PUT/PATCH verbs but it's effectively the same.)
> 
> 
>  -- Justin
>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 13 Feb 2013 06:07:47 +0900

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 <[email-masked]>:
> *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 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.
> 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
>> 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.
>>
>> https://bitbucket.org/openid/connect/issue/747.  I think that Nat's recent
>> comment there bears repeating on this list:
>>
>>
>>
>> Nat Sakimura:
>>
>>
>>
>> body, then you would have to call a low level function in the form of:
>>
>>
>>
>>
>> ```
>>
>> #!php
>>
>>
>>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en