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

Vivek Khurana <hiddenharmony@gmail.com> Tue, 11 May 2010 10:34 UTC

Return-Path: <hiddenharmony@gmail.com>
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 81C293A67F8 for <oauth@core3.amsl.com>; Tue, 11 May 2010 03:34:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
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 sH+YBOciKAS6 for <oauth@core3.amsl.com>; Tue, 11 May 2010 03:34:06 -0700 (PDT)
Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.211.173]) by core3.amsl.com (Postfix) with ESMTP id 8F0293A6783 for <oauth@ietf.org>; Tue, 11 May 2010 03:34:06 -0700 (PDT)
Received: by ywh3 with SMTP id 3so1670804ywh.31 for <oauth@ietf.org>; Tue, 11 May 2010 03:33:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7VIjy3uU5q8xJ6gzEkbjEJrjKYK6UTcaVV9sGHQ8WgQ=; b=Ts6CrpHfryuv8IjM8CiJTlLUmWDdsZm6vCxyV7NCPNbu6aZ3a0iwkKC01qsRmD53BI KXW4wkNv2dpPjrwEYPyeaCbIhGCLJpM3rG8NnuHVbf/7z6Qi1mUfe8qhyQLBjQxTt5WM i76fVYZfQb9dgrmuhOvV053d/gaT+tPZU1azE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mjwy3jEUMstsqwhAPAPS8gUj+dhac0yBwJSlldsxMrokcpmkuKGhJgM7mrZ202OoXo mthkA4x/iYRT7cjiHTV6RgED5+D+I3bHLzDcFPzVUW2xnf9BA1Foa/MXcletfNGuK8Sk pTn75l4FDx0wwG4G2c3WFt+1/QJGNRr2NtugA=
MIME-Version: 1.0
Received: by 10.100.246.9 with SMTP id t9mr1949071anh.3.1273574031553; Tue, 11 May 2010 03:33:51 -0700 (PDT)
Received: by 10.100.153.11 with HTTP; Tue, 11 May 2010 03:33:51 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <Acrvu4cfH3LKPgwRQV+7sW5YxUA1vA==> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Tue, 11 May 2010 16:03:51 +0530
Message-ID: <AANLkTik1NKqjCuquccqCMWV2RDQdqcdHpKnRQtwc7L4v@mail.gmail.com>
From: Vivek Khurana <hiddenharmony@gmail.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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: Tue, 11 May 2010 10:34:07 -0000

On Mon, May 10, 2010 at 2:36 AM, Eran Hammer-Lahav <eran@hueniverse.com> 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

 Being someone who has been involved in development of general purpose
libraries, I will either A or B, which means either full JSON RFC 4267
compliance or Form-encoded only. Support of multiple format not only
increases development and maintenance effort, it increases the size of
library too. Since on the web, client might have to download the
library, keeping library size small is very important. If the standard
supports multiple formats, we might end up with libraries which will
support either JSON or XML or Form-encoded, thus leading to confusion
among developers.

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

 Either of them is acceptable, but if we go with B, the specification
should specify the charset to be used for Basic authentication.

regards
Vivek

-- 
The hidden harmony is better than the obvious!!