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