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

Dick Hardt <dick.hardt@gmail.com> Wed, 18 April 2012 21:33 UTC

Return-Path: <dick.hardt@gmail.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 007FA11E8094 for <apps-discuss@ietfa.amsl.com>; Wed, 18 Apr 2012 14:33:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.561
X-Spam-Level:
X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 fSj7EruQs-NM for <apps-discuss@ietfa.amsl.com>; Wed, 18 Apr 2012 14:33:16 -0700 (PDT)
Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8F411E8097 for <apps-discuss@ietf.org>; Wed, 18 Apr 2012 14:33:16 -0700 (PDT)
Received: by dady13 with SMTP id y13so14353400dad.27 for <apps-discuss@ietf.org>; Wed, 18 Apr 2012 14:33:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=IoyzWbT37Vh64MY8b/RHmJzfDGfIzaveQdMbVO4AuEU=; b=PlzShUFbWS9QbjXZ3Bsw7FOE70eyUcTQTh63Br+6MeWXzE7VBZusLDPRDkAcYvvNlr yE9Gw5Zo6FM5zub+dvjJ4T1goH9e0wnG1ZCYiyPudTcz7/0apfI4VulOEtB/d7SrPECP hf6kTgXegsAcpLDa1DtSqwK5o3fYS+ZOL4rv37zn2B+A6Dx9qRokjVgrMbri45NB/32M r/+54YJhtQXkhOWAaw5u4Q4Uy7/+ut9FX1ELqoIjLqaX2Wm714+T94y+cgv4PV0KCrCv O9VjcIYBV4+88DAthif54FZLPHo1PXUz2Ol0pFnjWi76HMzqnOhth39rsFMff2intEYT qtWQ==
Received: by 10.68.138.195 with SMTP id qs3mr9543473pbb.91.1334784796022; Wed, 18 Apr 2012 14:33:16 -0700 (PDT)
Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id nt3sm225425pbc.14.2012.04.18.14.33.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Apr 2012 14:33:14 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset="us-ascii"
From: Dick Hardt <dick.hardt@gmail.com>
In-Reply-To: <075265B2-9C33-40D6-B9F7-707027502850@mnot.net>
Date: Wed, 18 Apr 2012 14:33:12 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D1453B78-DD59-4B92-98C5-18C1D0D25B5A@gmail.com>
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> <8173C795-AC92-4E54-8D1C-18A88BFE1AC2@mnot.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FEFD38@P3PWEX2MB008.ex2.secureserver.net> <3E66A1C7-97B7-43FE-A851-791F33C4A372@gmail.com> <075265B2-9C33-40D6-B9F7-707027502850@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
X-Mailer: Apple Mail (2.1257)
X-Mailman-Approved-At: Thu, 19 Apr 2012 07:48:55 -0700
Cc: Ned Freed <ned.freed@mrochek.com>, Apps Discuss <apps-discuss@ietf.org>, "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" <draft-ietf-oauth-v2-bearer.all@tools.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 21:33:17 -0000

On Apr 18, 2012, at 2:11 PM, Mark Nottingham wrote:

> 
> On 18/04/2012, at 1:49 PM, Dick Hardt wrote:
>> 
>> Mark:
>> 
>> Would you point me to where this is bad practice as opposed to bad web architecture?
> 
> What are you looking for here?

From your comment:

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


I looked through the thread and there was discussion comment about the security issue of the token being part of the URL and being in logs, caches etc. 

I was looking for the list or discussion or whatever where this method had been identified this as not a good practice. I apologize if it is somewhere obvious that I did not find. It would be a good basis for documentation per below.

> 
>> This is the only way to pass the parameter if doing JSONP -- there is no access to the headers. 
>> 
>> Many sites with substantial security expertise (Google, Facebook, LinkedIn, Foursquare) have chosen to use the query parameter as opposed to the header - both methods have been documented in the drafts since the beginning. Clearly from a practical point of view the implementors have chosen to use the query parameter. 
>> 
>> When I use the term hack, I am referring to people building things independent of specs because they are needing unspecified functionality. I am not talking about some hackers.
>> 
>> Having been building systems for some time, I fully appreciate the long term issues with name spaces, and having a query parameter is not the ideal solution, but given where the world is now, using a query parameter is what everyone is choosing -- and I have yet to hear a good reason why it is a bad solution -- and there is no known alternative to working with JSONP.
>> 
>> All the OAuth 2 deployments I have seen have been to fresh URLs where name collision with oath_token is a non issue. Calling it the parameter "token" would clearly be less than ideal, and lead to the issues that JSONP has with "callback"
>> 
>> Reserved words is one of those nasty gotchas that many languages have, that have been solved by prefix hacks such as leading underscores etc. or leading 'x-'
> 
> I understand all of that. This thread has been about the difference between documenting this kind of practice as a necessarily ~evil and recommending it (with the voice of the IETF).

I have have read people proposing dropping it from the spec or pushing it to an Appendix. I agree the that the security issues need to be documented and the architectural issues called out. I think dropping it form the spec or pushing it to an appendix is a disservice to implementors and sends a message that the IETF is not in touch with the realities of the web.