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
Vote for C, to be specified as: "Server MUST support JSON, form-encoded, and XML. Client MAY request any of the three, specified by a "format" parameter. Server will respond with JSON unless requested otherwise. Generic client libraries SHOULD support all three." Other formats (say, LISP s-expressions or Java Properties File format) can be specified through extensions that define the encoding and the value of the "format" parameter to match. Generation of valid data in these three formats is a much simpler problem than parsing, so I'd wager this isn't much of an imposition on the servers. Personally, I always found the form-encoded response a little strange, though I agree with the notion of "keep it as simple as possible". --- 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) Option A is absolutely still needed. I agree with Dick that OAuth should be self-contained wherever possible. But that said, I can see value in something like B as well for some deployments. I propose that we actually define a new flow for these cases, but instead of specifying Basic or Digest, we simply say that the client authenticates to the server using some out-of-band authentication method. It expected by the OAuth bits that the AS knows who the client represents by the time the request gets there. However the AS figures that out can effectively be outside the realm of OAuth, which gives us the ability to leverage Basic/Digest or other means (maybe even other OAuth tokens?) to accomplish this. -- Justin _______________________________________________ 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
