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

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 13 May 2010 10:01:11 -0700

Thanks to those who participated!

Some conclusions:

> 1. Server Response Format
> 
> After extensive debate, we have a large group in favor of using JSON as the
> only response format (current draft). We also have a smaller group but with
> stronger feelings on the subject that JSON adds complexity with no obvious
> value.
> 
> A. Form-encoded only (original draft)
> B. JSON only (current draft)
> C. JSON as default with form-encoded and XML available with an optional
> request parameter

It seems like we have weak consensus to go with C where the server must support all three formats, and the client can use either one. This approach addresses most of the concerns around client complexity / size. Only one person strongly objected to C (without an explanation that can be addressed). Summing up the results was hard because many people had no strong preference between A and B but with each of the three options received about a third of the votes.

My guess is that if we held another vote asking if the spec should only support form-encoded or all three - all three will get most of the votes (and same if we made JSON the only option or all three). This is why C is really the only way to move forward at this point. We can revisit this later if implementation experience shows supporting all three in this manner is a problem.

I am going to add this to the specification as a point of reference for future discussions.

> 2. Client Authentication (in flows)
> 
> How should the client authenticate when making token requests? The
> current draft defines special request parameters for sending client
> credentials. Some have argued that this is not the correct way, and that the
> client should be using existing HTTP authentication schemes to accomplish
> that such as Basic.
> 
> A. Client authenticates by sending its credentials using special parameters
> (current draft) B. Client authenticated by using HTTP Basic (or other schemes
> supported by the server such as Digest)

Weak consensus to support both request parameters and HTTP Basic authentication (with other schemes as optional). I will add a new section to the draft allowing replacing the parameters with an HTTP authentication header. The flows text will remain the same.

EHL

---

From: Yaron Goland <[email-masked]>
Date: Thu, 13 May 2010 20:50:17 +0000

I went through and counted all the votes I could find in the mail archive (I have reproduced the results below). 8 people explicitly stated a preference for A or B (of those 4 explicitly stated they don't want C). Only 3 people voted for C as their first choice. 

Even if we bunch together people who voted for C and people who could live with C (but picked another option as their first choice) that is still only 5 who expressed any level of preference for C versus 6 people who didn't pick C at all.

Given these numbers I am at a loss to understand why you believe a consensus (weak or otherwise) exists for C. Could you please explain your reasoning?

	Thanks,

		Yaron

Vivek Khurana - A or B but not C
Yaron Goland - A then B but not C
David Waite - A or B but doesn't like C
Mike Moore - A (but not C)
Dick Hardt - B
James H Manger - B

Torsten Lodderstedt - B but could live with C
Joseph Smarr - B but could live with C

Justin P. Richer - C
Eran Hammer-Lahav - C
David Recordon - C

Mark Mcgloin - No preference

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Eran Hammer-Lahav
> Sent: Thursday, May 13, 2010 10:01 AM
> To: OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
> 
> > After extensive debate, we have a large group in favor of using JSON
> > as the only response format (current draft). We also have a smaller
> > group but with stronger feelings on the subject that JSON adds
> > complexity with no obvious value.
> >
> > C. JSON as default with form-encoded and XML available with an
> > optional request parameter
> 
> It seems like we have weak consensus to go with C where the server must
> support all three formats, and the client can use either one. This approach
> addresses most of the concerns around client complexity / size. Only one
> person strongly objected to C (without an explanation that can be
> addressed). Summing up the results was hard because many people had no
> strong preference between A and B but with each of the three options
> received about a third of the votes.
> 
> My guess is that if we held another vote asking if the spec should only
> support form-encoded or all three - all three will get most of the votes (and
> same if we made JSON the only option or all three). This is why C is really the
> only way to move forward at this point. We can revisit this later if
> implementation experience shows supporting all three in this manner is a
> problem.
> 
> > credentials. Some have argued that this is not the correct way, and
> > that the client should be using existing HTTP authentication schemes
> > to accomplish that such as Basic.
> >
> > A. Client authenticates by sending its credentials using special
> > parameters (current draft) B. Client authenticated by using HTTP Basic
> > (or other schemes supported by the server such as Digest)
> 
> Weak consensus to support both request parameters and HTTP Basic
> authentication (with other schemes as optional). I will add a new section to
> the draft allowing replacing the parameters with an HTTP authentication
> header. The flows text will remain the same.
> 
> EHL
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 13 May 2010 14:14:24 -0700

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.

Weak consensus means that the option has some support and little objection. If those who had something against C still think the solution doesn't address their reason for voting against it, they are free (as always) to express their objections again.

Unlike other features of the spec which we can keep out while discussing it, this one is critical and the spec is completely useless without. It is far better to have support for three options (with the option of moving two to an extension document with the format parameter) than to pick one and then change it.

I believe there was enough support for putting C in the draft. If you have a problem with that, feel free to ask the chairs for a different resolution.

EHL

> From: Yaron Goland [mailto:[email-masked]]
> Sent: Thursday, May 13, 2010 1:50 PM
> To: Eran Hammer-Lahav; OAuth WG ([email-masked])
> Subject: RE: Open Issues: Group Survey (respond by 5/13)
> 
> I went through and counted all the votes I could find in the mail archive (I
> have reproduced the results below). 8 people explicitly stated a preference
> for A or B (of those 4 explicitly stated they don't want C). Only 3 people voted
> for C as their first choice.
> 
> Even if we bunch together people who voted for C and people who could live
> with C (but picked another option as their first choice) that is still only 5 who
> expressed any level of preference for C versus 6 people who didn't pick C at
> all.
> 
> Given these numbers I am at a loss to understand why you believe a
> consensus (weak or otherwise) exists for C. Could you please explain your
> reasoning?
> 
> 	Thanks,
> 
> 		Yaron
> 
> Torsten Lodderstedt - B but could live with C Joseph Smarr - B but could live
> with C
> 
> Justin P. Richer - C
> Eran Hammer-Lahav - C
> David Recordon - C
> 
> > > A. Form-encoded only (original draft) B. JSON only (current draft)
> > It seems like we have weak consensus to go with C where the server
> > must support all three formats, and the client can use either one.
> > This approach addresses most of the concerns around client complexity
> > / size. Only one person strongly objected to C (without an explanation
> > that can be addressed). Summing up the results was hard because many
> > people had no strong preference between A and B but with each of the
> > three options received about a third of the votes.
> >
> > My guess is that if we held another vote asking if the spec should
> > only support form-encoded or all three - all three will get most of
> > the votes (and same if we made JSON the only option or all three).
> > This is why C is really the only way to move forward at this point. We
> > can revisit this later if implementation experience shows supporting
> > all three in this manner is a problem.
> >
> > > parameters (current draft) B. Client authenticated by using HTTP
> > > Basic (or other schemes supported by the server such as Digest)
> >
> > authentication (with other schemes as optional). I will add a new
> > section to the draft allowing replacing the parameters with an HTTP
> > authentication header. The flows text will remain the same.
> >
> > EHL
> >
> >

---

From: Robert Sayre <[email-masked]>
Date: Thu, 13 May 2010 19:26:36 -0400

On Thu, May 13, 2010 at 5:14 PM, Eran Hammer-Lahav <[email-masked]> 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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 13 May 2010 16:43:22 -0700

Can you give a reason why you are objecting to C.

EHL

> From: Robert Sayre [mailto:[email-masked]]
> Sent: Thursday, May 13, 2010 4:27 PM
> To: Eran Hammer-Lahav
> Cc: Yaron Goland; OAuth WG ([email-masked])
> > 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

---

From: Robert Sayre <[email-masked]>
Date: Thu, 13 May 2010 19:54:17 -0400

As I just wrote:
> My objection to C was that your examples were buggy.

I don't think servers or clients will get XML, JSON, and form-encoded
right without taking on a lot of 3rd party dependencies.

Even if those dependencies are ok, three serialization formats will
enlarge the QA matrix enough to hurt interoperability. The nature of
this objection seems pretty obvious.

- Rob

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: Kris Selden <[email-masked]>
Date: Fri, 14 May 2010 13:29:18 -0700

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.

---

From: Yaron Goland <[email-masked]>
Date: Mon, 17 May 2010 21:57:53 +0000

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

> Of Kris Selden
> Sent: Friday, May 14, 2010 1:29 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG ([email-masked])
> 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.
> 
> 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.
> 
> 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.
> 
> >> tediously

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 17 May 2010 23:26:45 -0700

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

> Sent: Monday, May 17, 2010 2:58 PM
> To: Kris Selden; Eran Hammer-Lahav
> Subject: RE: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
> 
> 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
> [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
> 
> 
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > >>> 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

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 19 May 2010 17:43:02 -0700

> 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 dec…

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

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 20 May 2010 11:33:09 +1000

Marius,

> Only direct responses are JSON, form/url encoded
> still has to be used:
> - direct requests

A better solution would be to change the last two (token info delivered in a callback URIs) so a single parameter (in the query or fragment) holds all the token info -- as a base64url-encoded JSON value.

That is more complicated if you are only delivering a single quantity (eg just an access_token). However, the difference diminishes as more and more features are added: expires_in, scope, sites, refresh_token, access_token_secret, realm, auth_scheme, whatever-comes-out-of-OpenID-Connect etc.

A single parameter for token info in callback URIs also reduces the risk of clashing with client-specific parameters in callback URIs as things are added in the future (eg the earlier debate about no oauth_ prefix).

It eliminates the need to force all semantics to fit in a flat key/value model. This can only get harder as features are added, or extensions are supported. The OpenID 2.0 approach of namespaces and parameter name prefixes is not pretty. JSON does not solve this, but its structure helps.

I wouldn't be surprised if, in some scenarios, the token info gets too big to fit in a URI. In that case even the user-agent flow will need to make a direct request to get the token info, which is more likely to be delivered as JSON. OpenID and SAML have found they need this (eg artefact flows).

Please consider this as an open issue for today's meeting: a single parameter holding a base64url-encode JSON value for packaging token info in a callback URI.

--
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 19 May 2010 22:10:50 -0700

> From: Marius Scurtescu [mailto:[email-masked]]
> Sent: Wednesday, May 19, 2010 5:43 PM
> To: Eran Hammer-Lahav
> > 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
> 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.
> 

I have a feeling it will come up :-)

EHL
 
> >> 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
> >> [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 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?
> >>
> >> 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
> >>
> >>
> >> > From: [email-masked] [mailto:[email-masked]] On
> >> > Behalf Of Kris Selden
> >> > 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.
> >> >
> >> > 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.
> >> >
> >> > 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
> >> > overblown. Most have a percent-encoding decoder, needed just to
> >> > parse URLs. Splitting on & and = then replacing + with space is trivial.
> >> > 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.
> >> >
> >> > 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.
> >> >
> >> > 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.
> >> > >>> 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

---

From: Evan Gilbert <[email-masked]>
Date: Thu, 20 May 2010 06:53:31 -0700

On Wed, May 19, 2010 at 6:33 PM, Manger, James H <
[email-masked]> wrote:

> A better solution would be to change the last two (token info delivered in
> a callback URIs) so a single parameter (in the query or fragment) holds all
> the token info -- as a base64url-encoded JSON value.
>

This is really problematic
- All implementers will have to properly parse form fields *and* parse JSON
(and Base64 decode to boot).
- JavaScript clients are likely to have XSS holes. If clients don't execute
something like this code (from
gadgets.json<http://www.google.com/codesearch/p?hl=en#MSH8LMSqi38/trunk/features/core/json.js&q=io.js%20package:%22http://svn.apache.org/repos/asf/incubator/shindig/%22&d=2>),
then they will be exposing themself to XSS.

  if (/^[\],:{}\s]*$/.test(text.replace(/\\["\\\/b-u]/g, '@').
 replace(/"[^"\\\n\r]*"|true|false|null|-?\d+(?:\.\d*)?(?:[eE][+\-]?\d+)?/g,
']').          replace(/(?:^|:|,)(?:\s*\[)+/g, ''))) {        return
eval('(' + text + ')');      }

- Developers will not be able to read source directly

I'm a fan of Base64 encoding JSON for the purposes of creating a
canonicalized string for signing. But this is not a good default transport.

>
> That is more complicated if you are only delivering a single quantity (eg
> just an access_token). However, the difference diminishes as more and more
> features are added: expires_in, scope, sites, refresh_token,
> access_token_secret, realm, auth_scheme,
> whatever-comes-out-of-OpenID-Connect etc.
>
> A single parameter for token info in callback URIs also reduces the risk of
> clashing with client-specific parameters in callback URIs as things are
> added in the future (eg the earlier debate about no oauth_ prefix).
>
> It eliminates the need to force all semantics to fit in a flat key/value
> model. This can only get harder as features are added, or extensions are
> supported. The OpenID 2.0 approach of namespaces and parameter name prefixes
> is not pretty. JSON does not solve this, but its structure helps.
>
> I wouldn't be surprised if, in some scenarios, the token info gets too big
> to fit in a URI. In that case even the user-agent flow will need to make a
> direct request to get the token info, which is more likely to be delivered
> as JSON. OpenID and SAML have found they need this (eg artefact flows).
>
>
> Please consider this as an open issue for today's meeting: a single
> parameter holding a base64url-encode JSON value for packaging token info in
> a callback URI.
>
> --
> James Manger

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 20 May 2010 09:11:46 -0700

> A better solution would be to change the last two (token info delivered in a callback URIs) so a single parameter (in the query or fragment) holds all the token info -- as a base64url-encoded JSON…

I don't think the last one can be changed, parsing JSON in JavaScript
can be tricky, Evan shows that in his reply. Also Evan points out that
decoding Base64 is yet one more thing, much more complicated than
percent decoding.

> A single parameter for token info in callback URIs also reduces the risk of clashing with client-specific parameters in callback URIs as things are added in the future (eg the earlier debate about…

If we could have JSON for all requests and responses, then maybe that
will help. But I guess that's too hackish. If not, then not sure.
Requests have just as many parameters as responses.

> I wouldn't be surprised if, in some scenarios, the token info gets too big to fit in a URI. In that case even the user-agent flow will need to make a direct request to get the token info, which is…

In this case the user-agent flow becomes the web server flow, which
does this already, no?

Marius

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 21 May 2010 12:33:31 +1000

Marius,

> In this case the user-agent flow becomes the web server flow, which

The hassle is that the client chooses type=user_agent at the start so the authz server cannot change this to a web_server flow later if the response doesn't fit in the redirect URI.

The spec should change this -- allowing the authz server to choose to respond with token details in the redirect URI or with token details available at a token URI.
When it is the server's choice, the client needs to handle both possibilities.

On the other issues:

> parsing JSON in JavaScript can be tricky

This is not true.
My understanding is that the current versions of Firefox, IE, Opera, Chrome, and Safari all support JSON.parse().
In older browsers you may need to use eval(), but the JSON RFC (and Evan's email) show how to make that safe with 3 lines of code; or use json2.js (available from json.org) that implements JSON.parse() for older browsers.

> decoding Base64 is yet one more thing, much more complicated than percent decoding.

Base64 is so widely used that I don't consider it unreasonable to require.
Base64url is less common, but just as simple.
I don't think it is more complicated that %-decoding.

--
James Manger