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

[David Recordon]

On Sun, May 9, 2010 at 2:06 PM, Eran Hammer-Lahav  wrote:
> 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

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.


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

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


> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Dick Hardt]

On 2010-05-09, at 2:06 PM, Eran Hammer-Lahav wrote:

> 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

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

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

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


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Manger, James H]

> 1. Server Response Format
> 
> 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

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.


> 2. Client Authentication (in flows)
> 
> 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)

>> 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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[DeWitt Clinton]

Response inline.

On Sun, May 9, 2010 at 5:17 PM, Dick Hardt  wrote:

>
> On 2010-05-09, at 2:06 PM, Eran Hammer-Lahav wrote:
>
> > 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
>
> 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)
>

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


> More and more sites are returning both JSON and XML. Eventually everyone
> will see the light wrt. JSON ;-)
>
> >
> > ---
> >
> > 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)
>
> 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
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Eran Hammer-Lahav]

No strong views on either one.

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

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.

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

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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[David Waite]

On May 9, 2010, at 3:06 PM, Eran Hammer-Lahav wrote:
> 
> 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

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.

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

Prefer B.

- David Waite___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Smarr]

> 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
wrote:

>
> On May 9, 2010, at 3:06 PM, Eran Hammer-Lahav wrote:
>
>
> 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
>
>
> 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.
>
> ---
>
> 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)
>
>
> Prefer B.
>
> - David Waite
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Pid]

On 10/05/2010 07:57, Joseph Smarr wrote:
>> 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.

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




>> 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
> mailto:da...@alkaline-solutions.com>> wrote:
> 
> 
> On May 9, 2010, at 3:06 PM, Eran Hammer-Lahav wrote:
>>
>> 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
> 
> 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.
> 
>> ---
>>
>> 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)
> 
> Prefer B.
> 
> - David Waite
> 
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth




signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mark Mcgloin]

> 1. Server Response Format

No Preference

> 2. Client Authentication (in flows)

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

Prefer B

Mark

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Richer, Justin P.]

1. Server Response Format
  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

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




---

2. Client Authentication (in flows)
   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)


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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Dick Hardt]

On 2010-05-10, at 1:11 AM, Pid wrote:

> On 10/05/2010 07:57, Joseph Smarr wrote:
>>> 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.
> 
> I don't believe this is an accurate summary.

Are you saying the information is not accurate or not a complete 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.

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?
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Moore]

On Sun, May 9, 2010 at 3:06 PM, Eran Hammer-Lahav wrote:

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

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.


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

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


> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

Am 09.05.2010 23:06, schrieb Eran Hammer-Lahav:

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
   


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?



---

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)
   


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.



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
   



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Pid]

On 10/05/2010 15:56, Dick Hardt wrote:
> 
> On 2010-05-10, at 1:11 AM, Pid wrote:
> 
>> On 10/05/2010 07:57, Joseph Smarr wrote:
 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.
>>
>> I don't believe this is an accurate summary.
> 
> Are you saying the information is not accurate or not a complete 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.
> 
> 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).


> Implementations of both OAuth 1.0 and WRAP improperly decoded the responses.
> 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.


>> 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?

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






signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Smarr]

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

On Mon, May 10, 2010 at 11:33 AM, Pid  wrote:

> On 10/05/2010 15:56, Dick Hardt wrote:
> >
> > On 2010-05-10, at 1:11 AM, Pid wrote:
> >
> >> On 10/05/2010 07:57, Joseph Smarr wrote:
>  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.
> >>
> >> I don't believe this is an accurate summary.
> >
> > Are you saying the information is not accurate or not a complete 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.
> >
> > 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).
>
>
> > Implementations of both OAuth 1.0 and WRAP improperly decoded the
> responses.
> > 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.
>
>
> >> The options we've been offered seem contrived to support JSON,
> >
> > would you elaborate on why

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

[Joseph Smarr]

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  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:
>
> - 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
>
> On Mon, May 10, 2010 at 11:33 AM, Pid  wrote:
>
>> On 10/05/2010 15:56, Dick Hardt wrote:
>> >
>> > On 2010-05-10, at 1:11 AM, Pid wrote:
>> >
>> >> On 10/05/2010 07:57, Joseph Smarr wrote:
>>  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.
>> >>
>> >> I don't believe this is an accurate summary.
>> >
>> > Are you saying the information is not accurate or not a complete
>> 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.
>> >
>> > 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).
>>
>>
>> > Implementations of both OAuth 1.0 and WRAP improperly decoded the
>> responses.
>> > Also with reference to: "many developers have been caught just
>> splitting th

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

[Yaron Goland]

Please see inline

> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Sunday, May 09, 2010 2:07 PM
> To: OAuth WG (oauth@ietf.org)
> Subject: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
> 
> 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
> 
[Yaron Goland]  I prefer A, can live with B and object to C.

> ---
> 
> 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)
> 
[Yaron Goland] A is needed at a minimum because there are physical limitations 
to how many bytes can go into an authorization header.
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Eran Hammer-Lahav]

> -Original Message-
> From: Yaron Goland [mailto:yar...@microsoft.com]
> Sent: Monday, May 10, 2010 4:43 PM


> > 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)
> >
> [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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Robert Sayre]

On Mon, May 10, 2010 at 10:43 PM, Eran Hammer-Lahav  wrote:
>
> What?
>
> 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."
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

Am 11.05.2010 01:43, schrieb Yaron Goland:



---

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)

 

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


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
   



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Pid]

On 10/05/2010 23:38, Joseph Smarr wrote:
> 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.
> 
> 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.

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

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  > wrote:
> 
> On 10/05/2010 15:56, Dick Hardt wrote:
> >
> > On 2010-05-10, at 1:11 AM, Pid wrote:
> >
> >> On 10/05/2010 07:57, Joseph Smarr wrote:
>  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.
> >>
> >> I don't believe this is an accurate summary.
> 

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

[Yutaka OIWA]

On 2010/05/11 12:49, Robert Sayre wrote:

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

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: , 
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Yutaka OIWA]

On 2010/05/11 12:49, Robert Sayre wrote:
> What /would/ be nice is an HTTP authentication scheme that used some
> 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:
.

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.

-- 
Yutaka OIWA, Ph.D.   Research Scientist
Research Center for Information Security (RCIS)
National Institute of Advanced Industrial Science and Technology (AIST)
  Mail addresses: , 
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Vivek Khurana]

On Mon, May 10, 2010 at 2:36 AM, Eran Hammer-Lahav  wrote:
> 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

 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.

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

 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!!
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

Am 11.05.2010 12:33, schrieb Vivek Khurana:

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)
 

  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

   
What about defining a new Authentication Scheme for the purpose of OAuth 
client authentication? Would this help to deal with such problems?


regards,
Torsten.



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Marius Scurtescu]

On Tue, May 11, 2010 at 3:33 AM, Vivek Khurana  wrote:
> On Mon, May 10, 2010 at 2:36 AM, Eran Hammer-Lahav  
> wrote:
>> 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
>
>  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.

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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Yaron Goland]

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

> -Original Message-
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Monday, May 10, 2010 10:47 PM
> To: Yaron Goland
> Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
> 
> Am 11.05.2010 01:43, schrieb Yaron Goland:
> >
> >> ---
> >>
> >> 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)
> >>
> >>
> > [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.
> 
> >> ___
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> 
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Eran Hammer-Lahav]

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

EHL

> -Original Message-
> From: Yaron Goland [mailto:yar...@microsoft.com]
> Sent: Tuesday, May 11, 2010 4:24 PM
> To: Torsten Lodderstedt
> Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
> 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
> 
> > -Original Message-
> > From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> > Sent: Monday, May 10, 2010 10:47 PM
> > To: Yaron Goland
> > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
> > Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
> >
> > Am 11.05.2010 01:43, schrieb Yaron Goland:
> > >
> > >> ---
> > >>
> > >> 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)
> > >>
> > >>
> > > [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.
> >
> > >> ___
> > >> OAuth mailing list
> > >> OAuth@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/oauth
> > >>
> > > ___
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> > >
> >
> >

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Eran Hammer-Lahav]

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
 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Yaron Goland]

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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Thursday, May 13, 2010 10:01 AM
> To: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
> 
> 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
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Yaron Goland]

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


> -Original Message-
> From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
> Sent: Tuesday, May 11, 2010 4:37 PM
> To: Yaron Goland; Torsten Lodderstedt
> Cc: OAuth WG (oauth@ietf.org)
> Subject: RE: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
> 
> No one was suggesting putting the assertion in the header. Just the client
> credentials...
> 
> EHL
> 
> > -Original Message-
> > From: Yaron Goland [mailto:yar...@microsoft.com]
> > Sent: Tuesday, May 11, 2010 4:24 PM
> > To: Torsten Lodderstedt
> > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
> > 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
> >
> > > -----Original Message-----
> > > From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> > > Sent: Monday, May 10, 2010 10:47 PM
> > > To: Yaron Goland
> > > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
> > > Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
> > >
> > > Am 11.05.2010 01:43, schrieb Yaron Goland:
> > > >
> > > >> ---
> > > >>
> > > >> 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)
> > > >>
> > > >>
> > > > [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.
> > >
> > > >> ___
> > > >> OAuth mailing list
> > > >> OAuth@ietf.org
> > > >> https://www.ietf.org/mailman/listinfo/oauth
> > > >>
> > > > ___
> > > > OAuth mailing list
> > > > OAuth@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > > >
> > >
> > >
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Eran Hammer-Lahav]

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

> -Original Message-
> From: Yaron Goland [mailto:yar...@microsoft.com]
> Sent: Thursday, May 13, 2010 1:50 PM
> To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
> 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
> 
> 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> > Of Eran Hammer-Lahav
> > Sent: Thursday, May 13, 2010 10:01 AM
> > To: OAuth WG (oauth@ietf.org)
> > Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
> >
> > 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.
> 

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

[Robert Sayre]

On Thu, May 13, 2010 at 5:14 PM, Eran Hammer-Lahav  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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Eran Hammer-Lahav]

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

EHL

> -Original Message-
> From: Robert Sayre [mailto:say...@gmail.com]
> Sent: Thursday, May 13, 2010 4:27 PM
> To: Eran Hammer-Lahav
> Cc: Yaron Goland; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
> 
> On Thu, May 13, 2010 at 5:14 PM, Eran Hammer-Lahav
>  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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Robert Sayre]

On Thu, May 13, 2010 at 7:43 PM, Eran Hammer-Lahav  wrote:
> Can you give a reason why you are objecting to C.
>

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."
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Greg Brail]

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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Eran Hammer-Lahav
Sent: Sunday, May 09, 2010 5:07 PM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)

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)


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Eran Hammer-Lahav]

> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> 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
 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

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:

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


   

-Original Message-
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Tuesday, May 11, 2010 4:37 PM
To: Yaron Goland; Torsten Lodderstedt
Cc: OAuth WG (oauth@ietf.org)
Subject: RE: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)

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

EHL

 

-Original Message-
From: Yaron Goland [mailto:yar...@microsoft.com]
Sent: Tuesday, May 11, 2010 4:24 PM
To: Torsten Lodderstedt
Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
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

   

-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Monday, May 10, 2010 10:47 PM
To: Yaron Goland
Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)

Am 11.05.2010 01:43, schrieb Yaron Goland:
 
   

---

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)


 

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

 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

   


 
 
   



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Kris Selden]

-Original Message-
>> From: Robert Sayre [mailto:say...@gmail.com]
>> Sent: Thursday, May 13, 2010 4:27 PM
>> To: Eran Hammer-Lahav
>> Cc: Yaron Goland; OAuth WG (oauth@ietf.org)
>> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
>> 
>> On Thu, May 13, 2010 at 5:14 PM, Eran Hammer-Lahav
>>  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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Yaron Goland]

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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Kris Selden
> Sent: Friday, May 14, 2010 1:29 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG (oauth@ietf.org)
> 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 AP

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

[Eran Hammer-Lahav]

Now, this is useful.

I think this raises a very good point. Unless we expect the server response to 
always be just key/value pairs (regardless of the chosen serialization), we 
cannot support multiple formats. If we decide on limiting to a flat key/value 
pairs, the value of multiple formats is significantly reduced (but still 
somewhat useful).

EHL

> -Original Message-
> From: Yaron Goland [mailto:yar...@microsoft.com]
> Sent: Monday, May 17, 2010 2:58 PM
> To: Kris Selden; Eran Hammer-Lahav
> Cc: OAuth WG (oauth@ietf.org)
> 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> > Of Kris Selden
> > Sent: Friday, May 14, 2010 1:29 PM
> > To: Eran Hammer-Lahav
> > Cc: OAuth WG (oauth@ietf.org)
> > 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 

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

[Marius Scurtescu]

On Mon, May 17, 2010 at 11:26 PM, Eran Hammer-Lahav  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:yar...@microsoft.com]
>> Sent: Monday, May 17, 2010 2:58 PM
>> To: Kris Selden; Eran Hammer-Lahav
>> Cc: OAuth WG (oauth@ietf.org)
>> 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> > Of Kris Selden
>> > Sent: Friday, May 14, 2010 1:29 PM
>> > To: Eran Hammer-Lahav
>> > Cc: OAuth WG (oauth@ietf.org)
>> > Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
>> >
>> > The only reason I've heard was interoperability but it is a

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

[Manger, James H]

Marius,

> 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

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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Eran Hammer-Lahav]

> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Wednesday, May 19, 2010 5:43 PM
> To: Eran Hammer-Lahav
> Cc: Yaron Goland; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
> 
> On Mon, May 17, 2010 at 11:26 PM, Eran Hammer-Lahav
>  wrote:
> > Now, this is useful.
> 
> Yes, it is very useful.
> 
> One minor correction, forms do support multi-value fields. Also, XML
> supports name spaces.
> 
> 
> > I think this raises a very good point. Unless we expect the server response
> to always be just key/value pairs (regardless of the chosen serialization), we
> cannot support multiple formats. If we decide on limiting to a flat key/value
> pairs, the value of multiple formats is significantly reduced (but still
> somewhat useful).
> 
> Since we cannot have pure JSON I think we have to limit to flat key/value
> pairs. Only direct responses are JSON, form/url encoded still has to be used:
> - direct requests
> - through browser requests
> - through browser responses
> - through browser fragment responses
> 
> Considering the above, and also that:
> - JSON will complicate library implementations because of dependencies
> - clients using libraries are completely isolated from direct response formats
> 
> I still don't see the point of using JSON.
> 
> Even if a client implements everything from scratch and already uses JSON
> (so no dependency problems) it still has to also support form-encoded as
> well. Frameworks may help to some extent with query parameters (but if
> that's the case, then most likely the framework can help with all form-
> encoded cases), but there still are the other two cases.
> 
> Can we still discuss this tomorrow?

I have a feeling it will come up :-)

EHL
 
> Marius
> 
> 
> >
> > EHL
> >
> >> -Original Message-
> >> From: Yaron Goland [mailto:yar...@microsoft.com]
> >> Sent: Monday, May 17, 2010 2:58 PM
> >> To: Kris Selden; Eran Hammer-Lahav
> >> Cc: OAuth WG (oauth@ietf.org)
> >> 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 

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

[Evan Gilbert]

On Wed, May 19, 2010 at 6:33 PM, Manger, James H <
james.h.man...@team.telstra.com> wrote:

> Marius,
>
> > 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
>
> 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),
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
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Marius Scurtescu]

On Wed, May 19, 2010 at 6:33 PM, Manger, James H
 wrote:
> Marius,
>
>> 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
>
> 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.

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.


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

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.


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

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


Marius

>
>
> 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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Manger, James H]

Marius,


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

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

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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth