Re: [OAUTH-WG] Issue: Scope parameter

"Manger, James H" <James.H.Manger@team.telstra.com> Fri, 16 April 2010 01:40 UTC

Return-Path: <James.H.Manger@team.telstra.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 94EFD3A677E for <oauth@core3.amsl.com>; Thu, 15 Apr 2010 18:40:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.753
X-Spam-Level:
X-Spam-Status: No, score=0.753 tagged_above=-999 required=5 tests=[AWL=-0.761, BAYES_40=-0.185, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994]
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 NvcERcRtBzpO for <oauth@core3.amsl.com>; Thu, 15 Apr 2010 18:40:28 -0700 (PDT)
Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by core3.amsl.com (Postfix) with ESMTP id 4065A3A6919 for <oauth@ietf.org>; Thu, 15 Apr 2010 18:40:26 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.52,216,1270389600"; d="scan'208,217";a="1071938"
Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 16 Apr 2010 11:40:19 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,5952"; a="774441"
Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcbvi.tcif.telstra.com.au with ESMTP; 16 Apr 2010 11:40:19 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Fri, 16 Apr 2010 11:40:19 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: OAuth WG <oauth@ietf.org>
Date: Fri, 16 Apr 2010 11:40:18 +1000
Thread-Topic: [OAUTH-WG] Issue: Scope parameter
Thread-Index: AQHK3NEWvq+1OOTFrkS1RWT2flQ40pIkXsgAgAADXwCAAAODAP//ySWwgAAfiRA=
Message-ID: <255B9BB34FB7D647A506DC292726F6E1125748109A@WSMSG3153V.srv.dir.telstra.com>
References: <h2o74caaad21004151238w60c3afd3td8dccdd8a7127a4a@mail.gmail.com> <C7ECBC36.32379%eran@hueniverse.com> <191F411E00E19F4E943ECDB6D65C60851691F095@TK5EX14MBXC115.redmond.corp.microsoft.com>
In-Reply-To: <191F411E00E19F4E943ECDB6D65C60851691F095@TK5EX14MBXC115.redmond.corp.microsoft.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1125748109AWSMSG3153Vsrv_"
MIME-Version: 1.0
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: Fri, 16 Apr 2010 01:40:29 -0000

> I don’t see how the presence of a scope parameter hurts interoperability.



Scopes so far have all been specific to a specific service. Knowing how Google uses ‘scope’ tells you nothing about interoperating with Microsoft.



Requesting access to specific sets of resources is important. However, you can do it by providing different user-authorization URIs — even if the URIs only differ in the value of a ‘scope’ query parameter.



For a library that isn’t service-specific, a scope value offers no semantic value. All the library can do is tack it onto a supplied user authz URI. In which case it is simpler for the library to just accept a user authz URI that has had the scope tacked on before being passed to the library.





--

James Manger



From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Smith
Sent: Friday, 16 April 2010 9:39 AM
To: Eran Hammer-Lahav; Marius Scurtescu; recordond@gmail.com
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Issue: Scope parameter



I don’t see how the presence of a scope parameter hurts interoperability.



It think scope needs to be a 1st class citizen in the spec, not an extension. Without it, a client cannot request access to a specific set of resources (whether its represented as a string, URI, or anything else). Does the group think it Is important for an Authorization Server to be able to make auth decisions based on requested resources?