Re: [OAUTH-WG] Defining a maximum token length?

John Kemp <john@jkemp.net> Wed, 10 March 2010 22:24 UTC

Return-Path: <john@jkemp.net>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 945A03A68B2 for <oauth@core3.amsl.com>; Wed, 10 Mar 2010 14:24:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAmRU0xo0Uv0 for <oauth@core3.amsl.com>; Wed, 10 Mar 2010 14:24:01 -0800 (PST)
Received: from outbound-mail-01.bluehost.com (outbound-mail-01.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id E72C53A6830 for <oauth@ietf.org>; Wed, 10 Mar 2010 14:23:55 -0800 (PST)
Received: (qmail 8537 invoked by uid 0); 10 Mar 2010 22:24:01 -0000
Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by cpoproxy1.bluehost.com with SMTP; 10 Mar 2010 22:24:01 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=KLQ7ZHGaiDai/bwcrQc07VH2oSwYkjQla7pRANnMIzY0vE5SlLtvIKS8cwQSqoOMFTB9/S/qglXyx1gMAgOnKnPcR/ph9Y9rWfhXuUwlrlB25cGJ8Ro+uakorSEVzwri;
Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.103]) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from <john@jkemp.net>) id 1NpUJs-0004zo-Rs; Wed, 10 Mar 2010 15:24:01 -0700
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="iso-8859-1"
From: John Kemp <john@jkemp.net>
In-Reply-To: <DB9C8A57-DC10-464C-9E6B-2BEBD0528232@inuus.com>
Date: Wed, 10 Mar 2010 17:23:59 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <C280886E-38E9-4328-AFBD-DCC805B6C0C2@jkemp.net>
References: <fd6741651003091550t5a464496r57aae9a60c516599@mail.gmail.com> <0EC5832F-DE91-437F-96FE-87638A2BCF16@jkemp.net> <4B97C5F9.1020005@sipgate.de> <0693DA9D-980A-4CDD-87EF-12F96D5E8526@jkemp.net> <DB9C8A57-DC10-464C-9E6B-2BEBD0528232@inuus.com>
To: Paul Lindner <lindner@inuus.com>
X-Mailer: Apple Mail (2.1077)
X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net}
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Defining a maximum token length?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Mar 2010 22:24:03 -0000

On Mar 10, 2010, at 3:47 PM, Paul Lindner wrote:

> Standards have size limits to overcome operational issues all the time.

Standards usually standardize on the things necessary for interoperability, and token size isn't a necessity for interoperability unless we make it one. No-one has explained the benefit of doing that yet. 

>  For an extreme example look at the backflips that MIME goes through to insure that mail can be delivered by even the most hostile relay.  (Including systems using EBCDIC, and systems that mangle payloads!)
> 
> If there are no bounds on the size of a token the end result is that some parts of the protocol move from MAY to MUST.  For example, many firewall/proxy services in the wild will truncate URLs and even HTTP headers  much shorter than the 4k normally assumed.    Ergo, POST support is now a MUST.

And in environments without such intermediaries, tokens of much larger sizes may be sent without problems. 

I agree that implementation considerations such as URL length and so on may be relevant in some environments, but I would oppose some mandatory limit in OAuth on token size. 

It's fine, however, to say that if we rely on HTTP as a substrate that we should be governed by any relevant and documented standard HTTP (or other relevant specifications) limits, and provide implementation advice to suggest that in some environments where implementations don't follow the standards, URLs may be truncated by *some implementations* (for example). 

Regards,

- johnk

> 
> On Mar 10, 2010, at 8:30 AM, John Kemp wrote:
> 
>> On Mar 10, 2010, at 11:16 AM, Moritz Maisel wrote:
>> 
>>> On 03/10/2010 04:42 PM, John Kemp wrote:
>>>> One reason I can imagine is to make it possible to encode information into the token itself so that the token can be "self-contained" (mentioned also by others on this list). 
>>>> 
>>> 
>>> Though thats an interesting option, compatibility of implementations
>>> might be easier to achieve by strict specifications like "maximum of 256
>>> characters".
>> 
>> Could you explain why you need to standardize a maximum token length, or why you would want to standardize on implementations of a token store rather than a token-exchange protocol here? 
>> 
>>> 
>>> Just to get an idea about the situation: Is the mentioned
>>> "self-contained token" a common scenario / popular demand that needs to
>>> be covered?
>> 
>> Yes it is. Several people on this list have already mentioned it. 
>> 
>> Regards,
>> 
>> - johnk
>> 
>>> 
>>> Regards,
>>> Moritz
>>> 
>>> -- 
>>> sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf
>>> HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois
>>> Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391
>>> 
>>> www.sipgate.de - www.sipgate.at - www.sipgate.co.uk
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>