Response inline. On Sun, May 9, 2010 at 5:17 PM, Dick Hardt <dick.ha...@gmail.com> 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
