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

Torsten Lodderstedt <torsten@lodderstedt.net> Mon, 10 May 2010 17:34 UTC

Return-Path: <torsten@lodderstedt.net>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F094E3A6BFB for <oauth@core3.amsl.com>; Mon, 10 May 2010 10:34:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.415
X-Spam-Level:
X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_50=0.001, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OEUB7K0PdIg for <oauth@core3.amsl.com>; Mon, 10 May 2010 10:34:17 -0700 (PDT)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) by core3.amsl.com (Postfix) with ESMTP id 5C8CC3A6C11 for <oauth@ietf.org>; Mon, 10 May 2010 10:29:09 -0700 (PDT)
Received: from p4fff0c18.dip.t-dialin.net ([79.255.12.24] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1OBWmm-0000h7-Gr; Mon, 10 May 2010 19:28:56 +0200
Message-ID: <4BE84252.80006@lodderstedt.net>
Date: Mon, 10 May 2010 19:28:50 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Eran Hammer-Lahav <eran@hueniverse.com>
References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Df-Sender: 141509
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 May 2010 17:34:18 -0000

Am 09.05.2010 23:06, schrieb Eran Hammer-Lahav:
> 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 prefer B, but I also could live with C.

If the WG chooses C, I would suggest to support all three formats for 
POST requests and responses. The default response format could be the 
format of the request sent by the client, additionally the client could 
indicate the desired format w/ a request parameter. That's propably a 
new option D?

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

Clearly B, I'm fine with using HTTP authentication schemes for client 
authentication only. This is cleaner (and thus easier) than also using 
BASIC/DIGEST authentication for user credentials in the "Username and 
Password Flow".

regards,
Torsten.

>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>