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
