Every format requires some encoding, and if we limit the character set we will just be pushing the problem elsewhere (forcing servers to encode or define encoding for clients). Right now the assumption is that developers will implement the format (form-encoded) correctly, which will take care of any unexpected value. We can be more explicit about warning them no to assume anything about the values they receive.
Interop requires that servers always use the format defined by the spec, but may offer more formats per client request. This requires an extension parameter or a preference in the client configuration. I don't have a preference between JSON and form-encoded, but will point out that form-encoded is MUCH easier to parse without a library than JSON or XML. 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). 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
