Re: [OAUTH-WG] "access grant" terminology

Eran Hammer-Lahav <eran@hueniverse.com> Sun, 11 July 2010 03:03 UTC

Return-Path: <eran@hueniverse.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 2E24C3A6909 for <oauth@core3.amsl.com>; Sat, 10 Jul 2010 20:03:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.27
X-Spam-Level:
X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599]
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 wma60WKMCfnZ for <oauth@core3.amsl.com>; Sat, 10 Jul 2010 20:03:49 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 4DD8C3A68D9 for <oauth@ietf.org>; Sat, 10 Jul 2010 20:03:49 -0700 (PDT)
Received: (qmail 6705 invoked from network); 11 Jul 2010 03:03:54 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 Jul 2010 03:03:54 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 10 Jul 2010 20:03:54 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Brian Eaton <beaton@google.com>, OAuth WG <oauth@ietf.org>
Date: Sat, 10 Jul 2010 20:03:52 -0700
Thread-Topic: [OAUTH-WG] "access grant" terminology
Thread-Index: Acsgo1IqSaP1dBzARzCLBHb7zz8NFwAAl688
Message-ID: <C85E82A8.36FA5%eran@hueniverse.com>
In-Reply-To: <AANLkTikq4C9FYySiDmJqEBJIiYoYGxC9ZbpaPqHKgDgY@mail.gmail.com>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] "access grant" terminology
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: Sun, 11 Jul 2010 03:03:50 -0000

On 7/10/10 7:46 PM, "Brian Eaton" <beaton@google.com> wrote:

> The term "access grant" in the -09 spec is a bit odd.  Normally
> "access grant" or "permission grant" would refer to a specific policy
> decision made by a resource owner.
> 
> But that's not how the -09 spec uses the term.  The -09 spec refers to
> authorization codes and assertions as "access grants".  Again, that's
> weird.  Normally an assertion would be referred to as a "credential",
> not a grant.

Access grant is something that represents the decision made by the resource
owner. If the resource owner approves access, it is represented by a
authorization code. If the resource owner shares its password, it is
equivalent to unlimited access grant.

I coined the term based on common language, not on any existing terminology.
If there is a real conflict here, I am happy to consider another term, but
it doesn't sound like this is the case, or that the term is used against its
meaning.

> I think the term "authorization credential" might be a better fit than
> "access grant".
> 
> It certainly describes the purpose of the authorization code and the
> assertion.  And the term "credential" is normally used to describe
> things that need to be verified and protected.

I think authorization credential is going to confuse most readers. The spec
refers to credentials almost exclusively when dealing with identifier and
password (client, end-user), or as a general term for client authentication.
Authorization is specific to the end-user authorization endpoint and will be
confusing when used with assertions and other grant types.

So I'm open to other ideas but not this one.

Note that since this term impacts the name of the current 'grant_type'
parameter, changing it means code changes.

If anyone has a last minute idea please share (or if you are happy with the
current grant type). I expect it to be annoying to change once -10 is stable
for 4 weeks.

EHL