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

[Dick Hardt <[e-mail]>]

On 2010-05-09, at 2:06 PM, Eran Hammer-Lahav wrote:

> 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 vote for B

I would argue that form-encoded data adds complexity with no obvious value.

*If* a JSON parser is not available, parsing the JSON that is returned is not that much different from parsing form-encoded data (remember that we are only using a very small subset of JSON)

More and more sites are returning both JSON and XML. Eventually everyone will see the light wrt. JSON ;-)

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

C. support both flows in the spec. An AS can decide what it wants to support. I would like to retain A as it may be challenging for some clients to use HTTP Basic, and easier for an AS to be always parsing parameters for each flow. I can see the advantages for some in using HTTP Basic.

-- Dick