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

Brian Eaton <beaton@google.com> Sat, 17 July 2010 19:41 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 CEBA43A69CB for <oauth@core3.amsl.com>; Sat, 17 Jul 2010 12:41:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.827
X-Spam-Level:
X-Spam-Status: No, score=-105.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 qm0RYV4o6YqX for <oauth@core3.amsl.com>; Sat, 17 Jul 2010 12:41:43 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 96C6E3A684F for <oauth@ietf.org>; Sat, 17 Jul 2010 12:41:42 -0700 (PDT)
Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id o6HJfsuP028779 for <oauth@ietf.org>; Sat, 17 Jul 2010 12:41:54 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279395715; bh=n4F6ibW23BuR4uGCWB2GuhCOncw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=P85CIWd6IPDFk+q8NkrrAAUNlYBbpRT9jRCOg4S5WnmK8HMOgkGZ7XlfQaadvgRYq 91fbG/Ju0XU3RwVElHBdg==
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:content-transfer-encoding:x-system-of-record; b=IzSGicfzxBh9inmiDdByn5y4vfTRkYmTTg8pNHcd+xplYv2abg33YlyTeMummp3GQ h7Ak8265bx2ij4GZKr5sA==
Received: from pxi20 (pxi20.prod.google.com [10.243.27.20]) by kpbe20.cbf.corp.google.com with ESMTP id o6HJfruk000806 for <oauth@ietf.org>; Sat, 17 Jul 2010 12:41:53 -0700
Received: by pxi20 with SMTP id 20so1396140pxi.3 for <oauth@ietf.org>; Sat, 17 Jul 2010 12:41:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.134.13 with SMTP id h13mr3830257wfd.119.1279395713225; Sat, 17 Jul 2010 12:41:53 -0700 (PDT)
Received: by 10.142.193.19 with HTTP; Sat, 17 Jul 2010 12:41:53 -0700 (PDT)
In-Reply-To: <C8674977.374B1%eran@hueniverse.com>
References: <AA83846D-1817-4B51-9F3E-CA9DD91862D6@facebook.com> <C8674977.374B1%eran@hueniverse.com>
Date: Sat, 17 Jul 2010 12:41:53 -0700
Message-ID: <AANLkTinHP9fH8vFfu1L4HgF7nDtXp6-Kq2Orvb8gLQQL@mail.gmail.com>
From: Brian Eaton <beaton@google.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
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:41:44 -0000

On Sat, Jul 17, 2010 at 11:50 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> The use case is pretty simple: the user uses the server and approves a third
> party site access to their data directly (i.e. They are not sent to the
> server from the client, but just use the server). The third part then uses
> their client credentials to request a token. That token has access to
> whatever data was authorized previously by any user on the server side. This
> is still a client-only flow, but the grant isn’t just for the client’s own
> resources, but to whatever has been authorized to that client.

Let's pretend we're talking about a human user instead of an API client.

The user enters their username, and their password.

They get a token that can be used to access resources.  Those might
not be their resources; they might be viewing a friend's calendar, for
example.

Would you say calling that a "user password" profile would be
misleading?  Because the grant isn't just for the user's own
resources?

My guess is not.

What we are doing with the client password profile is exactly
equivalent.  Except instead of a human user, we're dealing with an API
client.

Cheers,
Brian