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

[Marius Scurtescu <[e-mail]>]

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?

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
>