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

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

> -----Original Message-----
> From: Marius Scurtescu [mailto:[e-mail]]
> Sent: Wednesday, May 19, 2010 5:43 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 Mon, May 17, 2010 at 11:26 PM, Eran Hammer-Lahav
> <[e-mail]> 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:[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
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >