Re: [OAUTH-WG] Issue: Scope parameter

Marius Scurtescu <mscurtescu@google.com> Thu, 15 April 2010 19:22 UTC

Return-Path: <mscurtescu@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 C47373A6AC2 for <oauth@core3.amsl.com>; Thu, 15 Apr 2010 12:22:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.927
X-Spam-Level:
X-Spam-Status: No, score=-105.927 tagged_above=-999 required=5 tests=[AWL=0.050, 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 GmXUE+bY8ymq for <oauth@core3.amsl.com>; Thu, 15 Apr 2010 12:22:34 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C1FEA3A67FC for <oauth@ietf.org>; Thu, 15 Apr 2010 12:21:18 -0700 (PDT)
Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id o3FJLANN019848 for <oauth@ietf.org>; Thu, 15 Apr 2010 12:21:10 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1271359271; bh=zlycNn6jMU69FE4ntUtoxmtYcrU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=KtBn+3A0Ungu6OFBe2qiw7J7Zfpu1/BGQFmg0Kipufl2+1J3bnTnSEqnvGloInSdF beX1XhKXt+DOiWxscMjWw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=g4Du/OCtVpsTTb/PO4ghW9uvaROOdEyLloi29jCJ8daBb32I5h8CYDmOLraFPPV71 wkn/00Tiy0Oba4UoxHVtw==
Received: from pvc22 (pvc22.prod.google.com [10.241.209.150]) by kpbe19.cbf.corp.google.com with ESMTP id o3FJKn1l030929 for <oauth@ietf.org>; Thu, 15 Apr 2010 12:21:09 -0700
Received: by pvc22 with SMTP id 22so1138604pvc.11 for <oauth@ietf.org>; Thu, 15 Apr 2010 12:21:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.141.107.2 with HTTP; Thu, 15 Apr 2010 12:20:49 -0700 (PDT)
In-Reply-To: <C7ECB1F7.32357%eran@hueniverse.com>
References: <C7ECB1F7.32357%eran@hueniverse.com>
From: Marius Scurtescu <mscurtescu@google.com>
Date: Thu, 15 Apr 2010 12:20:49 -0700
Received: by 10.141.187.9 with SMTP id o9mr900720rvp.211.1271359269288; Thu, 15 Apr 2010 12:21:09 -0700 (PDT)
Message-ID: <m2n74caaad21004151220qac3a829em2dc17f1c93b6efa1@mail.gmail.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: text/plain; charset="ISO-8859-1"
X-System-Of-Record: true
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Issue: Scope parameter
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: Thu, 15 Apr 2010 19:22:37 -0000

I still have not seen any arguments why scope structure is needed for
interop. Client and server side libraries do not need to understand
the scope, they just pass it around. Client and server code do need to
understand the scope, but we are not dealing with that.

Yes, a scope parameter does not buy much, it only prevents each authz
server from inventing their own custom parameter.

Marius



On Thu, Apr 15, 2010 at 12:07 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> WRAP includes a loosely defined scope parameter which allows for
> vendor-specific (and non-interoperable) use cases. This was requested by
> many working group members to be included in OAuth 2.0 with the argument
> that while it doesn't help interop, it makes using clients easier.
>
> The problem with a general purpose scope parameter that is completely
> undefined in structure is that it hurts interop more than it helps. It
> creates an expectation that values can be used across services, and it
> cannot be used without another spec defining its content and structure. Such
> as spec can simply define its own parameter.
>
> In addition, it is not clear what belongs in scope (list of resources,
> access type, duration of access, right to share data, rights to
> re-delegate).
>
> The rules should be that if a parameter cannot be used without another
> documentation, it should be defined in that other document.
>
> Proposal: Request proposals for a scope parameter definition that improve
> interop. Otherwise, keep the parameter out of the core spec.
>
> EHL
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>