Re: [OAUTH-WG] Issue: Scope parameter

"Manger, James H" <James.H.Manger@team.telstra.com> Fri, 16 April 2010 04:09 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 8DDA53A696F for <oauth@core3.amsl.com>; Thu, 15 Apr 2010 21:09:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.327
X-Spam-Level:
X-Spam-Status: No, score=-0.327 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, 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 VD8uiDdn3hQL for <oauth@core3.amsl.com>; Thu, 15 Apr 2010 21:09:12 -0700 (PDT)
Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by core3.amsl.com (Postfix) with ESMTP id C19503A6852 for <oauth@ietf.org>; Thu, 15 Apr 2010 21:09:08 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.52,217,1270389600"; d="p7s'?scan'208,217"; a="1363883"
Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 16 Apr 2010 14:09:01 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,5952"; a="811422"
Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipccni.tcif.telstra.com.au with ESMTP; 16 Apr 2010 14:09:01 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Fri, 16 Apr 2010 14:09:01 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Justin Smith <justinsm@microsoft.com>, OAuth WG <oauth@ietf.org>
Date: Fri, 16 Apr 2010 14:08:59 +1000
Thread-Topic: [OAUTH-WG] Issue: Scope parameter
Thread-Index: AQHK3NEWvq+1OOTFrkS1RWT2flQ40pIkXsgAgAADXwCAAAODAP//ySWwgAAfiRCAACcXIIAAAxeg
Message-ID: <255B9BB34FB7D647A506DC292726F6E11257591D3B@WSMSG3153V.srv.dir.telstra.com>
References: <h2o74caaad21004151238w60c3afd3td8dccdd8a7127a4a@mail.gmail.com> <C7ECBC36.32379%eran@hueniverse.com> <191F411E00E19F4E943ECDB6D65C60851691F095@TK5EX14MBXC115.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1125748109A@WSMSG3153V.srv.dir.telstra.com> <191F411E00E19F4E943ECDB6D65C60851691F5A9@TK5EX14MBXC115.redmond.corp.microsoft.com>
In-Reply-To: <191F411E00E19F4E943ECDB6D65C60851691F5A9@TK5EX14MBXC115.redmond.corp.microsoft.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_001A_01CADD6E.5BE31430"
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 04:09:13 -0000

> Is it important for an Authorization Server to be able to protect multiple resources?

 

YES

 

>  If so, how should the client specify which resource it intends to access (it seems like that is required)?

 

By redirecting the user to an authz URI that represents the intended resource.

 

If the client is interoperating with a resource it has no special knowledge about, then it can learn the authz URI from the 401 WWW-Auth.: OAUTH header it received when trying to access the resource directly. The server returning this header knows what resource the client asked for so the server can encode that information into the returned authz URI in whatever way it has prearranged with its AS.

 

 

--

James Manger

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Manger, James H
Sent: Thursday, April 15, 2010 6:40 PM
To: OAuth WG
Subject: Re: [OAUTH-WG] Issue: Scope parameter

 

> 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?