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:
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>> 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
>>>>>
>>>>>
>>>>
>>>
>>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
