[OAUTH-WG] Scope definition feedback (Yaron Goland)

Eran Hammer-Lahav <eran@hueniverse.com> Tue, 16 August 2011 22:58 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D202921F8B63 for <oauth@ietfa.amsl.com>; Tue, 16 Aug 2011 15:58:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.555
X-Spam-Level:
X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+-3SDix+xZ1 for <oauth@ietfa.amsl.com>; Tue, 16 Aug 2011 15:58:29 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 8E4FE21F8B56 for <oauth@ietf.org>; Tue, 16 Aug 2011 15:58:29 -0700 (PDT)
Received: (qmail 15763 invoked from network); 16 Aug 2011 22:59:17 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Aug 2011 22:59:17 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 16 Aug 2011 15:59:13 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: OAuth WG <oauth@ietf.org>
Date: Tue, 16 Aug 2011 15:57:59 -0700
Thread-Topic: Scope definition feedback (Yaron Goland)
Thread-Index: AcxcZ7wlGdX3t4yBRYyXt5ZPA1iJfw==
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234502498D246@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234502498D246P3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: [OAUTH-WG] Scope definition feedback (Yaron Goland)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Aug 2011 22:58:30 -0000

> 4.1.2.  Authorization Response: Comment "The language around scopes in

> the document is really frustrating. One only finds out much later in the

> document that it is perfectly allowable for an authorization server to more or

> less ignore what scopes are submitted and instead to just return whatever

> the hell they want. This is a fine design choice but it seems like the sort of

> thing that should be forcefully repeated anywhere in the spec that we allow

> people to submit scopes so nobody forgets."

Added new section and changed all duplicate definitions of 'scope' to reference it:

3.3.  Access Token Scope

   The authorization and token endpoints allow the client to specify the
   scope of the access request using the "scope" request parameter.  In
   turn, the authorization server uses the "scope" response parameter to
   inform the client of the scope of the access token issued.

   The value of the scope parameter is expressed as a list of space-
   delimited, case sensitive strings.  The strings are defined by the
   authorization server.  If the value contains multiple space-delimited
   strings, their order does not matter, and each string adds an
   additional access range to the requested scope.

   The authorization server MAY fully or partially ignore the scope
   requested by the client based on the authorization server policy or
   the resource owner's instructions.  If the issued access token scope
   is different from the one requested by the client, the authorization
   server SHOULD include the "scope" response parameter to inform the
   client of the actual scope granted.

EHL