Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer
Tim Bray <tbray@textuality.com> Thu, 12 April 2012 16:34 UTC
Return-Path: <tbray@textuality.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADC321F8646 for <apps-discuss@ietfa.amsl.com>; Thu, 12 Apr 2012 09:34:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.477
X-Spam-Level:
X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 5tEPswnSAJ0C for <apps-discuss@ietfa.amsl.com>; Thu, 12 Apr 2012 09:34:46 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 35E8921F8539 for <apps-discuss@ietf.org>; Thu, 12 Apr 2012 09:34:46 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so3406722obb.31 for <apps-discuss@ietf.org>; Thu, 12 Apr 2012 09:34:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=7zo5YLQy8k1aKxSbtEbhdZZOOu8jX7lvi0RT5zleJlA=; b=BgZVj5LbllH8NMaKtGJgxniCWx1gZXkSL5dbbxi+2Age48FsFSBYpZD7a6Ib3vNmsu 1fGD0VA/DTOQUupiB0sU5XpwXLHSOzPyXrsxFa3UMOeVXLAMMnMGEsoj9Razec8ag/On Kkxf0BVyYDTk2C8fqObIE1qv6izgXQk8FwdI3jYx10FuRgbAnKVUORbHApBTepmJN2c7 jvmYafVt7sqrO8MPSk0E0zn+J+B2XLyHpEJai/aZ63+EvCd3StTYla9Iemroz8DQ75yI SLYeS5+L1BAvKZxTLuBl6bfOk+hGpGK+49Hv5DNuN8rWLHAW95aDFR+CtGFQI0z71Ne2 N6Eg==
MIME-Version: 1.0
Received: by 10.182.113.42 with SMTP id iv10mr1039481obb.18.1334248485773; Thu, 12 Apr 2012 09:34:45 -0700 (PDT)
Received: by 10.182.29.6 with HTTP; Thu, 12 Apr 2012 09:34:45 -0700 (PDT)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FE2816@P3PWEX2MB008.ex2.secureserver.net>
References: <4F866AC0.3000603@qualcomm.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE2816@P3PWEX2MB008.ex2.secureserver.net>
Date: Thu, 12 Apr 2012 09:34:45 -0700
Message-ID: <CAHBU6iuR+2CfPsPdkjMJCSmzrX1B8_nLB=xp_NRZi7db78V8vw@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Eran Hammer <eran@hueniverse.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlc3Sx9xYZW7l14n8AMhGCzysZgKcVAT8eUvuEnS5yKI6i/uz8NWfasgCu5BR1f3yIF96pa
Cc: Pete Resnick <presnick@qualcomm.com>, "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" <draft-ietf-oauth-v2-bearer.all@tools.ietf.org>, Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2012 16:34:47 -0000
Well, it would claim it as a reserved paramater name if there a way to do such a thing, which there explicitly isn’t in RFC3986. URIs are for most application purposes opaque strings; this breaks that and is a hideous architectural botch. For example, there is a huge amount of deployed code out there which compares two URIs and determines whether they are equivalent or different (to start with, every piece of crawling and caching infrastructure in the world); must it all now be refactored to check the parameters for oauth_* and disregard those values in their equality considerations? Chapter 6 of RFC3986 explicitly discusses issues in comparing URIs for equivalency; read it, and you’ll find nothing there about ?name=value pairs. This is not how URIs work. It might be convenient in some application scenarios, but in other application scenarios it might be convenient to add your own IP packet header bits, and you can’t do that either. Please back this horrible idea out. -T On Thu, Apr 12, 2012 at 5:56 AM, Eran Hammer <eran@hueniverse.com> wrote: > 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: > > http://example.com/protected/resource?access_token=alskjdlaskjd > > 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. > > EH > > ________________________________________ > From: apps-discuss-bounces@ietf.org [apps-discuss-bounces@ietf.org] on behalf of Pete Resnick [presnick@qualcomm.com] > Sent: Wednesday, April 11, 2012 10:40 PM > To: Apps Discuss; draft-ietf-oauth-v2-bearer.all@tools.ietf.org > Subject: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer > > Folks, > > 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 <Michael.Jones@microsoft.com> wrote: > >> Mark Nottingham <mnot@mnot.net> 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? > > Thanks, > > pr > > -- > Pete Resnick<http://www.qualcomm.com/~presnick/> > Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss
- [apps-discuss] Reserved URI query parameter in dr… Pete Resnick
- Re: [apps-discuss] Reserved URI query parameter i… Eran Hammer
- Re: [apps-discuss] Reserved URI query parameter i… Julian Reschke
- Re: [apps-discuss] Reserved URI query parameter i… Tim Bray
- Re: [apps-discuss] Reserved URI query parameter i… John C Klensin
- Re: [apps-discuss] Reserved URI query parameter i… Ned Freed
- Re: [apps-discuss] Reserved URI query parameter i… Mark Nottingham
- Re: [apps-discuss] Reserved URI query parameter i… Ned Freed
- Re: [apps-discuss] Reserved URI query parameter i… John C Klensin
- Re: [apps-discuss] Reserved URI query parameter i… John C Klensin
- Re: [apps-discuss] Reserved URI query parameter i… Stephen Farrell
- Re: [apps-discuss] Reserved URI query parameter i… Mark Nottingham
- Re: [apps-discuss] Reserved URI query parameter i… Tim Bray
- Re: [apps-discuss] Reserved URI query parameter i… Ned Freed
- Re: [apps-discuss] Reserved URI query parameter i… Stephen Farrell
- Re: [apps-discuss] Reserved URI query parameter i… Carsten Bormann
- Re: [apps-discuss] Reserved URI query parameter i… John C Klensin
- Re: [apps-discuss] Reserved URI query parameter i… Ned Freed
- Re: [apps-discuss] Reserved URI query parameter i… Tim Bray
- Re: [apps-discuss] Reserved URI query parameter i… Mike Jones
- Re: [apps-discuss] Reserved URI query parameter i… Dick Hardt
- Re: [apps-discuss] Reserved URI query parameter i… Dick Hardt
- Re: [apps-discuss] Reserved URI query parameter i… Eran Hammer
- Re: [apps-discuss] Reserved URI query parameter i… Stephen Farrell
- Re: [apps-discuss] Reserved URI query parameter i… Derek Atkins
- Re: [apps-discuss] Reserved URI query parameter i… William Mills
- Re: [apps-discuss] Reserved URI query parameter i… Stephen Farrell
- Re: [apps-discuss] Reserved URI query parameter i… William Mills
- Re: [apps-discuss] Reserved URI query parameter i… Eran Hammer
- Re: [apps-discuss] Reserved URI query parameter i… Mike Jones
- Re: [apps-discuss] Reserved URI query parameter i… Eran Hammer
- Re: [apps-discuss] Reserved URI query parameter i… Eran Hammer
- Re: [apps-discuss] Reserved URI query parameter i… Dick Hardt
- Re: [apps-discuss] Reserved URI query parameter i… Dick Hardt
- Re: [apps-discuss] Reserved URI query parameter i… Dick Hardt
- Re: [apps-discuss] Reserved URI query parameter i… William Mills
- Re: [apps-discuss] Reserved URI query parameter i… Mark Nottingham
- Re: [apps-discuss] Reserved URI query parameter i… Eran Hammer
- Re: [apps-discuss] Reserved URI query parameter i… Mark Nottingham
- Re: [apps-discuss] Reserved URI query parameter i… Mark Nottingham
- Re: [apps-discuss] Reserved URI query parameter i… Dick Hardt
- Re: [apps-discuss] Reserved URI query parameter i… Dick Hardt
- Re: [apps-discuss] Reserved URI query parameter i… Dick Hardt
- Re: [apps-discuss] Reserved URI query parameter i… Dick Hardt
- Re: [apps-discuss] Reserved URI query parameter i… Dick Hardt