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

[Eran Hammer-Lahav <[e-mail]>]

Now, this is useful.

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).

EHL

> -----Original Message-----
> From: Yaron Goland [mailto:[e-mail]]
> Sent: Monday, May 17, 2010 2:58 PM
> To: Kris Selden; Eran Hammer-Lahav
> Cc: OAuth WG ([e-mail])
> 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: [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