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

[Paul Lindner <[e-mail]>]

RFC 2822 <http://www.rfc-editor.org/rfc/rfc2822.txt> provides an apropos
example in sections 2.1.1:

There are two limits that this standard places on the number of
characters in a line. Each line of characters MUST be no more than
998 characters, and SHOULD be no more than 78 characters, excluding
the CRLF.


RFC 2821 <http://www.rfc-editor.org/rfc/rfc2821.txt> has a whole section on
size limits in section 5.4.3.1.

Good reading....

OAuth  has it's own transport related issues, so our MUST limit would
probably be determined by HTTP or other transport considerations.  As a
community we can hopefully come to an agreement on what SHOULD value makes
sense...

I also suggest that error handling around this condition (and everything
else) be nailed down so things don't just break in mysterious ways.
 Remember to SMTP a 500 error is 'line too long'..

On Wed, Mar 10, 2010 at 2:23 PM, John Kemp <[e-mail]> wrote:

> 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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
>
>