Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer

Eran Hammer <> Thu, 12 April 2012 12:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A854A21F8692 for <>; Thu, 12 Apr 2012 05:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7PhduYp403eo for <>; Thu, 12 Apr 2012 05:56:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B98F721F867F for <>; Thu, 12 Apr 2012 05:56:20 -0700 (PDT)
Received: from ([]) by with bizsmtp id x0wL1i0010EuLVk010wLl3; Thu, 12 Apr 2012 05:56:20 -0700
Received: from ([]) by ([]) with mapi id 14.02.0247.003; Thu, 12 Apr 2012 05:56:20 -0700
From: Eran Hammer <>
To: Pete Resnick <>, Apps Discuss <>, "" <>
Thread-Topic: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer
Thread-Index: AQHNGG7U0F8LwN3hVU263jHNydMVG5aXJLK6
Date: Thu, 12 Apr 2012 12:56:19 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Apr 2012 12:56:22 -0000

The issue is pretty simple. The OAuth bearer token specification defines an HTTP Authorization header scheme. It also provides a "hack" for sending the same authentication credentials direction in the HTTP request URI. For example:

This in practice claims the 'access_token' URI query parameter as a reseved parameter name used by the bearer token specification. The reason is that any future (or existing) implementation using this parameter name will now be in conflict with the OAuth bearer token specification. We do not have a mechanism for reserving URI query parameters - but in practice, this updates RFC 3986 by taking ownership of the query parameter name.

There were other voices on the OAuth WG to simply drop this mechanism but resistance from the authors and lack of strong consensus kept it in.

I supported Mark's recommendation of dropping that mechanism.

Hope this is helpful.


From: [] on behalf of Pete Resnick []
Sent: Wednesday, April 11, 2012 10:40 PM
To: Apps Discuss;
Subject: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer


Mark mentioned to me that he did not think one major issue in his review
of this document was fully addressed. I would like to get some feedback
from other folks here on the Apps-discuss list as I cannot say myself
that I fully understand the implications of the issue.

Mike Jones <> wrote:

> Mark Nottingham <> wrote:
>> * Section 2.3 URI Query Parameter
>> This section effectively reserves a URI query parameter for the
>> draft's use. This should not be done lightly, since this would be a
>> precedent for the IETF encroaching upon a server's URIs (done
>> previously in RFC5785, but in a much more limited fashion, as a
>> tactic to prevent further, uncontrolled encroachment).
>> Given that the draft already discourages the use of this mechanism,
>> I'd recommend dropping it altogether. If the Working Group wishes it
>> to remain, this issues should be vetted both through the APPS area
>> and the W3C liaison.
>> (The same criticism could be leveled at Section 2.2 Form-Encoded Body
>> Parameter, but that at least isn't surfaced in an identifier)
> There are some contexts, especially limited browsers and/or
> development environments, where query parameters are usable but the
> other methods are not.  Thus, the query parameter method must be
> retained.  Also, Justin Richter's comments describing the value to him
> of the query parameter method are pertinent:  A URL with all
> parameters including authorization is a powerful artifact which can be
> passed around between systems as a unit.
> As to using a standard parameter name, this is essential for
> interoperability.  It is not reserved in any contexts other than when
> the Bearer spec is employed, which is a voluntary act by both
> parties.  Thus, this poses no undue burdens or namespace restrictions
> on implementations in practice.
> Finally, you'll find that OAuth 1.0 [RFC 5849] similarly defined, not
> one, but two standard query parameter values:  oauth_token and
> oauth_verifier.  As this didn't cause any problems in practice then,
> I'm sure that defining an access_token parameter within the Bearer
> spec for interoperability purposes won't cause a problem either.

Would anyone (including, but not limited to, Mark) be able to better
explain the issue here?



Pete Resnick<>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

apps-discuss mailing list