Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON

[Torsten Lodderstedt <[e-mail]>]

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:[e-mail]]
>> 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: [e-mail] [mailto:[e-mail]] 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>          
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>        
>>
>>
>>      
>