Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Defining a maximum token length?
+1 no restriction, please
256 is much too short
Am 10.04.2010 07:16, schrieb Eran Hammer-Lahav:
I would argue that for the spec to provide a token size limit that is greater
than 255 would cause more harm
Subject: Re: [OAUTH-WG] Defining a maximum token length?
+1 no restriction, please
256 is much too short
Am 10.04.2010 07:16, schrieb Eran Hammer-Lahav:
I would argue that for the spec to provide a token size limit that is greater
than 255 would cause more harm than good. This is not to say I am
+1 no restriction, please
256 is much too short
Am 10.04.2010 07:16, schrieb Eran Hammer-Lahav:
I would argue that for the spec to provide a token size limit that is
greater than 255 would cause more harm than good. This is not to say I
am supporting the 255 limit (I take no position on the
Hi Allen,
as I already posted, I don't think a size limit is a good idea.
Regarding your example: As per RFC-2109, 4KB is the minimum size that
must be supported by user agents. The maximum size is not restricted:
In general, user agents' cookie support should have no fixed limits..
Let's finish off the thread on token length limits.
In summary, David Recordon proposed a length limit of 255 characters due to
database length limits (blobs versus shorter and indexable types such as
varchars). Several people were opposed to the 255 length limit. However, there
was general
On Fri, Apr 9, 2010 at 3:14 AM, Luke Shepard lshep...@facebook.com wrote:
Let's finish off the thread on token length limits.
In summary, David Recordon proposed a length limit of 255 characters due to
database length limits (blobs versus shorter and indexable types such as
varchars).
, 2010 12:12 PM
To: Luke Shepard
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Defining a maximum token length?
On Fri, Apr 9, 2010 at 3:14 AM, Luke Shepard lshep...@facebook.com wrote:
Let's finish off the thread on token length limits.
In summary, David Recordon proposed a length limit of 255
I think a good precedent would be to use the HTTP Cookie size limit, which
is 4KB.
An OAuth Access Token is like an HTTP Authorization cookie. They're both
bearer tokens that are used as a credentials for a client to access
protected resources on behalf of the end user.
All Oauth clients have to
I would argue that for the spec to provide a token size limit that is greater
than 255 would cause more harm than good. This is not to say I am supporting
the 255 limit (I take no position on the matter - yeah, that happens rarely).
If the spec provided a 4K limit, client libraries are likely
Hi,
It appears that people agree excessive token length could be an issue
for interoperability, but opinions vary on how long tokens
could/should/must be. Relatively long tokens will occur when encoding
data associated with the user (access rights, group memberships, etc.),
and integrity
On Fri, Mar 19, 2010 at 8:44 AM, jbem...@zonnet.nl wrote:
Hi,
It appears that people agree excessive token length could be an issue for
interoperability, but opinions vary on how long tokens could/should/must be.
Relatively long tokens will occur when encoding data associated with the
user
Eaton
Sent: Tuesday, March 09, 2010 11:35 PM
To: Luke Shepard
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Defining a maximum token length?
On Tue, Mar 9, 2010 at 11:02 PM, Luke Shepard lshep...@facebook.com wrote:
I'd still like to see someone construct an example access token that is
longer than 255
On Mar 9, 2010, at 6:50 PM, David Recordon wrote:
Ideally we'd limit the length of access and refresh tokens as well as
client keys and secrets to no more than 255 characters (a one byte
varchar in MySQL). Is this an issue for anyone?
Yes.
Why would we want to encode such a specific
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
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
Standards have size limits to overcome operational issues all the time. 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
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
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
No issue, and there is certainly precedent. SAML 2.0 specifies the following
about persistent name identifiers, which would be similar is use and formfactor:
Persistent name identifier values MUST NOT exceed a length of 256 characters
-cmort
On 3/9/10 3:50 PM, David Recordon
On Tue, Mar 9, 2010 at 3:50 PM, David Recordon record...@gmail.com wrote:
Ideally we'd limit the length of access and refresh tokens as well as
client keys and secrets to no more than 255 characters (a one byte
varchar in MySQL).
Add verification codes to the list as well.
Is this an issue
On 2010-03-09, at 4:23 PM, Marius Scurtescu wrote:
On Tue, Mar 9, 2010 at 3:50 PM, David Recordon record...@gmail.com wrote:
Ideally we'd limit the length of access and refresh tokens as well as
client keys and secrets to no more than 255 characters (a one byte
varchar in MySQL).
Is this
Agreed. I've heard tell of Yahoo access tokens with encoded
information weighing in at up to 800 characters. I don't see anything
necessarily wrong with this and I don't think there's much reason to
limit it in the spec. It could incur a significant bandwidth cost, but
since the provider is going
On 2010-03-09, at 6:24 PM, Ethan Jewett wrote:
I think it would make sense to advise client library and application
programmers to provide for the possibility of and storage of large
tokens. We should probably reference examples of tokens seen in the
wild and mention the technical
The challenge is that client developers (who we really want to make
OAuth dead simple for) will be forced to use less optimal storage for
tokens (blobs versus shorter and indexable types such as varchars).
They also won't be able to build any assumptions around token length
into their database
I understand the desire to set a max length that can easily fit into a DB.
There are lots of other items I think the developer is storing that can be
long as well, like URLs -- so I don't see it as a huge issue.
I do see the need to make it clear that it can be a few K or something like
that so
On Tue, Mar 9, 2010 at 7:16 PM, David Recordon record...@gmail.com wrote:
The challenge is that client developers (who we really want to make
OAuth dead simple for) will be forced to use less optimal storage for
tokens (blobs versus shorter and indexable types such as varchars).
They also
On 2010-03-09, at 7:50 PM, David Recordon wrote:
On Tue, Mar 9, 2010 at 7:25 PM, Dick Hardt dick.ha...@gmail.com wrote:
I understand the desire to set a max length that can easily fit into a DB.
There are lots of other items I think the developer is storing that can be
long as well, like
Hi David,
I wouldn't restrict the length of a tokens to 255 characters, especially
for access tokens.
Our proprietary token service today uses a token type combination
similar to OAUTH refresh and access tokens. Based on our experiences I
would assume the following characteristics of a
Whoa- are we seriously saying we need more than 255 characters to encode a
token? (By the way, that's 10^396 combinations, with letters and numbers.)
Having short tokens makes the whole protocol much simpler, more approachable,
easy to use for developers. I will push hard to keep them short and
On Tue, Mar 9, 2010 at 4:44 PM, David Recordon record...@gmail.com wrote:
I believe that Google wishes to encode information within access
tokens so that they can be verified in a stateless manner. Brian, how
many characters do you need?
I think it would be OK to make request tokens short.
Hi,
Whoa- are we seriously saying we need more than 255 characters to encode a
token? (By the way, that's 10^396 combinations, with letters and numbers.)
yes. As I said, in our approach we put permissions and attributes into
the tokens.
Having short tokens makes the whole protocol much
On Mar 9, 2010, at 8:16 PM, David Recordon wrote:
The challenge is that client developers (who we really want to make
OAuth dead simple for) will be forced to use less optimal storage for
tokens (blobs versus shorter and indexable types such as varchars).
They also won't be able to build any
I'd still like to see someone construct an example access token that is longer
than 255 characters that would be reasonably used. If there are real,
legitimate use cases that REQUIRE more than that many characters, then let's
hear them. I don't think that appealing to it might be useful is a
On Tue, Mar 9, 2010 at 11:02 PM, Luke Shepard lshep...@facebook.com wrote:
I'd still like to see someone construct an example access token that is
longer than 255 characters that would be reasonably used. If there
are real, legitimate use cases that REQUIRE more than that many
characters, then
34 matches
Mail list logo
