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

agks mehx <agksmehx@gmail.com> Sun, 08 January 2012 22:12 UTC

Return-Path: <agksmehx@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7911621F852E for <oauth@ietfa.amsl.com>; Sun, 8 Jan 2012 14:12:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id K3FSsdAP-MD6 for <oauth@ietfa.amsl.com>; Sun, 8 Jan 2012 14:12:51 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id DE9FF21F852D for <oauth@ietf.org>; Sun, 8 Jan 2012 14:12:50 -0800 (PST)
Received: by yhpp56 with SMTP id p56so234692yhp.31 for <oauth@ietf.org>; Sun, 08 Jan 2012 14:12:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=50MkcGwA/dSwwkI98NECvCoEFKJN8UhGGetSjy9lVbY=; b=S2i/WeGVBVAsB9lrtzvR0SBWgg2RIzzUTr2VpwXwoL3oDiAY7Q0Nja+u+cAfIIh6eD 9YVuuP0AiYcfbEEQJap+MIH2BggcHmjEDwhb44maquEX//etu+tG9FlcOViB9XRE6U5N uPDXnGkHOVH64Uy3GlRRYLWME+gxrXLJpVSH0=
MIME-Version: 1.0
Received: by with SMTP id l33mr3230075yhi.66.1326060770412; Sun, 08 Jan 2012 14:12:50 -0800 (PST)
Received: by with HTTP; Sun, 8 Jan 2012 14:12:50 -0800 (PST)
Date: Sun, 08 Jan 2012 14:12:50 -0800
Message-ID: <CAG+j4TrQGwiDj01huDgfEy+02b4=tTDYifiXcvhDHrw3i32-6Q@mail.gmail.com>
From: agks mehx <agksmehx@gmail.com>
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="20cf301b65b12bc96004b60b950a"
Subject: [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: Sun, 08 Jan 2012 22:13:39 -0000

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:


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

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?