> 1. Server Response Format > > 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 B doesn't stop specific services also offering form-encoded or XML variants -- particularly if that matches the rest of their API. A client app written specifically for such a service could still avoid JSON. Choice B means a generic client needs to support JSON, which I feel isn't unreasonable. > 2. Client Authentication (in flows) > > 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. I vote for B+. The spec messages have no dependence on any specific client auth mechanism. The spec says client apps capable of authenticating with a shared secret MUST support HTTP BASIC. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
