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
