> 1. Server Response Format I vote for B, though I could live with C. (A would make me sad though)
We've had a healthy and reasonable debate about the trade-offs here, but I think the main counterargument for requiring JSON support is that it's not quite yet a "no-brainer" to have JSON support in all environments (e.g. iPhone libraries currently would need to statically link in an available JSON library), whereas the counterarguments for A are the well-documented problems properly decoding url-encoded params from OAuth 1.0, plus the fact that it's not a common response format, whereas JSON (and XML) are. Since I think JSON will continue to increase in use for at least the next several years, the pain associated with requiring JSON is likely to be higher now than it will be in the future, and it's already low enough that we've had this debate about whether it's already acceptable or not-quite-yet. And JSON has been proven to "just work" in terms of avoiding encoding/decoding headaches in the wild, which for something like OAuth is really critical. > 2. Client Authentication (in flows) No strong opinion, but slight preference for A, perhaps with additional profiles to follow that support HTTP Basic/Digest if it really does become a problem in practice to do A. Main thing is that there *should* be some way for a client to exchange raw username/password credentials for a token, since this pattern is not going away anytime soon, and thus if we don't standardize it, we'll wish we had. On Sun, May 9, 2010 at 11:39 PM, David Waite <da...@alkaline-solutions.com>wrote: > > On May 9, 2010, at 3:06 PM, Eran Hammer-Lahav wrote: > > > 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'm for A or B, but not so hot about C. Specifically (to throw my 2c into > the pot): > > - if form-encoded form or XML is an optional feature for servers to > implement, then general-purpose client libraries cannot be built to expect > them to be there. > - for that reason, it feels the alternate encodings are not there to > provide flexibility for client developers, but to allow implementations of > OAuth to use other encodings in their clients (and support them in their > servers) without the clients being considered out of spec compliance. > - as a security protocol, implementations might be concerned about reducing > their overall vulnerability surface area. It is plausible that implementors > on both sides would be more apt to not implement alternate protocols if it > means importing and exposing three libraries for creating/consuming the > encoded forms. > > --- > > 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) > > > Prefer B. > > - David Waite > > _______________________________________________ > 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
