On 10/05/2010 07:57, Joseph Smarr wrote: >> 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.
I don't believe this is an accurate summary. I asked for someone in the pro-JSON camp to describe the technical merits of that format over url encoded, but to date, there's no one who has responded. The options we've been offered seem contrived to support JSON, so instead I propose a more logical alternative: 4. urlencoded as the default, with optional JSON and XML p >> 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 > <[email protected] <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
