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

[Eran Hammer-Lahav <[e-mail]>]

No strong views on either one.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Eran Hammer-Lahav
> Sent: Sunday, May 09, 2010 2:07 PM
> To: OAuth WG ([e-mail])
> Subject: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
> 
> DEADLINE: 5/13
> 
> I would like to publish one more draft before our interim meeting in two
> weeks (5/20). Below are two open issues we have on the list. Please reply
> with your preference (or additional solutions) to each item. Issues with
> consensus will be incorporated into the next draft. Those without will be
> discussed at the meeting.
> 
> EHL
> 
> ---
> 
> 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 think C is the right solution, but as someone who wrote his own JSON parser from scratch (which took a day and a lot of debugging), I can live with either option.

> ---
> 
> 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)

B is the right approach (limited to client credentials), but it requires a lot more work than just moving the client credentials out to the header. To do it right, the entire token endpoint needs to become more restful, and I doubt it is something this group has an appetite for (except for James...). So A seems like an easier path to a final spec with B as a future cleanup (basically a new set of flows).

EHL