Re: [OAUTH-WG] Scope - Coming to a Consensus
Torsten Lodderstedt <torsten@lodderstedt.net> Sat, 01 May 2010 06:01 UTC
Return-Path: <torsten@lodderstedt.net>
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 185D83A6A5E for <oauth@core3.amsl.com>; Fri, 30 Apr 2010 23:01:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.595
X-Spam-Level:
X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[AWL=-0.946, BAYES_50=0.001, HELO_EQ_DE=0.35]
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 Gncp7-4oVRDV for <oauth@core3.amsl.com>; Fri, 30 Apr 2010 23:01:04 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by core3.amsl.com (Postfix) with ESMTP id A38E93A6A08 for <oauth@ietf.org>; Fri, 30 Apr 2010 23:01:01 -0700 (PDT)
Received: from p4fff1ad4.dip.t-dialin.net ([79.255.26.212] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1O85kr-0007aU-TO; Sat, 01 May 2010 08:00:45 +0200
Message-ID: <4BDBC389.2090709@lodderstedt.net>
Date: Sat, 01 May 2010 08:00:41 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Marius Scurtescu <mscurtescu@google.com>
References: <90C41DD21FB7C64BB94121FBBC2E723439321772EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BDB24CA.4050407@lodderstedt.net> <AANLkTikGcyvdMiYKLC3TUaIVChlgwQUxJ2I8eud1ivNU@mail.gmail.com>
In-Reply-To: <AANLkTikGcyvdMiYKLC3TUaIVChlgwQUxJ2I8eud1ivNU@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Df-Sender: 141509
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Scope - Coming to a Consensus
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, 01 May 2010 06:01:05 -0000
Am 01.05.2010 03:07, schrieb Marius Scurtescu: > On Fri, Apr 30, 2010 at 11:43 AM, Torsten Lodderstedt > <torsten@lodderstedt.net> wrote: > >> In my opinion, automatic discovery on scope values is as valuable or not >> valuable as automatic discovery for a service API. I would like to echo one >> of my postings: >> >> A scope defines the set of permissions a client asks for and that becomes >> associated with tokens. I don't see the need (and a way) for automatic scope >> discovery. In my opinion, scopes are part of the API documentation of a >> particular resource server. So if someone implements a client, it needs to >> consider the different scopes this client needs the end users authorization >> for. If the resource server implements a OAuth2-based standard API (e.g. for >> contact management or e-Mail), a client might be interoperable (in terms of >> scopes) among the resource servers implementing this standard. >> > Not sure I understand, are you saying that for a standard API, like > IMAP for example, there should be a standard scope (or set of scopes)? > Yes, that's what I said. Scopes (~permissions) should be defined allong with the corresponding API. So developers should know upfront which scope is required to perform a particular action. For example, "uploading documents requires scope 'upload'". The same holds for IMAP. Depending on the IMAP feature set you want to use there could be plenty of scopes, ranging from "read users INBOX" to sharing scenarios, where users have access to other users IMAP folders. regards, Torsten. > If not, then discovery of scopes is almost a must in this case. The > client implementor cannot know the actual scope because implementation > is done against a generic API. > > I did not see the value of scope discovery until I realized the above use case. > > Marius >
- [OAUTH-WG] Scope - Coming to a Consensus Eran Hammer-Lahav
- Re: [OAUTH-WG] Scope - Coming to a Consensus Torsten Lodderstedt
- Re: [OAUTH-WG] Scope - Coming to a Consensus Allen Tom
- Re: [OAUTH-WG] Scope - Coming to a Consensus Joseph Smarr
- Re: [OAUTH-WG] Scope - Coming to a Consensus Pelle Braendgaard
- Re: [OAUTH-WG] Scope - Coming to a Consensus Justin Smith
- Re: [OAUTH-WG] Scope - Coming to a Consensus Marius Scurtescu
- Re: [OAUTH-WG] Scope - Coming to a Consensus Marius Scurtescu
- Re: [OAUTH-WG] Scope - Coming to a Consensus Torsten Lodderstedt
- Re: [OAUTH-WG] Scope - Coming to a Consensus Eve Maler
- Re: [OAUTH-WG] Scope - Coming to a Consensus Luke Shepard
- Re: [OAUTH-WG] Scope - Coming to a Consensus Dick Hardt
- Re: [OAUTH-WG] Scope - Coming to a Consensus Manger, James H
- Re: [OAUTH-WG] Permissions (Scope - Coming to a C… Manger, James H
- Re: [OAUTH-WG] Permissions (Scope - Coming to a C… Allen Tom
- Re: [OAUTH-WG] Scope - Coming to a Consensus Evan Gilbert
- Re: [OAUTH-WG] Scope - Coming to a Consensus Mark Mcgloin
- Re: [OAUTH-WG] Scope - Coming to a Consensus Eran Hammer-Lahav