IETF Logo Mail Archive

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

Brian Eaton <beaton@google.com> Tue, 13 July 2010 20:43 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 5345A3A67F4 for <oauth@core3.amsl.com>; Tue, 13 Jul 2010 13:43:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.826
X-Spam-Level:
X-Spam-Status: No, score=-101.826 tagged_above=-999 required=5 tests=[AWL=0.151, 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 VCsD-zdAhrlC for <oauth@core3.amsl.com>; Tue, 13 Jul 2010 13:43: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 3AB243A69A3 for <oauth@ietf.org>; Tue, 13 Jul 2010 13:43:10 -0700 (PDT)
Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id o6DKhIGa027212 for <oauth@ietf.org>; Tue, 13 Jul 2010 13:43:18 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279053798; bh=zTI4xyS0IcULYV/u6T7rskFqtzQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=brZ5+ejk4/7lFJJK4KKZpBVcOVUsFUnB5JxqXoD5icclo22RWcUyr45XxFVYK7S2U k/XGoih07DBQ3o7exBV9A==
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=Nd4C3RYgI/PMHXSmoGpA9CfttI2nEY2ZT9oCzk6Z+6PrGx9PJ4ADHb3eeCfJrriot WV3Ik4souSddLi/2QedYw==
Received: from pxi18 (pxi18.prod.google.com [10.243.27.18]) by hpaq3.eem.corp.google.com with ESMTP id o6DKhHKj021968 for <oauth@ietf.org>; Tue, 13 Jul 2010 13:43:17 -0700
Received: by pxi18 with SMTP id 18so2446006pxi.4 for <oauth@ietf.org>; Tue, 13 Jul 2010 13:43:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.157.6 with SMTP id f6mr7210267wfe.181.1279053796689; Tue, 13 Jul 2010 13:43:16 -0700 (PDT)
Received: by 10.142.193.19 with HTTP; Tue, 13 Jul 2010 13:43:16 -0700 (PDT)
In-Reply-To: <4C3CCF58.6010102@alcatel-lucent.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> <AANLkTimCOZs-VlhX-pyhUUa5rdIsnUEDgSNZX5MprQRs@mail.gmail.com> <4C3CCF58.6010102@alcatel-lucent.com>
Date: Tue, 13 Jul 2010 13:43:16 -0700
Message-ID: <AANLkTimjvjcTEbR-sC4q8G8oC3vh5k4mPOMI71XD3tf4@mail.gmail.com>
From: Brian Eaton <beaton@google.com>
To: igor.faynberg@alcatel-lucent.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:43:12 -0000

On Tue, Jul 13, 2010 at 1:40 PM, Igor Faynberg
<igor.faynberg@alcatel-lucent.com> wrote:
> In this case, the term "capability" MUST be defined up front. The word
> "capability" seems to carry a much broader meaning than password...

It has a standard definition we can reference.  From
http://www.ietf.org/rfc/rfc2828.txt

   $ capability
      (I) A token, usually an unforgeable data value (sometimes called a
      "ticket") that gives the bearer or holder the right to access a
      system resource. Possession of the token is accepted by a system
      as proof that the holder has been authorized to access the
      resource named or indicated by the token. (See: access control
      list, credential, digital certificate.)

      (C) This concept can be implemented as a digital certificate.
      (See: attribute certificate.)

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