The only reason I've heard was interoperability but it is always stated as patently obvious without a given reasoning. My assumption is this is concern of OAuth 2 client library authors who don't want to depend on 3 parsing libraries but want to state they can inter-operate with any OAuth 2 provider.
I have a suggestion to mitigate the client library dependency issue, an argument for why C is more "interoperable" (even why the server should be not be required to support all 3 formats), comments on encoding, and percent encoding issues with OAuth 1. Basically, what OAuth providers return are key/value pairs and this discussion is really an issue of serialization. Instead of depending on libraries, client providers could have a interface for serialization that takes a mime type and string and returns a structure of key value pairs. That way if I've already chosen libyajl (which it is, even though it is UTF8 only) as my favorite JSON library, I can plug it in. Chances are your client library is going to still be more bloated than me just writing to a testable spec for the flows I need. Maybe even unusable simply because I'm using an API from an application on an evented server and your library uses blocking I/O for making the requests. On to why C is more interoperable and why as a consumer having it just be one format, doesn't help me unless I'm only using JSON APIs, it only helps the OAuth 2 client library developer. Let's say API A supports JSON, API B supports XML and API C supports both (as many APIs do, oh no the horror of the QA matrix). If I'm consuming API A, be nice if the OAuth 2 endpoint used JSON. If I'm consuming API B would be nice if the endpoint supported XML. If I needed both A and B, I need 2 parsers anyways, so what the endpoint did doesn't matter but I would pick JSON. If A and C I would want JSON. If B and C I would want XML. On the server side, would be nice if a service could match the OAuth endpoint format. I don't really see a need to support all 3 since in order to use my JSON only API you need a JSON parser anyway. There is little point to an API support multiple formats as many do if the OAuth endpoints require JSON only. If my service is just a REST storage API, accepting binary files like images, I just want whatever the simplest to parse in which case I would like form-encoded. I really don't see why people think that format is complicated, been in use a long time, there is lots of library support, and is more trivial to write your own parser than both JSON and XML. The problem with application/x-www-form-urlencoded that was complicated in OAuth 1, had to do with signature base strings because some characters could be optionally encoded and various libraries did this. Here we are talking about key/value pair serialization that HTML forms have been using for a long time. The percent encoding is of bytes and the bytes character set is defined by the charset in the response header. Would not matter if some characters were optionally percent encoded, they would still be decoded. While a lot of clients may not have an application/x-www-form-urlencoded parser, this problem is way overblown. Most have a percent-encoding decoder, needed just to parse URLs. Splitting on & and = then replacing + with space is trivial. This can easily be done in JavaScript, which is where I suspect some of the JSON only momentum is coming from. Not all JSON libraries handle the NULL position UTF detection in the RFC 4627, some just assume UTF8 only. I'm guessing supporting the other Unicode transfer encodings isn't all that popular since UTF8 is a superset of ASCII. Even though JSON maybe the way of the future, more SDKs like the iPhone come with a XML parser and you'd need to find a third party JSON parser or roll your own. As for the QA matrix, APIs that have handled multiple formats, have one output structure that is serialized to different formats which helps mitigate testing complexity. Test the one output, then test that that structure can be serialized to the supported formats. You may make that one structure JSON, then have a filter that can translate it to XML. For OAuth, I think it would increase interoperability if the output was considered key/value string pairs and multiple serialization formats were available, requested through the Accept header. Or I guess you can make it so OAuth is only for JSON APIs because JSON is the future. Though I seem to remember that being said about XML not long ago. Maybe I'm getting old. I guess I shouldn't use RSS and Atom feeds because they are so last year. I'm for option C plus relaxing the all 3 formats support to recommended but not required. On May 13, 2010, at 4:43 PM, Eran Hammer-Lahav wrote: > Can you give a reason why you are objecting to C. > > EHL > >> -----Original Message----- >> From: Robert Sayre [mailto:[email protected]] >> Sent: Thursday, May 13, 2010 4:27 PM >> To: Eran Hammer-Lahav >> Cc: Yaron Goland; OAuth WG ([email protected]) >> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) >> >> On Thu, May 13, 2010 at 5:14 PM, Eran Hammer-Lahav >> <[email protected]> wrote: >>> There is clearly no consensus for either A or B. There was mostly no >>> objection to C, and the reason given by most of those who objected was >> client complexity with the current proposal solves. >> >> My objection to C was that your examples were buggy. So, to be tediously >> explicit: >> >> B, then A. Not C. >> >> - Rob > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
