I agree we need JSON formatting for all the currently url-encoded responses,
but not for the requests, since that stuff will be handled by normal web
servers. That's all you were saying right? We still need a proposed format
for the JSON, but my strawman would just be take all the key/value pairs
returned currently and encode them as one flat JSON object with those same
exact key/value pairs.
So, using the example in 3.5.2.2, instead of the response body being:
access_token=SlAV32hkKG&expires_in=3600&refresh_token=8xLOxBtZp8
It would be:
{ "access_token": "SlAV32hkKG", "expires_in": "3600", "refresh_token":
"8xLOxBtZp8" }
Any reason that wouldn't work?
Thanks, js
On Wed, Apr 28, 2010 at 3:03 PM, Torsten Lodderstedt <
[email protected]> wrote:
> no one interested any longer in this topic? I would like to prepare a
> proposal, but I need some feedback.
>
> regards,
> Torsten.
>
> Am 24.04.2010 09:44, schrieb Torsten Lodderstedt:
>
> Am 20.04.2010 17:10, schrieb Eran Hammer-Lahav:
>>
>>> There seems to be support for this idea with some concerns about
>>> complexity. Someone needs to propose text for this including defining the
>>> request parameter and schema of the various reply formats.
>>>
>>>
>> I would like to prepare some text. Beforehand, I would like to discuss
>> some ideas in order to come to a rough consensous.
>>
>> Basically, I would suggest to only consider cases where the implementation
>> platform does not directly support URI query parameter decoding. From my
>> point of view, this are all HTTP responses a client will need to process.
>> All request parameters, e.g. redirect back to the web server in the web
>> server flow, will still be delivered as "application/x-www-form-urlencoded"
>> only, since the web container automatically prepares this parameters for
>> easy access in the web application.
>>
>> I have compiled a list of candidates:
>>
>> 3.5.1. User-Agent Flow
>> 3.5.1.1. Client Requests Authorization
>>
>> fragement of the redirect URL. Change this to base64 encoded XML/JSON,
>> desired format as request parameter
>>
>> 3.5.2. Web Server Flow
>> 3.5.2.2. Client Requests Access Token
>>
>> response formats: application/x-www-form-urlencoded, application/xml, or
>> application/json
>> desired format as request parameter
>> response mime type indicates response format
>>
>> 3.5.3. Device Flow
>> 3.5.3.1. Client Requests Authorization
>>
>> proposal see 3.5.2.2. Client Requests Access Token
>>
>> 3.5.3.2. Client Requests Access Token
>>
>> proposal see 3.5.2.2. Client Requests Access Token
>>
>> 3.6.1. Username and Password Flow
>> 3.6.1.1. Client Requests Access Token
>>
>> proposal see 3.5.2.2. Client Requests Access Token
>>
>> 3.7.1. Client Credentials Flow
>> 3.7.1.1. Client Requests Access Token
>>
>> proposal see 3.5.2.2. Client Requests Access Token
>>
>> 3.7.2. Assertion Flow
>> 3.7.2.1. Client Requests Access Token
>>
>> proposal see 3.5.2.2. Client Requests Access Token
>>
>> 4. Refreshing an Access Token
>>
>> proposal see 3.5.2.2. Client Requests Access Token
>>
>> Any comments?
>>
>> regards,
>> Torsten.
>>
>>> EHL
>>>
>>> -----Original Message-----
>>>> From: Torsten Lodderstedt [mailto:[email protected]]
>>>> Sent: Monday, April 19, 2010 4:48 AM
>>>> To: Eran Hammer-Lahav
>>>> Cc: Dick Hardt; OAuth WG
>>>> Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
>>>>
>>>>
>>>> We can also offer both and define a client request parameter (as long
>>>>> as the server is required to make at least one format available).
>>>>>
>>>> +1 on this
>>>>
>>>> regards,
>>>> Torsten.
>>>>
>>>> EHL
>>>>>
>>>>> -----Original Message-----
>>>>>> From: [email protected] [mailto:[email protected]] On
>>>>>> Behalf Of Dick Hardt
>>>>>> Sent: Sunday, April 18, 2010 9:30 PM
>>>>>> To: OAuth WG
>>>>>> Subject: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
>>>>>>
>>>>>> The AS token endpoint response is encoded as application/x-www-form-
>>>>>> urlencoded
>>>>>>
>>>>>> While this reuses a well known and understood encoding standard, it
>>>>>> is uncommon for a client to receive a message encoded like this. Most
>>>>>> server responses are encoded as XML or JSON. Libraries are NOT
>>>>>> reedily available to parse application/x-www-form-urlencoded results
>>>>>> as this is something that is typically done in the web servers
>>>>>> framework. While parsing the name value pairs and URL un-encoding
>>>>>> them is not hard, many developers have been caught just splitting the
>>>>>>
>>>>> parameters and forgetting to URL decode the token.
>>>>
>>>>> Since the token is opaque and may contain characters that are
>>>>>> escaped, it is a difficult bug to detect.
>>>>>>
>>>>>> Potential options:
>>>>>>
>>>>>> 1) Do nothing, developers should read the specs and do the right
>>>>>> thing.
>>>>>>
>>>>>> 2) Require that all parameters are URL safe so that there is no
>>>>>> encoding issue.
>>>>>>
>>>>>> 3) Return results as JSON, and recommend that parameters be URL safe.
>>>>>>
>>>>>> -- Dick
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [email protected]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [email protected]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>
>>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
