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

Mark Nottingham <mnot@mnot.net> Wed, 18 April 2012 19:00 UTC

Return-Path: <mnot@mnot.net>
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 DE0D811E8080 for <apps-discuss@ietfa.amsl.com>; Wed, 18 Apr 2012 12:00:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.98
X-Spam-Level:
X-Spam-Status: No, score=-105.98 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, 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 eWAM+Fi8XNye for <apps-discuss@ietfa.amsl.com>; Wed, 18 Apr 2012 11:59:56 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 888FB11E8085 for <apps-discuss@ietf.org>; Wed, 18 Apr 2012 11:59:56 -0700 (PDT)
Received: from [172.16.11.154] (unknown [12.197.88.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 48CB622E25D; Wed, 18 Apr 2012 14:59:52 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset="windows-1252"
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <217479C6-A2F8-4A06-A53E-E6BF4D1AB410@gmail.com>
Date: Wed, 18 Apr 2012 11:59:47 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <8173C795-AC92-4E54-8D1C-18A88BFE1AC2@mnot.net>
References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> <22B64109-DAFD-4F2A-B1DA-5950E732882A@mnot.net> <4F88AA3A.8040401@cs.tcd.ie> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE83A2@P3PWEX2MB008.ex2.secureserver.net> <0608087F-1F83-4D19-9BA2-F2C58ED33F31@gmail.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FECDB0@P3PWEX2MB008.ex2.secureserver.net> <5837DDA7-19DC-4452-BD47-FFF6C674E179@gmail.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FEE3DF@P3PWEX2MB008.ex2.secureserver.net> <217479C6-A2F8-4A06-A53E-E6BF4D1AB410@gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
X-Mailer: Apple Mail (2.1257)
Cc: Ned Freed <ned.freed@mrochek.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>, Pete Resnick <presnick@qualcomm.com>
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: Wed, 18 Apr 2012 19:00:01 -0000

On 18/04/2012, at 10:26 AM, Dick Hardt wrote:

> Thanks Eran, I think I understand.
> 
> To restate what you have said, specifying a query parameter as part of the spec is "bad" web architecture and potentially sets a precedent for other specifications to reserve a query parameter. Correct?
> 
> The reality is that the world is a messy place. Developers hack the architecture to accomplish goals not envisioned by the architects. The architects can accept the reality of the world, or ignore it and lose their relevance. In my opinion, putting the query parameter mechanism into an appendix is ignoring the reality of current implementations. Adding language to the spec that use of the query parameter is not architecturally ideal, but accepts the reality of the current web would be far more preferable.

… Except that AIUI that method has been identified as not good practice for entirely practical reasons, independent of the architectural reasons.

Putting that aside, there's a large difference between acknowledging and documenting broad practice that's bad and sanctioning its use to encourage further abuses.

Believe it or not, things like this *do* affect real people -- just not the "hackers" who are working on OAuth. It affects people who run real Web sites, because they have to consider what query parameters they can use in their apps without danger of colliding with OAuth or the future extensions that mimic it (do you *really* think this is going to be the Last Authentication Scheme in the World?). It affects the folks who have to figure out how to graft this mechanism onto existing systems that already use the parameter name you've chosen.

I really don't want to have to go through a list of 50 such "reserved" query parameters every time I write a new Web app in ten years. Sorry if having a perspective that's further out than my nose gets me out of the "hacker" bucket into the dreaded "architect" camp. Deploying and maintaining extremely large systems over a long period of time has taught me that it's a good idea. YMMV.

Thanks,

>  
> -- Dick
> 
> On Apr 17, 2012, at 8:28 PM, Eran Hammer wrote:
> 
>> A site has a bunch of APIs. They want to use OAuth with Bearer tokens. They can no longer use the access_token parameter for their own use cases because the Bearer token specification creates a conflict. This conflict does not exist with the use of the header. It does exist with the use of the body if they have an access_token parameter already in use.
>>  
>> The API format has nothing to do with OAuth, but the use of a query parameter leaks into that namespace.
>>  
>> This isn’t a critical issue. It is a hack – it has always been since it was introduced in OAuth 1.0. The issue raised was about web architecture in general and setting a precedence. I don’t think it will likely to create real-world problems, but the same goes for not supporting this use case anymore (or at least explicitly marking it as deprecated, maybe even demoted to an appendix documenting historical use).
>>  
>> While the violation of the provider namespace is a significant principal, I want to make sure my view isn’t coming off as some severe warning. Either way, it is not a big deal IMO.
>>  
>> EH
>>  
>> From: Dick Hardt [mailto:dick.hardt@gmail.com] 
>> Sent: Tuesday, April 17, 2012 12:32 PM
>> To: Eran Hammer
>> Cc: Dick Hardt; Stephen Farrell; Mark Nottingham; Pete Resnick; Ned Freed; draft-ietf-oauth-v2-bearer.all@tools.ietf.org; Apps Discuss
>> Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer
>>  
>> Please elaborate on what the issue is then as protecting API resources is what OAuth is all about. 
>>  
>> On Apr 17, 2012, at 12:19 PM, Eran Hammer wrote:
>> 
>> 
>> That has nothing to do with this issue. The protected resources API format was never part of OAuth at any time.
>>  
>> EH
>>  
>> From: Dick Hardt [mailto:dick.hardt@gmail.com] 
>> Sent: Tuesday, April 17, 2012 9:50 AM
>> To: Eran Hammer
>> Cc: Stephen Farrell; Mark Nottingham; Pete Resnick; Ned Freed; draft-ietf-oauth-v2-bearer.all@tools.ietf.org; Apps Discuss
>> Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer
>>  
>>  
>> On Apr 14, 2012, at 11:31 PM, Eran Hammer wrote:
>> 
>> 
>> 
>> (Sticking with the naivety:-) So, what's different there from how the base
>> oauth draft registers client_id and shows how that can be used in a GET
>> request? [1]
>> 
>> Big difference. The base draft specifies its own endpoints as part of a complete API package for obtaining authorization. These parameters are scoped only for the endpoints defined and not for any others. There is no possibility of conflict because the specification defines the entire namespace.
>> 
>> OTOH, the bearer spec is applied to *any* web resources using OAuth authentication where some other namespace definition must exist.
>>  
>>  
>> If we had kept it all in one spec as it had originally been drafted, this would not be an issue, and it would be easier for implementers to understand. I don't know of anyone looking to implement the bearer spec independent of the base spec. (would be interested if anyone does know of an implementation)
> 

--
Mark Nottingham
http://www.mnot.net/