IETF Logo Mail Archive

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

Phil Hunt <phil.hunt@oracle.com> Tue, 10 January 2012 19:32 UTC

Return-Path: <phil.hunt@oracle.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 F0CF721F8688 for <oauth@ietfa.amsl.com>; Tue, 10 Jan 2012 11:32:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.901
X-Spam-Level:
X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 v-DS3JaMPi5L for <oauth@ietfa.amsl.com>; Tue, 10 Jan 2012 11:32:54 -0800 (PST)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2FC21F873B for <oauth@ietf.org>; Tue, 10 Jan 2012 11:32:53 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0AJWqo8012755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Jan 2012 19:32:53 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q0AJWpIT027766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 19:32:52 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q0AJWplb008043; Tue, 10 Jan 2012 13:32:51 -0600
Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 10 Jan 2012 11:32:50 -0800
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset="us-ascii"
From: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <6.2.5.6.2.20120110104038.099f1ba8@resistor.net>
Date: Tue, 10 Jan 2012 11:32:48 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <E300DA82-5DB9-4768-AF21-D30B15ECB4D0@oracle.com>
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>
To: SM <sm@resistor.net>
X-Mailer: Apple Mail (2.1251.1)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4F0C9265.007F,ss=1,re=0.000,fgs=0
Cc: oauth@ietf.org
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 19:32:55 -0000

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

v2.28.0 | Report a Bug | By Email | System Status