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

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:yarong@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-bounces@ietf.org [mailto:oauth-bounces@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