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

Julian Reschke <julian.reschke@gmx.de> Thu, 12 April 2012 13:09 UTC

Return-Path: <julian.reschke@gmx.de>
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 1026121F856C for <apps-discuss@ietfa.amsl.com>; Thu, 12 Apr 2012 06:09:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.053
X-Spam-Level:
X-Spam-Status: No, score=-103.053 tagged_above=-999 required=5 tests=[AWL=-0.454, 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 yLGYLlrYxNPq for <apps-discuss@ietfa.amsl.com>; Thu, 12 Apr 2012 06:09:15 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 0D02A21F854E for <apps-discuss@ietf.org>; Thu, 12 Apr 2012 06:09:14 -0700 (PDT)
Received: (qmail invoked by alias); 12 Apr 2012 13:09:13 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp036) with SMTP; 12 Apr 2012 15:09:13 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+X+UxJ7OKX5XQhT54Q02s03gTb4Y1svNYghzJqhs Z2RMvE3Q5PG7bS
Message-ID: <4F86D3F5.9020802@gmx.de>
Date: Thu, 12 Apr 2012 15:09:09 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Eran Hammer <eran@hueniverse.com>
References: <4F866AC0.3000603@qualcomm.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE2816@P3PWEX2MB008.ex2.secureserver.net>
In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FE2816@P3PWEX2MB008.ex2.secureserver.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
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 13:09:16 -0000

On 2012-04-12 14:56, Eran Hammer 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
> ...

It is.

Right now the spec describes the two fallback methods and the auth 
scheme side-by side.

Maybe it should be reorganized so that is only mentions the 
query-parameter and form-based schemes as workarounds in an appendix, so 
that it becomes clearer that when you use those, you're *not* doing HTTP 
Bearer authentication?

Best regards, Julian