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