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