Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer
John C Klensin <john@jck.com> Fri, 13 April 2012 19:53 UTC
Return-Path: <john@jck.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 ECAB521F8833 for <apps-discuss@ietfa.amsl.com>; Fri, 13 Apr 2012 12:53:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 bNCjGGcTJBs3 for <apps-discuss@ietfa.amsl.com>; Fri, 13 Apr 2012 12:53:26 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 138E521F8832 for <apps-discuss@ietf.org>; Fri, 13 Apr 2012 12:53:26 -0700 (PDT)
Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john@jck.com>) id 1SImTK-000GDs-Gd; Fri, 13 Apr 2012 15:47:54 -0400
Date: Fri, 13 Apr 2012 15:53:10 -0400
From: John C Klensin <john@jck.com>
To: Ned Freed <ned.freed@mrochek.com>, Mark Nottingham <mnot@mnot.net>
Message-ID: <0D4BD162580A7D4CE6A01C71@PST.JCK.COM>
In-Reply-To: <01OE921YMRSW00ZUIL@mauve.mrochek.com>
References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: Pete Resnick <presnick@qualcomm.com>, Apps Discuss <apps-discuss@ietf.org>, draft-ietf-oauth-v2-bearer.all@tools.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: Fri, 13 Apr 2012 19:53:27 -0000
--On Friday, April 13, 2012 00:43 -0700 Ned Freed <ned.freed@mrochek.com> wrote: >> On 12/04/2012, at 4:15 PM, Ned Freed wrote: >> > >> > Pete, I think the issue is moot at this point. A quick >> > google search clearly shows that this stuff is already >> > deployed by multiple vendors, including use of >> > access_token. As such, it is effectively impossible to >> > change it at this point. >> > >> > I have to say I would have a lot more comfortable with a >> > name like oauth_access_token that removes the possibility >> > of conflict with other uses, but at this point it's a "grin >> > and bear it" situation AFAICT. > >> I would still like to see us do the right thing by the W3C, >> and I don't see why the IESG can't insert language that >> cautions against this (as well as future things like it). > > I certainly don't object to doing that. In fact I don't object > to dropping this nasty hack from the document, although > perhaps documenting it as *not* standardized and explaining > why it sucks would be even better. > > But I also think that believing this will prevent or even > significantly limit it's use is probably unrealistic given how > far it deployment appears to have gotten. Agreeing that the horse has left the barn and is far down the street, the IETF is still being asked to publish this and publish it with some level of authority that we call "IETF Consensus" and/or "Standard". Recommendation: (1) For reasons explained in my earlier note, prune this down to one recommended/standardized method, not three. (2) For any other methods, document them as existing practice (and consequently alternatives) and _at least_ discuss the reasons for and against using them. (3) If the recommendation is to use a reserved query parameter keyword, seriously consider making that keyword something like "oauth_access_token" but noting that "access_token" is in use as a synonym and that, while we discourage it, servers SHOULD normally treat it as a synonym. I disagree with Ned to the extent that, as a firm believer in Murphy's Law and the general perversity of the universe, I would have said "reduce", rather than "remove", the possibility of conflict, but even "reduce" would be A Good Thing. (4) The document should explain the risks associated with someone using "?access_token" to mean something else entirely and of parsing, hashing, or encoding URL tails in ways that effectively disable the intent of the spec. I think that represents a reasonable balance with reality and existing practice while avoiding IETF endorsement of practices we have ample reason to believe are undesirable and should not be encouraged or endorsed. An alternative would be to not standardize this at all but simply publish a slightly-revised version of the document as an Informational description of existing practice, noting W3C endorsement to whatever degree that is appropriate. I actually don't think that is a particularly good idea, but it would be another way out. best, john
- [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