Re: [OAUTH-WG] "shared symmetric secret"

Brian Eaton <beaton@google.com> Tue, 13 July 2010 20:35 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 914A23A6A73 for <oauth@core3.amsl.com>; Tue, 13 Jul 2010 13:35:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.789
X-Spam-Level:
X-Spam-Status: No, score=-101.789 tagged_above=-999 required=5 tests=[AWL=0.188, 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 O07t94fl5OYA for <oauth@core3.amsl.com>; Tue, 13 Jul 2010 13:35:11 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 537133A69A5 for <oauth@ietf.org>; Tue, 13 Jul 2010 13:35:10 -0700 (PDT)
Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id o6DKZIib016862 for <oauth@ietf.org>; Tue, 13 Jul 2010 13:35:18 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279053318; bh=6j1WHW9BoyiIgqRaU7iGEEdZ7h8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=IthIdj+dW5v5sUMSyO4/ZdKfN+ZjGB5Lk+HsLSD0rcnDM/Z+M4ZMtsxzur5wYqJr2 7JoLoOAlpMU5qq/HhDA7w==
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=gksefoAM3Pf7Jj71ukcBl+9H0g4d2FjsQ4n286oqh+nCImiM3fmqpFcpZepl7XM+m ab1oA0U7FPrn12JPufTWw==
Received: from pvg2 (pvg2.prod.google.com [10.241.210.130]) by kpbe12.cbf.corp.google.com with ESMTP id o6DKZGuX000861 for <oauth@ietf.org>; Tue, 13 Jul 2010 13:35:16 -0700
Received: by pvg2 with SMTP id 2so3559712pvg.26 for <oauth@ietf.org>; Tue, 13 Jul 2010 13:35:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.211.6 with SMTP id j6mr19434345wfg.165.1279053316264; Tue, 13 Jul 2010 13:35:16 -0700 (PDT)
Received: by 10.142.193.19 with HTTP; Tue, 13 Jul 2010 13:35:16 -0700 (PDT)
In-Reply-To: <AANLkTikd1o-pS24OcaREB98ePUdJDcythnO-1WwV_L2c@mail.gmail.com>
References: <97BD2762-F147-4774-9557-AD478338B348@jkemp.net> <C861F32E.371BA%eran@hueniverse.com> <D24C564ACEAD16459EF2526E1D7D605D0C9E7F3576@IMCMBX3.MITRE.ORG> <AANLkTimKH9OL3zq91lTCK8_EuCefcifPfqslb24zytv7@mail.gmail.com> <93F20A70-3133-4C5A-BE15-9C85F1D42787@jkemp.net> <AANLkTikd1o-pS24OcaREB98ePUdJDcythnO-1WwV_L2c@mail.gmail.com>
Date: Tue, 13 Jul 2010 13:35:16 -0700
Message-ID: <AANLkTimCOZs-VlhX-pyhUUa5rdIsnUEDgSNZX5MprQRs@mail.gmail.com>
From: Brian Eaton <beaton@google.com>
To: Blaine Cook <romeda@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
X-System-Of-Record: true
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] "shared symmetric secret"
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, 13 Jul 2010 20:35:13 -0000

On Tue, Jul 13, 2010 at 1:06 PM, Blaine Cook <romeda@gmail.com> wrote:
> Don't leak it, and treat it as though it were a
> password", then we avoid having to explain (embarrassingly) that the
> "capability" actually meant something like "password".

For the initiated, that's what "capability" means.

How about this language

"Access tokens are bearer authentication tokens, such as passwords or
capabilities."

I'd encourage the use of the word "capability" because a lot of the
use cases that OAuth 2 enables over OAuth 1 involve using the token
like a capability, sharing it across multiple components to convey
authorization.