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
