> -----Original Message----- > From: Marius Scurtescu [mailto:[email protected]] > Sent: Wednesday, May 19, 2010 5:43 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 Mon, May 17, 2010 at 11:26 PM, Eran Hammer-Lahav > <[email protected]> wrote: > > Now, this is useful. > > Yes, it is very useful. > > One minor correction, forms do support multi-value fields. Also, XML > supports name spaces. > > > > I think this raises a very good point. Unless we expect the server response > to always be just key/value pairs (regardless of the chosen serialization), we > cannot support multiple formats. If we decide on limiting to a flat key/value > pairs, the value of multiple formats is significantly reduced (but still > somewhat useful). > > Since we cannot have pure JSON I think we have to limit to flat key/value > pairs. Only direct responses are JSON, form/url encoded still has to be used: > - direct requests > - through browser requests > - through browser responses > - through browser fragment responses > > Considering the above, and also that: > - JSON will complicate library implementations because of dependencies > - clients using libraries are completely isolated from direct response formats > > I still don't see the point of using JSON. > > Even if a client implements everything from scratch and already uses JSON > (so no dependency problems) it still has to also support form-encoded as > well. Frameworks may help to some extent with query parameters (but if > that's the case, then most likely the framework can help with all form- > encoded cases), but there still are the other two cases. > > Can we still discuss this tomorrow?
I have a feeling it will come up :-) EHL > Marius > > > > > > EHL > > > >> -----Original Message----- > >> From: Yaron Goland [mailto:[email protected]] > >> Sent: Monday, May 17, 2010 2:58 PM > >> To: Kris Selden; Eran Hammer-Lahav > >> Cc: OAuth WG ([email protected]) > >> Subject: RE: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) > >> > >> My concerns with C are twofold. > >> > >> First, it's unclear to me how we will successfully reason about > >> OAuth's data model when the three proposed formats all have mutually > >> incompatible data models? > >> > >> | Forms | JSON | XML Nesting | NO | > >> YES | YES Multi-Value Fields | NO | YES| NO[1] Typing > >> | NO | YES | NO[2] Namespaces | NO | NO | NO > >> Objects | NO | YES | YES[3] > >> > >> [1] There is no formal definition in XML for multi-value fields > >> although one can build them using nested elements [2] XML does have > >> XML schema but most parsers don't natively support it [3] XML > >> actually has two different kinds of objects, elements and attributes. > >> > >> Will we dumb down JSON and XML to the point where they match Forms? > >> In other words, per Kris's mail, is OAuth's data model just name/value > pairs? > >> That can work but then it calls into question why the heck we > >> bothered supporting JSON or XML in the first place if we are > >> essentially just using them as Forms? It seems almost cruel to dangle > >> the richer data models of JSON and XML in front of people and then > >> pull them back with a restriction that we only do name/value pairs. > >> > >> Will we support JSON's data model? In which case do we intend to add > >> typing, arrays, etc. to forms and ban attributes and namespaces from > XML? > >> > >> Will we support XML's data model? In which case do we intend to add > >> name spacing and attributes to forms and JSON while banning all types > >> but string along with arrays in JSON? > >> > >> Or maybe we'll simply assert the existence of three different worlds > >> where every extension is defined in a completely different context > >> independently of each other? So every extension to OAuth has to, in > >> essence, be defined three separate times? > >> > >> Second, as a burden on server implementers we are requiring that they > >> possess and test three different parsers. I think this is > >> unnecessarily onerous and all but guaranteed to lead to > >> interoperability issues as server implementers will focus primarily > >> on the particular syntaxes they think will see the most use and give > >> less attention to other others. This is an inevitable trade off given the > difficulties of fully testing even basic formats. > >> > >> Thanks, > >> > >> Yaron > >> > >> > >> > -----Original Message----- > >> > From: [email protected] [mailto:[email protected]] On > >> > Behalf Of Kris Selden > >> > Sent: Friday, May 14, 2010 1:29 PM > >> > To: Eran Hammer-Lahav > >> > Cc: OAuth WG ([email protected]) > >> > Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) > >> > > >> > 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 > > > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
