Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)

[Yaron Goland <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf
> Of Kris Selden
> Sent: Friday, May 14, 2010 1:29 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG ([e-mail])
> 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:[e-mail]]
> >> Sent: Thursday, May 13, 2010 4:27 PM
> >> To: Eran Hammer-Lahav
> >> Cc: Yaron Goland; OAuth WG ([e-mail])
> >> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
> >>
> >> On Thu, May 13, 2010 at 5:14 PM, Eran Hammer-Lahav
> >> <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth