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

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:torsten@lodderstedt.net]
>>> 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: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] 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
>>>>> 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