IETF Logo Mail Archive

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

Andreas Åkre Solberg <andreas.solberg@uninett.no> Mon, 23 January 2012 09:23 UTC

Return-Path: <andreas.solberg@uninett.no>
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 907D621F85C2 for <oauth@ietfa.amsl.com>; Mon, 23 Jan 2012 01:23:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 yMU+8ZjmMozB for <oauth@ietfa.amsl.com>; Mon, 23 Jan 2012 01:23:27 -0800 (PST)
Received: from epost.uninett.no (epost.uninett.no [IPv6:2001:700:0:526:158:38:180:100]) by ietfa.amsl.com (Postfix) with ESMTP id CCEC521F84CF for <oauth@ietf.org>; Mon, 23 Jan 2012 01:23:26 -0800 (PST)
Received: from dmanso-11.uninett.no (dmanso-11.uninett.no [158.38.62.67]) by epost.uninett.no (Postfix) with ESMTPS id C76E5336378; Mon, 23 Jan 2012 10:23:24 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: multipart/signed; boundary="Apple-Mail=_E8722BD9-2C3A-449A-B69A-86CEFEBD07C7"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Andreas Åkre Solberg <andreas.solberg@uninett.no>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AAB964E7@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Mon, 23 Jan 2012 10:23:24 +0100
Message-Id: <73AB1858-7975-430F-9B70-269310D88302@uninett.no>
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>
To: Eran Hammer <eran@hueniverse.com>
X-Mailer: Apple Mail (2.1251.1)
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 09:23:27 -0000

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