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

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 9 May 2010 14:06:43 -0700

DEADLINE: 5/13

I would like to publish one more draft before our interim meeting in two weeks (5/20). Below are two open issues we have on the list. Please reply with your preference (or additional solutions) to each item. Issues with consensus will be incorporated into the next draft. Those without will be discussed at the meeting.

EHL

---

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

---

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)

---

From: David Recordon <[email-masked]>
Date: Sun, 9 May 2010 16:13:46 -0700

> C. JSON as default with form-encoded and XML available with an optional request parameter

It doesn't seem to make a lot of sense to require a client have a JSON
parser if the API they're interacting with is XML. And conversely it
doesn't make a lot of sense to require a client have a XML parser if
the API they're interacting with is JSON. Given the expressed desire
for JSON, I think that option C makes the most sense. Default is JSON
but the client can ask for XML or form-encoded instead.

> B. Client authenticated by using HTTP Basic (or other schemes supported by the server such as Digest)

I'd prefer that OAuth remain as self contained as possible. Thus A.

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Dick Hardt <[email-masked]>
Date: Sun, 9 May 2010 17:17:20 -0700

> C. JSON as default with form-encoded and XML available with an optional request parameter

I vote for B

I would argue that form-encoded data adds complexity with no obvious value.

*If* a JSON parser is not available, parsing the JSON that is returned is not that much different from parsing form-encoded data (remember that we are only using a very small subset of JSON)

More and more sites are returning both JSON and XML. Eventually everyone will see the light wrt. JSON ;-)

> B. Client authenticated by using HTTP Basic (or other schemes supported by the server such as Digest)

C. support both flows in the spec. An AS can decide what it wants to support. I would like to retain A as it may be challenging for some clients to use HTTP Basic, and easier for an AS to be always parsing parameters for each flow. I can see the advantages for some in using HTTP Basic.

-- Dick

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 10 May 2010 10:55:09 +1000

I vote for B

B doesn't stop specific services also offering form-encoded or XML variants -- particularly if that matches the rest of their API. A client app written specifically for such a service could still avoid JSON.
Choice B means a generic client needs to support JSON, which I feel isn't unreasonable.

>> C. support both flows in the spec.

I vote for B+.
The spec messages have no dependence on any specific client auth mechanism.
The spec says client apps capable of authenticating with a shared secret MUST support HTTP BASIC.

--
James Manger

---

From: DeWitt Clinton <[email-masked]>
Date: Sun, 9 May 2010 21:45:41 -0700

Response inline.

On Sun, May 9, 2010 at 5:17 PM, Dick Hardt <[email-masked]> wrote:

> > I would like to publish one more draft before our interim meeting in two
> weeks (5/20). Below are two open issues we have on the list. Please reply
> with your preference (or additional solutions) to each item. Issues with
> consensus will be incorporated into the next draft. Those without will be
> discussed at the meeting.
> >
> > EHL
> >
> > ---
> >
> > 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.
> >
> *If* a JSON parser is not available, parsing the JSON that is returned is
> not that much different from parsing form-encoded data (remember that we are
> only using a very small subset of JSON)
>

I strongly disagree here.  The subset of JSON returned is "all valid JSON",
pure and simple.  Indeed, this was exactly what I was concerned about
before.

The server is *no* obligation to return something that can be parsed more
easily than full JSON.  If we don't make that crystal clear, then I worry
about no end to unsafe encoding and escaping issues down the road.

If the decision is to go with either option B or C, please do it only via
language that says that clients and servers both MUST be RFC 4627 compliant.
 I.e., a full JSON parser, or no JSON at all.

 -DeWitt

> > 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.
> >
> C. support both flows in the spec. An AS can decide what it wants to
> support. I would like to retain A as it may be challenging for some clients
> to use HTTP Basic, and easier for an AS to be always parsing parameters for
> each flow. I can see the advantages for some in using HTTP Basic.
>
> -- Dick
>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 9 May 2010 22:25:16 -0700

No strong views on either one.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Eran Hammer-Lahav
> Sent: Sunday, May 09, 2010 2:07 PM
> To: OAuth WG ([email-masked])
> Subject: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
> 
> DEADLINE: 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.
> 

I think C is the right solution, but as someone who wrote his own JSON parser from scratch (which took a day and a lot of debugging), I can live with either option.

> supported by the server such as Digest)

B is the right approach (limited to client credentials), but it requires a lot more work than just moving the client credentials out to the header. To do it right, the entire token endpoint needs to become more restful, and I doubt it is something this group has an appetite for (except for James...). So A seems like an easier path to a final spec with B as a future cleanup (basically a new set of flows).

EHL

---

From: David Waite <[email-masked]>
Date: Mon, 10 May 2010 00:39:16 -0600

> C. JSON as default with form-encoded and XML available with an optional request parameter

I'm for A or B, but not so hot about C. Specifically (to throw my 2c into the pot):

- if form-encoded form or XML is an optional feature for servers to implement, then general-purpose client libraries cannot be built to expect them to be there. 
- for that reason, it feels the alternate encodings are not there to provide flexibility for client developers, but to allow implementations of OAuth to use other encodings in their clients (and support them in their servers) without the clients being considered out of spec compliance.
- as a security protocol, implementations might be concerned about reducing their overall vulnerability surface area. It is plausible that implementors on both sides would be more apt to not implement alternate protocols if it means importing and exposing three libraries for creating/consuming the encoded forms.

> B. Client authenticated by using HTTP Basic (or other schemes supported by the server such as Digest)

Prefer B.

- David Waite

---

From: Joseph Smarr <[email-masked]>
Date: Sun, 9 May 2010 23:57:59 -0700

> 1. Server Response Format

I vote for B, though I could live with C. (A would make me sad though)

We've had a healthy and reasonable debate about the trade-offs here, but I
think the main counterargument for requiring JSON support is that it's not
quite yet a "no-brainer" to have JSON support in all environments (e.g.
iPhone libraries currently would need to statically link in an available
JSON library), whereas the counterarguments for A are the well-documented
problems properly decoding url-encoded params from OAuth 1.0, plus the fact
that it's not a common response format, whereas JSON (and XML) are. Since I
think JSON will continue to increase in use for at least the next several
years, the pain associated with requiring JSON is likely to be  higher now
than it will be in the future, and it's already low enough that we've had
this debate about whether it's already acceptable or not-quite-yet. And JSON
has been proven to "just work" in terms of avoiding encoding/decoding
headaches in the wild, which for something like OAuth is really critical.

> 2. Client Authentication (in flows)

No strong opinion, but slight preference for A, perhaps with additional
profiles to follow that support HTTP Basic/Digest if it really does become a
problem in practice to do A. Main thing is that there *should* be some way
for a client to exchange raw username/password credentials for a token,
since this pattern is not going away anytime soon, and thus if we don't
standardize it, we'll wish we had.

On Sun, May 9, 2010 at 11:39 PM, David Waite
<[email-masked]>wrote:

> - if form-encoded form or XML is an optional feature for servers to
> implement, then general-purpose client libraries cannot be built to expect
> them to be there.
> - for that reason, it feels the alternate encodings are not there to
> provide flexibility for client developers, but to allow implementations of
> OAuth to use other encodings in their clients (and support them in their
> servers) without the clients being considered out of spec compliance.
> - as a security protocol, implementations might be concerned about reducing
> their overall vulnerability surface area. It is plausible that implementors
> on both sides would be more apt to not implement alternate protocols if it
> means importing and exposing three libraries for creating/consuming the
> encoded forms.
>
> ---
>
> 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.
>

---

From: Pid <[email-masked]>
Date: Mon, 10 May 2010 09:11:06 +0100

On 10/05/2010 07:57, Joseph Smarr wrote:
> We've had a healthy and reasonable debate about the trade-offs here, but
> I think the main counterargument for requiring JSON support is that it's
> not quite yet a "no-brainer" to have JSON support in all environments
> (e.g. iPhone libraries currently would need to statically link in an
> available JSON library), whereas the counterarguments for A are the
> well-documented problems properly decoding url-encoded params from OAuth
> 1.0, plus the fact that it's not a common response format, whereas JSON
> (and XML) are. Since I think JSON will continue to increase in use for
> at least the next several years, the pain associated with requiring JSON
> is likely to be  higher now than it will be in the future, and it's
> already low enough that we've had this debate about whether it's already
> acceptable or not-quite-yet. And JSON has been proven to "just work" in
> terms of avoiding encoding/decoding headaches in the wild, which for
> something like OAuth is really critical.

I don't believe this is an accurate summary.

I asked for someone in the pro-JSON camp to describe the technical
merits of that format over url encoded, but to date, there's no one who
has responded.

The options we've been offered seem contrived to support JSON, so
instead I propose a more logical alternative:

4. urlencoded as the default, with optional JSON and XML

p

> profiles to follow that support HTTP Basic/Digest if it really does
> become a problem in practice to do A. Main thing is that there *should*
> be some way for a client to exchange raw username/password credentials
> for a token, since this pattern is not going away anytime soon, and thus
> if we don't standardize it, we'll wish we had.
> 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>>     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.
>>
>     implement, then general-purpose client libraries cannot be built to
>     expect them to be there. 
>     provide flexibility for client developers, but to allow
>     implementations of OAuth to use other encodings in their clients
>     (and support them in their servers) without the clients being
>     considered out of spec compliance.
>     - as a security protocol, implementations might be concerned about
>     reducing their overall vulnerability surface area. It is plausible
>     that implementors on both sides would be more apt to not implement
>     alternate protocols if it means importing and exposing three
>     libraries for creating/consuming the encoded forms.
> 
>>     ---
>>
>>     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.
>>
>     [email-masked] <mailto:[email-masked]>

---

From: Mark Mcgloin <[email-masked]>
Date: Mon, 10 May 2010 10:15:29 +0100

> 1. Server Response Format

No Preference

> B. Client authenticated by using HTTP Basic (or other schemes supported
by the server such as Digest)

Prefer B

Mark

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 10 May 2010 09:06:25 -0400

Vote for C, to be specified as: "Server MUST support JSON, form-encoded, and XML. Client MAY request any of the three, specified by a "format" parameter. Server will respond with JSON unless requested otherwise. Generic client libraries SHOULD support all three." Other formats (say, LISP s-expressions or Java Properties File format) can be specified through extensions that define the encoding and the value of the "format" parameter to match. Generation of valid data in these three formats is a much simpler problem than parsing, so I'd wager this isn't much of an imposition on the servers. Personally, I always found the form-encoded response a little strange, though I agree with the notion of "keep it as simple as possible". 

---

Option A is absolutely still needed. I agree with Dick that OAuth should be self-contained wherever possible. But that said, I can see value in something like B as well for some deployments. I propose that we actually define a new flow for these cases, but instead of specifying Basic or Digest, we simply say that the client authenticates to the server using some out-of-band authentication method. It expected by the OAuth bits that the AS knows who the client represents by the time the request gets there. However the AS figures that out can effectively be outside the realm of OAuth, which gives us the ability to leverage Basic/Digest or other means (maybe even other OAuth tokens?) to accomplish this.

 -- Justin

---

From: Dick Hardt <[email-masked]>
Date: Mon, 10 May 2010 07:56:39 -0700

> I don't believe this is an accurate summary.

Are you saying the information is not accurate or not a complete summary?

> merits of that format over url encoded, but to date, there's no one who

per http://www.ietf.org/mail-archive/web/oauth/current/msg01992.html

client libraries exist to parse JSON responses
client libraries do NOT exist to parse url encoded responses

Implementations of both OAuth 1.0 and WRAP improperly decoded the responses.

> 
> The options we've been offered seem contrived to support JSON,

would you elaborate on why you think the options presented by the editor were contrived?

---

From: Mike Moore <[email-masked]>
Date: Mon, 10 May 2010 09:11:23 -0600

> C. JSON as default with form-encoded and XML available with an optional

A, with both JSON and XML support via an optional extension. I'd prefer to
keep the core spec as clean as possible, and I think form encoding does
that.

> the server such as Digest)

B, if possible. (I'm fairly convinced it is possible, but I'm not 100% sure
yet.)

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 10 May 2010 19:28:50 +0200

> C. JSON as default with form-encoded and XML available with an optional request parameter

I prefer B, but I also could live with C.

If the WG chooses C, I would suggest to support all three formats for 
POST requests and responses. The default response format could be the 
format of the request sent by the client, additionally the client could 
indicate the desired format w/ a request parameter. That's propably a 
new option D?

> B. Client authenticated by using HTTP Basic (or other schemes supported by the server such as Digest)

Clearly B, I'm fine with using HTTP authentication schemes for client 
authentication only. This is cleaner (and thus easier) than also using 
BASIC/DIGEST authentication for user credentials in the "Username and 
Password Flow".

regards,
Torsten.

---

From: Pid <[email-masked]>
Date: Mon, 10 May 2010 19:33:42 +0100

> per http://www.ietf.org/mail-archive/web/oauth/current/msg01992.html

Is that the right message?  There's not much in the way of positive
arguments for JSON in that one.

> client libraries exist to parse JSON responses

Meaning a dependency.

> client libraries do NOT exist to parse url encoded responses

There aren't libraries to perform that type of decoding because it's
trivial, (as you acknowledged).

> Also with reference to: "many developers have been caught just
splitting the parameters and forgetting to URL decode the token"

With respect, I think this is pretty close to a straw man.  It would be
just as easy to argue that developers will make a mess of parsing JSON.

Everyone seems to have, (in some cases grudgingly), agreed that it's
easier to decode/parse urlencoded data than JSON.

There are definitely occasions when using JSON for data description &
transmission is advantageous, I just don't think this is one of them.
It's a proverbial sledgehammer for a tiny OAuth nut.

There should be something positive to say about JSON that establishes
why it is a better format for this purpose.

> would you elaborate on why you think the options presented by the editor were contrived?

Sure.  Two of them offer JSON as the default, including the putative
'compromise' option.

JSON and XML add complexity, as the editor states.  IMHO it's odd
therefore not to select the least complex as the default, if multiple
formats are offered.

I appreciate that JSON is popular and there is a degree of devil's
advocacy to my position here, (as I've already said), but if it's not
possible to make a list of logical, positive statements in favour of the
technical merits of JSON over the original format choice then it
shouldn't be selected as the default.

p

---

From: Joseph Smarr <[email-masked]>
Date: Mon, 10 May 2010 15:35:24 -0700

Let me try to offer some of those "logical, positive statements in favour of
the technical merits of JSON over the original format choice" for those that
aren't familiar or haven't gleaned them from the thread thus far:

- unambiguous spec for encoding/decoding (including how to represent spaces
and unicode chars, both of which are common points of ambiguity in
url-encoding that lead to bugs, confusion, and lack of ability to use
built-in libraries, if available). For example, the OAuth PHP library does
the following: return str_replace('+', ' ', str_replace('%7E', '~',
rawurlencode($input)) -- yuck!

- easier to read the encoded format (because it has clear sentinel braces,
quoted attributes, and no url-encoding of parameters; only some backslashing
of reserved chars)

- widely available libraries with good track records in the wild, and
increasingly built in to many platforms

- extensible support for more representing more complex data structures in
the future, if needed

- simple enough that it's easy to understand, but just complex enough that
it's not too tempting to roll your own parser (which leads empirically to
better compliance due to use of common libraries)

- more likely to be recognized and understood by developers, since they've
seen it elsewhere in API response formats

I think that about covers it. Again, it's an objective fact that
url-encoding has caused confusion and bugs in OAuth 1.0 implementations, and
it's also an objective fact that JSON has had a very high "just works" rate
in the wild, to the point that it's the default API response format for many
widely used APIs from large providers targeting many platforms. So this is
not a choice based on "fashion", but based on trying to learn from history
to increase developer success and remove the opportunity for subtle bugs,
which was one of the major problems with OAuth 1.0a that prompted us to work
on OAuth 2.0 in the first place.

Thanks, js

---

From: Joseph Smarr <[email-masked]>
Date: Mon, 10 May 2010 15:38:13 -0700

Oh, one other quick benefit of JSON (kind of an extension of point 1 below):

- no ambiguous treatment of whitespace or newlines (this is a problem I've
observed multiple times while helping developers debug OAuth 1.0
implementations--since they just split on & and =, they often don't trim
extra whitespace or newlines that were returned by the server, leading to
those spaces/newlines being part of the parsed attribute values, which then
cause broken signatures and are very hard to debug, since the chars are
invisible when printed). Not a problem with JSON.

On Mon, May 10, 2010 at 3:35 PM, Joseph Smarr <[email-masked]> wrote:

> Let me try to offer some of those "logical, positive statements in favour
> of the technical merits of JSON over the original format choice" for those
> that aren't familiar or haven't gleaned them from the thread thus far:
>

---

From: Yaron Goland <[email-masked]>
Date: Mon, 10 May 2010 23:43:14 +0000

Please see inline

> C. JSON as default with form-encoded and XML available with an optional
[Yaron Goland]  I prefer A, can live with B and object to C.

> 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)
> 
[Yaron Goland] A is needed at a minimum because there are physical limitations to how many bytes can go into an authorization header.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 10 May 2010 19:43:48 -0700

> From: Yaron Goland [mailto:[email-masked]]
> Sent: Monday, May 10, 2010 4:43 PM

> > 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)
> >
> [Yaron Goland] A is needed at a minimum because there are physical
> limitations to how many bytes can go into an authorization header.

What?

Basic auth seems to be working just fine for the entire web...

EHL

---

From: Robert Sayre <[email-masked]>
Date: Mon, 10 May 2010 23:49:26 -0400

> Basic auth seems to be working just fine for the entire web...

I hadn't heard of implementations hitting a limitation on header size,
but Basic and Digest are both broken.

Basic leaves the input character encoding unspecified, so it doesn't
handle anything but ASCII in an interoperable way. OAuth
implementations will certainly screw this up too, but I suspect it
will be somewhat less buggy, since most people will probably just
guess it's supposed to be UTF-8.

The way Digest hashes credentials is incompatible with pretty much
every authentication database, so it never gets used, and it isn't
very secure anyway.

What /would/ be nice is an HTTP authentication scheme that used some
sort of PAKE... but don't gate the OAuth spec on that.

-- 

Robert Sayre

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 11 May 2010 07:46:57 +0200

> [Yaron Goland] A is needed at a minimum because there are physical limitations to how many bytes can go into an authorization header.

As far as I know, 4KB is the minimum size for headers that must be 
supported by user agents, which should suffice from my point of view. 
Moreover, other HTTP authentication mechanisms need much more than 4KB, 
For example, SPNEGO authentication headers can be up to 12392 bytes.

regards,
Torsten.

---

From: Pid <[email-masked]>
Date: Tue, 11 May 2010 09:15:15 +0100

On 10/05/2010 23:38, Joseph Smarr wrote:
> - no ambiguous treatment of whitespace or newlines (this is a problem
> I've observed multiple times while helping developers debug OAuth 1.0
> extra whitespace or newlines that were returned by the server, leading
> to those spaces/newlines being part of the parsed attribute values,
> which then cause broken signatures and are very hard to debug, since the
> chars are invisible when printed). Not a problem with JSON.
> 
>     Let me try to offer some of those "logical, positive statements in
>     favour of the technical merits of JSON over the original format
>     choice" for those that aren't familiar or haven't gleaned them from
>     the thread thus far:
> 
>     - unambiguous spec for encoding/decoding (including how to represent
>     spaces and unicode chars, both of which are common points of
>     ambiguity in url-encoding that lead to bugs, confusion, and lack of
>     ability to use built-in libraries, if available). For example, the
>     OAuth PHP library does the following: return str_replace('+', ' ',
>     str_replace('%7E', '~', rawurlencode($input)) -- yuck!
>
>     - easier to read the encoded format (because it has
>     clear sentinel braces, quoted attributes, and no url-encoding of
>     parameters; only some backslashing of reserved chars)
> 
>     - widely available libraries with good track records in the wild,
>     and increasingly built in to many platforms
> 
>     - extensible support for more representing more complex data
>     structures in the future, if needed
> 
>     - simple enough that it's easy to understand, but just complex
>     enough that it's not too tempting to roll your own parser (which
>     leads empirically to better compliance due to use of common libraries)
> 
>     - more likely to be recognized and understood by developers, since
>     they've seen it elsewhere in API response formats

Thanks for taking the trouble to respond in detail, the arguments in
favour of JSON are now much clearer.

>     url-encoding has caused confusion and bugs in OAuth 1.0
>     implementations, and it's also an objective fact that JSON has had a
>     very high "just works" rate in the wild, to the point that it's the
>     default API response format for many widely used APIs from large
>     providers targeting many platforms. So this is not a choice based on
>     "fashion", but based on trying to learn from history to increase
>     developer success and remove the opportunity for subtle bugs, which
>     was one of the major problems with OAuth 1.0a that prompted us to
>     work on OAuth 2.0 in the first place.

I take your point.

I'm slightly less convinced that this means that JSON is a single best
format, as much of the above could apply to XML too.  (Though I am aware
of the other JSON vs XML arguments, which favour JSON).

My preference is for multiple formats, but I'll leave this topic alone now.

cheers,

p

>     Thanks, js
> 
>     On Mon, May 10, 2010 at 11:33 AM, Pid <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         > per
>         http://www.ietf.org/mail-archive/web/oauth/current/msg01992.html
>

---

From: Yutaka OIWA <[email-masked]>
Date: Tue, 11 May 2010 19:13:11 +0900

> guess it's supposed to be UTF-8.

For the purpose of using Basic auth internally for OAuth, we could specify that
it should be treated as UTF-8 under OAuth's context. However, if we go that way
please make it an explicit rule in addition to RFC2617, not just as a people's
guess.

In Japan there is a long, non-ignorable history of using MS-Windows/MS-DOS local
encoding (Shift_JIS) for Basic auth.
And there is still many major implementations not using UTF-8 for this purpose.
I afraid that, if Basic is used with no explicit charset rule, clients may
use the core libraries of those and thus they will not assume UTF-8.

At least under my short experiment,
IE7 (ja) still assumes Shift_JIS for all of realm, user-name and password.
This may be depending on the locale of either the browser or the operating
system (I do not know which).
# "Authorization: Basic k/qWe4zqOpP6lnuM6g==",
# where both user/pass are the 3-char word "nihon-go" in Japanese characters.

FF3.5.9 (Windows, ja) assumes ISO-8859-1(?) for realm, and sends some
meaningless data for Japanese user-name/password (possibly each character
truncated to single-octet forcibly).
# "Authorization: Basic 5SyeOuUsng==". You can see there is only
# 7 octets (for 6 Japanese characters + a colon) after decoding BASE64.

-- 
Yutaka OIWA, Ph.D.                                       Research Scientist
                            Research Center for Information Security (RCIS)
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: Yutaka OIWA <[email-masked]>
Date: Tue, 11 May 2010 19:30:34 +0900

> sort of PAKE... but don't gate the OAuth spec on that.

FYI for people interested: my proposal for PAKE-based HTTP authentication
submitted as an Internet-Draft:
<http://tools.ietf.org/html/draft-oiwa-http-mutualauth-06>.

I designed it mainly considering Browser-based authentication, but
I do not limit its possible uses to Browsers.
Feedbacks from other possible usage area, if possible, is much appreciated.

---

From: Vivek Khurana <[email-masked]>
Date: Tue, 11 May 2010 16:03:51 +0530

> C. JSON as default with form-encoded and XML available with an optional request parameter

 Being someone who has been involved in development of general purpose
libraries, I will either A or B, which means either full JSON RFC 4267
compliance or Form-encoded only. Support of multiple format not only
increases development and maintenance effort, it increases the size of
library too. Since on the web, client might have to download the
library, keeping library size small is very important. If the standard
supports multiple formats, we might end up with libraries which will
support either JSON or XML or Form-encoded, thus leading to confusion
among developers.

> B. Client authenticated by using HTTP Basic (or other schemes supported by the server such as Digest)

 Either of them is acceptable, but if we go with B, the specification
should specify the charset to be used for Basic authentication.

regards
Vivek

-- 
The hidden harmony is better than the obvious!!

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 11 May 2010 17:53:35 +0200

> should specify the charset to be used for Basic authentication.
What about defining a new Authentication Scheme for the purpose of OAuth 
client authentication? Would this help to deal with such problems?

regards,
Torsten.

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 11 May 2010 14:04:44 -0700

> support either JSON or XML or Form-encoded, thus leading to confusion

For C, I don't think clients would be required to support both, only
servers must support both.

That being said, clients have to support A regardless (refresh token
request still require clients to use form-encoded for the request;
browser based requests require adding parameters to query string;
browser based responses require parsing the query string; the
User-Agent flow requires parsing query string from fragment). To me B
and C are the same when it comes to dependencies and complexity.

Marius

---

From: Yaron Goland <[email-masked]>
Date: Tue, 11 May 2010 23:23:51 +0000

Actually it's server side that's the problem. Many servers limit the size of the HTTP request headers they will accept. Apache 2.2, for example, uses the LimitRequestFieldSize Directive (http://httpd.apache.org/docs/2.2/mod/core.html). Its default size is 8190 bytes. IIS, I Believe, defaults to around 16K. But SAML assertions can easily clock in at 30 or 40k without even trying.

So as a practical matter we need a way to allow clients to assert their right to a token using the request body so as to not need to artificially limit the size of the token that is being submitted.

		Yaron

> From: Torsten Lodderstedt [mailto:[email-masked]]
> Sent: Monday, May 10, 2010 10:47 PM
> To: Yaron Goland
> Cc: Eran Hammer-Lahav; OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
> 
> >> parameters (current draft) B. Client authenticated by using HTTP
> >> Basic (or other schemes supported by the server such as Digest)
> >>
> >>
> As far as I know, 4KB is the minimum size for headers that must be supported
> by user agents, which should suffice from my point of view.
> Moreover, other HTTP authentication mechanisms need much more than
> 4KB, For example, SPNEGO authentication headers can be up to 12392 bytes.
> 
> regards,
> Torsten.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 11 May 2010 16:36:51 -0700

No one was suggesting putting the assertion in the header. Just the client credentials...

EHL

> Sent: Tuesday, May 11, 2010 4:24 PM
> To: Torsten Lodderstedt
> Subject: RE: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
> 
> Actually it's server side that's the problem. Many servers limit the size of the
> HTTP request headers they will accept. Apache 2.2, for example, uses the
> LimitRequestFieldSize Directive
> (http://httpd.apache.org/docs/2.2/mod/core.html). Its default size is 8190
> bytes. IIS, I Believe, defaults to around 16K. But SAML assertions can easily
> clock in at 30 or 40k without even trying.
> 
> So as a practical matter we need a way to allow clients to assert their right to
> a token using the request body so as to not need to artificially limit the size of
> the token that is being submitted.
> 
> 		Yaron
> 
> > >> that the client should be using existing HTTP authentication
> > >> schemes to accomplish that such as Basic.
> > >>

---

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

But in federation scenarios the client credentials are an assertion.

For example, Microsoft has a service called Dallas that lets entities purchase access to proprietary data feeds. A common scenario we run into with Dallas is that a company will purchase access to a feed for its employees. But the company doesn't want to have to individually specify to Dallas who can and cannot use the feed. Instead they want to agree on a key with Dallas and use that key to sign assertions sent to Dallas saying "let this person in". The OAuth flow would be:

1. A Dallas client of an employee of 'the company' issues a request to 'the company's ticket issuer asking for a security token it can send to Dallas.
2. 'The Company's ticket issuer generates a signed assertion stating that the bearer has the right to use 'The Company's subscription to a particular feed.
3. The Dallas client then forwards that security token to Dallas's ticket issuer asking for an access token to actually talk to Dallas's front end.
4. Dallas validates the security token (e.g. checks the signature, makes sure it has the right claims, etc.) and if successful then issues an access token to the Dallas client.

So in step 3 the client credential was a full-fledged security token of potentially arbitrary size.

BTW, just to make sure I'm properly following along, we are talking about section 3.9?

		Yaron

> From: Eran Hammer-Lahav [mailto:[email-masked]]
> Sent: Tuesday, May 11, 2010 4:37 PM
> To: Yaron Goland; Torsten Lodderstedt
> Cc: OAuth WG ([email-masked])
> > Actually it's server side that's the problem. Many servers limit the
> > size of the HTTP request headers they will accept. Apache 2.2, for
> > example, uses the LimitRequestFieldSize Directive
> > (http://httpd.apache.org/docs/2.2/mod/core.html). Its default size is
> > 8190 bytes. IIS, I Believe, defaults to around 16K. But SAML
> > assertions can easily clock in at 30 or 40k without even trying.
> >
> > So as a practical matter we need a way to allow clients to assert
> > their right to a token using the request body so as to not need to
> > artificially limit the size of the token that is being submitted.
> >
> > 		Yaron
> >
> > > >> How should the client authenticate when making token requests?
> > > >> The current draft defines special request parameters for sending

---

From: Greg Brail <[email-masked]>
Date: Thu, 13 May 2010 21:56:42 -0400

I'm sorry that I'm late on this but for what it's worth:

Server Response Format: I prefer A (form-encoded only). It's the simplest
solution that requires the least amount of client-side technology. JSON is
too complex a spec for simply encoding a set of flat key-value parameters
when where is already a well-established way to do this today in the HTTP
spec. My second preference is B (JSON only).

Client authentication: OAuth 1.0a was fine with authentication explicitly
expressed in the headers and I think 2.0 should stay the same.

More importantly, however -- I think that the spec should try to keep
things simple rather than offer multiple choice on many different aspects
of the implementation. The world is full of complicated specs and it's
always easier to keep adding options than to choose one of several
alternatives. Better to pick one that works well enough for everyone
rather than to keep adding choices to satisfy special cases that may or
may not be important in the future.

So in either of those cases, if Eran or whoemever is so empowered were to
choose, for example, "JSON only" and "HTTP basic only," then I would
support both choices over a set of options even though in both cases
neither is my first choice.

				greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Eran Hammer-Lahav
Sent: Sunday, May 09, 2010 5:07 PM
To: OAuth WG ([email-masked])
Subject: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)

DEADLINE: 5/13

EHL

---

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

---

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)

---

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

> Of Greg Brail
> Sent: Thursday, May 13, 2010 6:57 PM

>Eran or whoemever is so empowered were to choose

No one is empowered to choose. We need to keep at it until we reach consensus, but someone has to give.

EHL

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 14 May 2010 07:45:20 +0200

from my understanding, the assertion you explained in your scenario 
represent the authorization of end-users (not client applications) to 
access feeds. Thus I see them as a kind of user credentials and would 
send them as request parameter. Authorization headers will be used for 
client authentication only.

regards,
Torsten.

Am 13.05.2010 22:51, schrieb Yaron Goland:
>>>> 4KB, For example, SPNEGO authentication headers can be up to 12392
>>>>          
>>> bytes.
>>>        
>>>> regards,
>>>> Torsten.
>>>>
>>>>