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

Eran Hammer <eran@hueniverse.com> Mon, 09 January 2012 16:05 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 32E5D21F8516 for <oauth@ietfa.amsl.com>; Mon, 9 Jan 2012 08:05:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level:
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 BS5OpVpZr1vb for <oauth@ietfa.amsl.com>; Mon, 9 Jan 2012 08:05:03 -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 56C0611E8072 for <oauth@ietf.org>; Mon, 9 Jan 2012 08:05:03 -0800 (PST)
Received: (qmail 12445 invoked from network); 9 Jan 2012 16:05:02 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 Jan 2012 16:05:02 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Mon, 9 Jan 2012 09:04:51 -0700
From: Eran Hammer <eran@hueniverse.com>
To: agks mehx <agksmehx@gmail.com>, "oauth@ietf.org" <oauth@ietf.org>
Date: Mon, 09 Jan 2012 09:04:35 -0700
Thread-Topic: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification
Thread-Index: AczOUskvVDrfg5X0SKe4DupMHiv9+wAlRqSA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453A72D0CF1@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <CAG+j4TrQGwiDj01huDgfEy+02b4=tTDYifiXcvhDHrw3i32-6Q@mail.gmail.com>
In-Reply-To: <CAG+j4TrQGwiDj01huDgfEy+02b4=tTDYifiXcvhDHrw3i32-6Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453A72D0CF1P3PW5EX1MB01E_"
MIME-Version: 1.0
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, 09 Jan 2012 16:05:05 -0000

In general, you are correct. However in this case, since OAuth 2.0 does not attempt to guarantee interop between a generic client and any vendor, the vendor has the right to define its own requirements as long as they are within the spec boundaries.

For example, a vendor can define a missing or empty scope to mean no scope and reject the request. That's allowed since the definition of scope is left for the vendor to define.

Personally, I would not write a server implementation with this behavior and instead define a default scope that's sufficient in most cases.

EHL


From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of agks mehx
Sent: Sunday, January 08, 2012 2:13 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification

My client implementation per latest draft did not work against a major vendor's server implementation.

This was because the vendor REQUIRES the scope parameter in the initial request.  If I do not supply the scope parameter, it calls back the URL with an error response stating that the request is invalid:

error=invalid_request&error_description=Missing+required+parameter:+scope

I reported this to the vendor and the vendor claims that the IETF draft specification says scope is OPTIONAL and that means the vendor is free to make it required in a conforming implementation.

After a careful reading of the relevant sections of the draft specification, I do not believe that is what is the intent of the specification.  It says "OPTIONAL" is to be interpreted per RFC2119, which in turn says: "an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)"

This leads me to believe that if I do not supply scope I should not get an error -- I may not be able to perform any API calls but I should get a token back that proves to me that the user was *some* user at the vendor.

Could you please clarify or disambiguate?