Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer
John C Klensin <john-ietf@jck.com> Thu, 12 April 2012 18:27 UTC
Return-Path: <john-ietf@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 D90D721F84D2 for <apps-discuss@ietfa.amsl.com>; Thu, 12 Apr 2012 11:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.445
X-Spam-Level:
X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 1+1ebZ6N5RU4 for <apps-discuss@ietfa.amsl.com>; Thu, 12 Apr 2012 11:27:22 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id D5EE721F84CD for <apps-discuss@ietf.org>; Thu, 12 Apr 2012 11:27:21 -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-ietf@jck.com>) id 1SIOee-000EB7-R9; Thu, 12 Apr 2012 14:22:00 -0400
Date: Thu, 12 Apr 2012 14:27:14 -0400
From: John C Klensin <john-ietf@jck.com>
To: Pete Resnick <presnick@qualcomm.com>, Apps Discuss <apps-discuss@ietf.org>, draft-ietf-oauth-v2-bearer.all@tools.ietf.org
Message-ID: <969CE95E2B28189A109BB90F@PST.JCK.COM>
In-Reply-To: <4F866AC0.3000603@qualcomm.com>
References: <4F866AC0.3000603@qualcomm.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
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 18:27:23 -0000
Pete, The first part of this may be the same as Tim Bray's answer in different form, but, in studying it I spotted an additional, and IMO, fundamental, issue. I want to note that, prior to your request, I had not reviewed this specification -- it falls into an area in which I have assumed, and continue to believe, that there are lots of competent people in the IETF watching and that, in general, my time is therefore better spent in other ways. I've also had a specific reason to avoid it for which I will provide details to you you off list. We've basically got two types of identifiers or identifier structures. One is completely restricted and associated, to the best of our ability, with very specific syntax rules and actual or implied registries for keywords. The other is free-form or has a form whose locus of interpretation is either determined by a registered keyword and associated rigid syntax or a very narrow rule about where interpretation of the syntax can occur. We have both with email addresses: A high-level syntax (ignoring source routes, "@" divides things into a left side and a right side. The right side is a domain name (specific syntax and with the DNS itself serving as a registry). The left side can be interpreted only by the destination server and is otherwise pretty much an opaque blob of text. It is no secret that I've never been a big fan of URIs. Much of the reason is that they try to combine the above and do it badly: we've got a method type that has a rigid syntax (case-insensitive ASCII alphanumeric string if I recall) and a registry. After that, the syntax gets method-dependent, with some symbols and strings (varying somewhat by method) having specific syntax and registry structure (e.g., when the locator is a domain name and nothing else is permitted there) and other bits being opaque except to the method or the combination of a method and a particular host or other identifier, or... And syntax is sometimes reserved and sometimes not. At some level, that characterization is unfair because the actual rules are more precise than the above implies. On the other hand, I suggest that the number of people in the community who could actually describe the exact rules to a third party in a reasonably short period of time, without the spec in front of them and without hand waving, and have that third party understand the rules when they are finished is few indeed. But now the this spec presumes to come along and essentially create an overlay on the general URI spec (see below) that reserves a query parameter that can somehow be used even in environments in which normal URI interpretation doesn't permit queries. It isn't clear from a quick reading of the spec whether that is actually intended or whether this is a collection of methods that apply to HTTP 1.1 only -- the text talks about URIs but the cases and examples given appear to be very HTTP (and maybe even HTTP 1.1)-specific. If it were clearly restricted to HTTP/HTTPS URLs, it would be somewhat more palatable because those URIs at least don't prohibit query parts. But the problem is with defining a specific query keyword, across hosts/locations and maybe across methods, for this use. The document doesn't discuss what has been done to demonstrate that they keyword is not in use anywhere else (a nearly impossible task given that there is no registry and no restrictions on such keywords and that they are interpreted on a per-server basis). It should at least discuss what would happen if someone were using this keyword for an entirely different purpose. Presumably such a use would safely fail any OAUTH-related tests, but the effect of OAUTH changing the intent of the original parameter would be, it seems to me, unpredictable. This is not a suggestion because the basic problem would remain, but we have mechanisms that we have tried in the past to at least significantly minimize the risks that a specific keyword or bit of syntax that is newly-introduced into a previously unrestricted or less restricted space will not interfere with an unknown catalog of prior (or even future but unrelated) uses. None of them use anything as generic-sounding as "access_token". If, contrary to the other suggestions here (and Tim's and Mark's comments), the IESG were to go ahead with this spec, the practical risks would be reduced by borrowing notes from IDNA (perhaps "xyz--access_token" or "access-_token") or some of the discussions about alternatives to "x-" (perhaps "oath-bearer.access_token"). Note the deliberately-odd mix of hyphens and underscores in both examples. Unless some syntax can be found that violates the URI specification (or at least the HTTP/HTTPS URL specification, see above) so as to mark a clear boundary between "end of normal URI" and access token information, perhaps the "right" way to do this would be to encapsulate the URI as a payload inside an OATH access package. Another plausible alternative would be to simply eliminate this option by dropping Section 2.3 from the spec. But that leads to a broader issue and criticism: IETF protocols have generally been the most successful when they provide a minimum number of ways to do something, ideally no more than one. This specification provides three (see Section 2), which we normally discourage, at least in the absence of very strong motivation. As far as I can tell (I've read through the spec, but not studied every word), that motivation is not explained in the document, nor are there criteria for which one should be selected under different circumstances (other than the "MUST NOT use...unless" statement about the method in Section 2.2), and there is no mandatory-to-implement provision for clients or servers. If the authors intend to require that all servers support all three models so that clients can do as they like without interoperability issues, they should say so. Otherwise, this is a recipe for interoperability failures (and, if all servers are required to support all methods, it is a requirement for apparently-unnecessary complexity. Recommendation: This specification should not be approved unless either: (i) Two of the three methods are removed, noting that removing 2.3 would eliminate most of the keyword and syntax-related objections. If 2.3 remains, those issues should be dealt with as well. (ii) The document was enhanced with a consensus discussion about why multiple methods are needed, how clients and servers should make decisions about what to actually implement and use, and what, if any methods and features can be depended on for interoperability (e.g., are mandatory to implement). You asked :-( regards, 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