IETF Logo Mail Archive

Re: [OAUTH-WG] Change grant_type="none" to something less confusing

Brian Eaton <beaton@google.com> Sat, 17 July 2010 19:49 UTC

Return-Path: <beaton@google.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 77EE23A69C9 for <oauth@core3.amsl.com>; Sat, 17 Jul 2010 12:49:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.957
X-Spam-Level:
X-Spam-Status: No, score=-101.957 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100]
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 LUa2W-5mztp7 for <oauth@core3.amsl.com>; Sat, 17 Jul 2010 12:49:03 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 7DF743A69C6 for <oauth@ietf.org>; Sat, 17 Jul 2010 12:49:02 -0700 (PDT)
Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id o6HJnEN6024287 for <oauth@ietf.org>; Sat, 17 Jul 2010 12:49:14 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279396154; bh=ANxl54tZ4awkOzzei5YdI/ntKWM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=KGeoJ36zchmNDGWW8119e5wA5o3S5QOwkOkCRVvBzk6J7kTR62w0Y2BoLyLp8LKn9 SdZbdRNOEx1OS2ijOMJjg==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=yoaMHufRN4FmRbyat2urs967JNcpc3nLbQgjJD/al8FaClJjd3Ar5/g3rnpIBkaEm oSsalyeiBd1opXeKBJu6g==
Received: from pxi19 (pxi19.prod.google.com [10.243.27.19]) by wpaz37.hot.corp.google.com with ESMTP id o6HJnCGB024557 for <oauth@ietf.org>; Sat, 17 Jul 2010 12:49:13 -0700
Received: by pxi19 with SMTP id 19so2004808pxi.40 for <oauth@ietf.org>; Sat, 17 Jul 2010 12:49:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.232.21 with SMTP id e21mr3915308wfh.92.1279396152426; Sat, 17 Jul 2010 12:49:12 -0700 (PDT)
Received: by 10.142.193.19 with HTTP; Sat, 17 Jul 2010 12:49:12 -0700 (PDT)
In-Reply-To: <AA83846D-1817-4B51-9F3E-CA9DD91862D6@facebook.com>
References: <1279297826.11628.61.camel@localhost.localdomain> <AANLkTinRE0My8GRTVrBM9cwyCWgrpeYQzul3YBp_Z-8A@mail.gmail.com> <AANLkTim_GpxKx2G6FQN9TGwMYxnRv4N7pOo7Yo3g2s6c@mail.gmail.com> <AANLkTinDwGDYq4IYA9BKJakdEMnR8FbruTqR4i_zS88p@mail.gmail.com> <AANLkTinbbIJ03UPFWibPJC569ckseU33Tnyf-1BYRGj2@mail.gmail.com> <AANLkTimfdpugQSgTMUPtLy-xOMIB-dJ4E8IMzB5EwU6R@mail.gmail.com> <AANLkTintmqhY1PY51h4DcXEI0r3FQmIB92pP3vykPQrw@mail.gmail.com> <3AF1FD6F-2178-42ED-833C-D93C534DDA8A@hueniverse.com> <AANLkTindn2UOcqWz410_UnyAORe58_XpXQKcy5sMt_pF@mail.gmail.com> <AA83846D-1817-4B51-9F3E-CA9DD91862D6@facebook.com>
Date: Sat, 17 Jul 2010 12:49:12 -0700
Message-ID: <AANLkTinrz-KCjHpeUCnDpJhRGRCHoY_nl3fKgNgivoxi@mail.gmail.com>
From: Brian Eaton <beaton@google.com>
To: Luke Shepard <lshepard@facebook.com>
Content-Type: text/plain; charset="ISO-8859-1"
X-System-Of-Record: true
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Change grant_type="none" to something less confusing
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: Sat, 17 Jul 2010 19:49:06 -0000

On Sat, Jul 17, 2010 at 8:52 AM, Luke Shepard <lshepard@facebook.com> wrote:
> As far as consistency, it is just a little weird to call it "client password" in one
> part of the spec, when it's defined as "client secret" elsewhere.

Agreed, we could be more consistent.  The value we're talking about is
the same in all of the flows, no sense in switching terminology.

I prefer client_password, because "password", for me, evokes all the
right kinds of security concerns.  Password storage, encryption on the
wire, etc...

I'm less happy with client_secret, though I can certainly live with
it.  My main concern with client_secret is that people might confuse
it with a signing secret.  The value is not used for signing.  If we
are going to have flows where clients have secrets that are used for
cryptographic authentication, then I would want to call those "keys"
instead.

> How about just "client_only" ?

That would be fine by me.

v2.35.0 | Report a Bug | By Email | System Status