Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification
agks mehx <agksmehx@gmail.com> Wed, 11 January 2012 00:18 UTC
Return-Path: <agksmehx@gmail.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 EDBD311E8093 for <oauth@ietfa.amsl.com>; Tue, 10 Jan 2012 16:18:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.377
X-Spam-Level:
X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 mfa6kQrNEjcC for <oauth@ietfa.amsl.com>; Tue, 10 Jan 2012 16:18:14 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id ACB5D11E8088 for <oauth@ietf.org>; Tue, 10 Jan 2012 16:18:14 -0800 (PST)
Received: by yhpp56 with SMTP id p56so85466yhp.31 for <oauth@ietf.org>; Tue, 10 Jan 2012 16:18:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=YK2ZMy51RdH8jkhTQV3rkPWcEDYvVI+qDXNkBXBgArs=; b=OV92sXjo5RS2fBjh787N45As2qye7g/fy8V0ZMEfjrRjJRSPbUbHYQXOTKEcfVNlZq y+1DO1ymDmL2SUqyg4g1SQqgPNT59CktQAa8Ul9pE0ONwL++WyHlTmTTMUqO7AJAIBku 6dcawfQW+Gc6I5fL2yfClHGiWQ1uTTRWyllT0=
MIME-Version: 1.0
Received: by 10.236.155.226 with SMTP id j62mr5538107yhk.49.1326241090807; Tue, 10 Jan 2012 16:18:10 -0800 (PST)
Received: by 10.236.115.68 with HTTP; Tue, 10 Jan 2012 16:18:10 -0800 (PST)
In-Reply-To: <1326240141.98332.YahooMailNeo@web31808.mail.mud.yahoo.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> <E300DA82-5DB9-4768-AF21-D30B15ECB4D0@oracle.com> <90C41DD21FB7C64BB94121FBBC2E723453A72D0F24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1326240141.98332.YahooMailNeo@web31808.mail.mud.yahoo.com>
Date: Tue, 10 Jan 2012 16:18:10 -0800
Message-ID: <CAG+j4TpwzWWYUryJjD0d+t+emzzH6_5ed5cj22Py4RE52DcfCw@mail.gmail.com>
From: agks mehx <agksmehx@gmail.com>
To: William Mills <wmills@yahoo-inc.com>, Eran Hammer <eran@hueniverse.com>, "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="20cf303b3c871aa73504b63591b8"
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: Wed, 11 Jan 2012 00:18:16 -0000
Sounds very good: "... MAY include or omit the scope parameter. If omitted, the server must process the request using an empty scope as the default." On Tue, Jan 10, 2012 at 4:02 PM, William Mills <wmills@yahoo-inc.com> wrote: > On your #1, I don't agree that an empty scope is useless. There are > comparable implementations that use an empty scope to be a wildcard scope. > I'd say, > > "The client can MAY include or omit the scope parameter. If omitted, the > server must process the request using an empty scope as the default. The > server then processes the request either issuing a grant with it's default > scope as defined by the server or failing the request indicating an invalid > scope requested." > > That language isn't quite right, but I think it's clear. > > ------------------------------ > *From:* Eran Hammer <eran@hueniverse.com> > *To:* "oauth@ietf.org" <oauth@ietf.org> > *Sent:* Tuesday, January 10, 2012 1:15 PM > > *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in > Specification > > 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 > _______________________________________________ > 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 > >
- [OAUTH-WG] Seeking Clarification: Potential Ambig… agks mehx
- Re: [OAUTH-WG] Seeking Clarification: Potential A… SM
- Re: [OAUTH-WG] Seeking Clarification: Potential A… Eran Hammer
- Re: [OAUTH-WG] Seeking Clarification: Potential A… agks mehx
- Re: [OAUTH-WG] Seeking Clarification: Potential A… William Mills
- Re: [OAUTH-WG] Seeking Clarification: Potential A… agks mehx
- Re: [OAUTH-WG] Seeking Clarification: Potential A… William Mills
- Re: [OAUTH-WG] Seeking Clarification: Potential A… agks mehx
- Re: [OAUTH-WG] Seeking Clarification: Potential A… William Mills
- Re: [OAUTH-WG] Seeking Clarification: Potential A… agks mehx
- Re: [OAUTH-WG] Seeking Clarification: Potential A… William Mills
- Re: [OAUTH-WG] Seeking Clarification: Potential A… SM
- Re: [OAUTH-WG] Seeking Clarification: Potential A… Phil Hunt
- Re: [OAUTH-WG] Seeking Clarification: Potential A… Eran Hammer
- Re: [OAUTH-WG] Seeking Clarification: Potential A… William Mills
- Re: [OAUTH-WG] Seeking Clarification: Potential A… agks mehx
- Re: [OAUTH-WG] Seeking Clarification: Potential A… William Mills
- Re: [OAUTH-WG] Seeking Clarification: Potential A… Eran Hammer
- Re: [OAUTH-WG] Seeking Clarification: Potential A… William Mills
- Re: [OAUTH-WG] Seeking Clarification: Potential A… Eran Hammer
- Re: [OAUTH-WG] Seeking Clarification: Potential A… Igor Faynberg
- Re: [OAUTH-WG] Seeking Clarification: Potential A… William Mills
- Re: [OAUTH-WG] Seeking Clarification: Potential A… Andreas Åkre Solberg
- Re: [OAUTH-WG] Seeking Clarification: Potential A… Eran Hammer