Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)

[David Waite <[e-mail]>]

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