[OAUTH-WG] FW: couple minor spec issues

Eran Hammer-Lahav <eran@hueniverse.com> Mon, 15 August 2011 06:18 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 C6DD011E80AE for <oauth@ietfa.amsl.com>; Sun, 14 Aug 2011 23:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Level:
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599]
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 nuSb95m8K6Fj for <oauth@ietfa.amsl.com>; Sun, 14 Aug 2011 23:18:55 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id B211C11E80AD for <oauth@ietf.org>; Sun, 14 Aug 2011 23:18:55 -0700 (PDT)
Received: (qmail 27697 invoked from network); 15 Aug 2011 06:19:39 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Aug 2011 06:19:39 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 14 Aug 2011 23:19:38 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: OAuth WG <oauth@ietf.org>
Date: Sun, 14 Aug 2011 23:18:27 -0700
Thread-Topic: couple minor spec issues
Thread-Index: AQHMS6QtMsuj60qNLUK/U1Pu7gq3j5UAReQAgB1IzxA=
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234502498CDD8@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <CA543FC3.1FDCA%clucas@e-miles.com> <CA559080.20043%clucas@e-miles.com>
In-Reply-To: <CA559080.20043%clucas@e-miles.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [OAUTH-WG] FW: couple minor spec issues
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, 15 Aug 2011 06:18:56 -0000

Sending to the list for proper archiving.

EHL

-----Original Message-----
From: Casey Lucas [mailto:CLucas@e-miles.com] 
Sent: Wednesday, July 27, 2011 8:05 AM
To: Eran Hammer-Lahav
Subject: FW: couple minor spec issues

Eran,

I tried to send this to the oauth list yesterday but it didn't get through. I'm not sure what the problem was but wanted to relay the information in case you found it helpful.

Thanks,
-casey






On 7/26/11 9:56 AM, "Casey Lucas" <clucas@e-miles.com> wrote:


Thank you all for the oauth2 related work.

While evaluating the applicability of oauth for some of my company's problems I noticed what appear to be a couple of minor issues with the spec (version 20):

1. Section 4.1.3 Access Token Request is missing the word "request":

"For example, the client makes the following HTTP using transport-layer security (extra line breaks are for display purposes only)"


Likely it should be:

For example, the client makes the following HTTP _request_ using transport-layer security (extra line breaks are for display purposes only)



2. Section 6 Refreshing an Access Token seems to conflict with itself concerning token scope:

"The requested scope MUST be equal or lesser than the scope originally granted by the resource owner, and if omitted is treated as equal to the scope originally granted by the resource owner."


Yet the last sentence in that section states:

"If a new refresh token is issued, its scope MUST be identical to that of the refresh token included in the request."

Should't it be the lesser of the original refresh_token's scope and the newly requested scope? Since the scope parameter is either passed or implied, should that last sentence be something like:

If a new refresh token is issued, its scope MUST be identical to the passed or implied scope parameter.


For reference, the scope parameter description is currently:

OPTIONAL.  The scope of the access request expressed as a list
         of space-delimited, case sensitive strings.  The value is
         defined by the authorization server.  If the value contains
         multiple space-delimited strings, their order does not matter,
         and each string adds an additional access range to the
         requested scope.  The requested scope MUST be equal or lesser
         than the scope originally granted by the resource owner, and if
         omitted is treated as equal to the scope originally granted by
         the resource owner.



-casey