Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification

Eran Hammer <eran@hueniverse.com> Tue, 10 January 2012 21:15 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 9787211E807F for <oauth@ietfa.amsl.com>; Tue, 10 Jan 2012 13:15:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.58
X-Spam-Level:
X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599]
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 TQTM0315J1oo for <oauth@ietfa.amsl.com>; Tue, 10 Jan 2012 13:15:56 -0800 (PST)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id CD20A11E8071 for <oauth@ietf.org>; Tue, 10 Jan 2012 13:15:56 -0800 (PST)
Received: (qmail 12946 invoked from network); 10 Jan 2012 21:15:53 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 10 Jan 2012 21:15:53 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Tue, 10 Jan 2012 14:15:33 -0700
From: Eran Hammer <eran@hueniverse.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Date: Tue, 10 Jan 2012 14:15:13 -0700
Thread-Topic: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification
Thread-Index: AczPzrtyNTFtRxfPRoaOekLZP1QN0wADTs4A
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453A72D0F24@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <CAG+j4TrQGwiDj01huDgfEy+02b4=tTDYifiXcvhDHrw3i32-6Q@mail.gmail.com> <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> <CAG+j4TrFoxvMMK_Bx=0e1qFLjUmKKaEmJD6hBnR06H6Fm75xfw@mail.gmail.com> <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> <CAG+j4TpuO0N7n9xxB=3mh7EZhsjXDtB2DPa0S8BBJmhV_mv4Xw@mail.gmail.com> <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> <CAG+j4TrUGtua8umh+GqJM_i6OeZrwHy7NwoGK1dTYGpHBuuV2Q@mail.gmail.com> <1326160314.71861.YahooMailNeo@web31806.mail.mud.yahoo.com> <CAG+j4TrkXE_N6T35LaApswKJMRzNmBYbB_CnqUi37s6sK5nQAw@mail.gmail.com> <1326162276.40306.YahooMailNeo@web31811.mail.mud.yahoo.com> <CAG+j4TqhGi_0Z=C7gPbxAx6L7DV-NeLCewYyc4T-SbfdfWR=GA@mail.gmail.com> <1326215997.44445.YahooMailNeo@web31816.mail.mud.yahoo.com> <6.2.5.6.2.20120110104038.099f1ba8@resistor.net> <E300DA82-5DB9-4768-AF21-D30B15ECB4D0@oracle.com>
In-Reply-To: <E300DA82-5DB9-4768-AF21-D30B15ECB4D0@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification
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, 10 Jan 2012 21:15:57 -0000

I don't think the issue here is about the scope value, but who does the OPTIONAL designation applies to. IOW, is it optional for the server to support/require it, or is it optional for the client to include or omit it.

The intention was to make it optional for the authorization server to make all decisions about the parameter, including making it required. But the text is confusing since the text is aimed directly at the client when making the request.

We need to clarify this and the options are:

1. The client can decide if they want to include or omit the scope parameter. If omitted, the server must process the request using some documented default scope. This default scope can be an empty scope rendering the token useless for anything other than verifying user authentication.

2. The server can declare scope to be a required parameter in which case the client must include it or the request will fail. In this case, we should make the text clearer that clients to find out if the particular server requires it.

#1 is better for interoperability, #2 is more in the spirit of the parameter discussions so far.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Phil Hunt
> Sent: Tuesday, January 10, 2012 11:33 AM
> To: SM
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in
> Specification
> 
> The underlying issue is that there was a decision not to in any way
> standardize values for scope.
> 
> I agreed this was reasonable since the underlying resource APIs are likely to
> be very specific requiring some degree of prior knowledge by the client app
> developer. Thus the resource server OAuth infrastructure is free to decide
> what are and are not acceptable values including missing or null values for
> scope.
> 
> I think the specification is acceptable as it is.
> 
> I note that other specifications that layer on top of OAuth2 such as OpenID
> Connect may choose to strictly define acceptable values for scope. This type
> of layering works well in my opinion.
> 
> Phil
> 
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
> 
> 
> 
> 
> 
> On 2012-01-10, at 10:56 AM, SM wrote:
> 
> > At 09:19 10-01-2012, William Mills wrote:
> >> That does clear it up!  If the implementation returns a proper error when
> the scope is omitted then it will be in conformance.  Sending an error result
> for the empty scope is valid.
> >
> > Yes.
> >
> > It is not possible to get a clear view of the specs if the discussion about
> "ambiguity" relies on the meaning of the word "OPTIONAL" only.  If there is a
> problem, then clarifying text could be used to fix it instead of changing the
> requirements.
> >
> > Regards,
> > -sm
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth