IETF Logo Mail Archive

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

Eran Hammer <eran@hueniverse.com> Mon, 23 January 2012 15:33 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 9E33B21F8687 for <oauth@ietfa.amsl.com>; Mon, 23 Jan 2012 07:33:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.314
X-Spam-Level:
X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 jDSd7WyvKMrd for <oauth@ietfa.amsl.com>; Mon, 23 Jan 2012 07:33:34 -0800 (PST)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 35D0B21F8683 for <oauth@ietf.org>; Mon, 23 Jan 2012 07:33:34 -0800 (PST)
Received: (qmail 32695 invoked from network); 23 Jan 2012 15:33:32 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 23 Jan 2012 15:33:32 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 23 Jan 2012 08:33:26 -0700
From: Eran Hammer <eran@hueniverse.com>
To: Andreas Åkre Solberg <andreas.solberg@uninett.no>
Date: Mon, 23 Jan 2012 08:33:21 -0700
Thread-Topic: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification
Thread-Index: AczZsKooptLIMsS8SH2BhOn7UoD/fAAM4ddg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AAB965D2@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> <90C41DD21FB7C64BB94121FBBC2E723453A72D0F24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1326240141.98332.YahooMailNeo@web31808.mail.mud .yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723453A72D0F60@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1326268674.20557.YahooMailNeo@web31807.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723453AAB964E7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <73AB1858-7975-430F-9B70-269310D88302@uninett.no>
In-Reply-To: <73AB1858-7975-430F-9B70-269310D88302@uninett.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "oauth@ietf.org" <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: Mon, 23 Jan 2012 15:33:34 -0000

It doesn't disallow asking the user. The server is allowed to ignore the scope requested by the client. It can also define 'default scope' to mean 'prompt user' and document that.

EHL

> -----Original Message-----
> From: Andreas Åkre Solberg [mailto:andreas.solberg@uninett.no]
> Sent: Monday, January 23, 2012 1:23 AM
> To: Eran Hammer
> Cc: William Mills; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in
> Specification
> 
> Den 20. jan. 2012 kl. 21:32 skrev Eran Hammer:
> 
> > New text added to Access Token Scope section:
> >
> >           If the client omits the scope parameter when requesting
> authorization, the authorization
> >           server MUST process the request using a pre-defined default value, or
> fail the request
> >           indicating an invalid scope.
> 
> Will this change imply that implementing a more dynamic approach to issuing
> scopes, such as in example asking the user which scope should be issued to
> the consumer, will be explicitly disallowed, while it was accepted before this
> text was added?
> 
> I think this section of the text does not solve the initial problem that started
> this thread, and I think it adds unneccessary restrictions.
> 
> >  The authorization server SHOULD document its scope
> >           requirements and default value (if defined).
> 
> This makes more sense to me.
> 
> Andreas

v2.23.0 | Report a Bug | By Email