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
