On Tue, Mar 9, 2010 at 11:02 PM, Luke Shepard 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 let's hear them.
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 g
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 a
On Tue, Mar 9, 2010 at 12:02 PM, David Recordon wrote:
> I'd rather support the client secret and document the hell out of the
> security considerations for the profile.
Thinking out loud... what if we called it the "server you trust to use
username and password profile" instead of the client app
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 si
On Tue, Mar 9, 2010 at 4:44 PM, David Recordon 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. They are
service-s
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
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 large
On 2010-03-09, at 7:50 PM, David Recordon wrote:
> On Tue, Mar 9, 2010 at 7:25 PM, Dick Hardt 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 URLs -- so I don'
On Tue, Mar 9, 2010 at 7:25 PM, Dick Hardt 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 URLs -- so I don't see it as a huge issue.
> I do see the need to make it
On Tue, Mar 9, 2010 at 7: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 bui
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 th
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 desi
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 limitat
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 t
On 2010-03-09, at 4:23 PM, Marius Scurtescu wrote:
> On Tue, Mar 9, 2010 at 3: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
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?
On Tue, Mar 9, 2010 at 4:23 PM, Marius Scurtescu wrote:
> On Tue, Mar 9, 2010 at 3:50 PM, David Recordon wrote:
>> Ideally we'd li
On Tue, Mar 9, 2010 at 3: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).
Add verification codes to the list as well.
> Is this an issue for anyone?
Not
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" wrote:
Ideally
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?
The OAuth 1.0 protocol specifically states:
Clients should avoid making assumptions about the size of tokens and
Sorry, I jumped the gun on my "related note". I don't think I really
understood what was being discussed. So ... er ... ignore that
suggestion please.
Ethan
On Tue, Mar 9, 2010 at 11:23 AM, Justin Smith wrote:
> Part of the motivation behind that profile was to allow an autonomous client
> (no
Ah, now I think I figured it out: x/s means x operations per second.
(Initially, I thought x was the time it took to perform an operation,
and /s was some time measured in one or other fraction of a second.)
Thanks!
Igor
P.S.:Just to state my preferences: I am actually very much for the
publ
Hi Igor,
I don't consider RSA a good option for signing requests from consumer
to resources because of its performance
characteristics. Symmetric algorithms like HMAC are by magnitudes
faster. I did some benachmarking in
a project in 2006. The measurements have been taken on a Windows PC
(Inte
I'd rather support the client secret and document the hell out of the
security considerations for the profile.
On Tue, Mar 9, 2010 at 10:57 AM, Allen Tom wrote:
> The problem with using a client secret for trusted devices is that these
> secrets usually get extracted over time. For obvious reason
On Tue, Mar 9, 2010 at 9:46 AM, David Recordon wrote:
> @Brain, I'm not focused on using this profile for DRM. Rather for
> trusted devices (ideally with TPM) which do not open web browsers
> (such as the XBox).
That sounds a lot like DRM + hardware support. And other folks on
this thread have
The problem with using a client secret for trusted devices is that these
secrets usually get extracted over time. For obvious reasons, I'd rather not
get into the details, but there are many examples of devices whose secrets
are not secret.
The motivation for deliberately excluding the client secr
Yep - mistake on my part. I the discussion was around section 5.1 and 5.2 on
OAuth WRAP v0.9.7.2.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of David
Recordon
Sent: Tuesday, March 09, 2010 9:46 AM
To: oauth-wrap...@googlegroups.com; oauth@ie
@Justin, there's a separate client key and secret profile for making
requests not within the context of a given user.
@Brain, I'm not focused on using this profile for DRM. Rather for
trusted devices (ideally with TPM) which do not open web browsers
(such as the XBox).
--David
On Tue, Mar 9, 20
On Mon, Mar 8, 2010 at 10:33 PM, David Recordon wrote:
> Yes. I was agreeing with your point and suggesting that the profile
> have the client secret added to the request. :)
Just so we're clear on use cases... is the primary use case here DRM,
verifying software on client machines?
Or do folk
Can you clarify what you mean by autonomous? Isn't the wrap_username
an end user identity?
Sent from my iPhone
On Mar 9, 2010, at 8:25 AM, "Justin Smith"
wrote:
> Part of the motivation behind that profile was to allow an
> autonomous client (no end-user identity passed to the AS) the
>
Part of the motivation behind that profile was to allow an autonomous client
(no end-user identity passed to the AS) the ability to access a web service. In
that case, I don't see what the client secret (along with the username and
password) would be adding.
Ethan - assuming the token is signed
Torsten Lodderstedt wrote:
...
I don't consider RSA a good option for signing requests from consumer
to resources because of its performance
characteristics. Symmetric algorithms like HMAC are by magnitudes
faster. I did some benachmarking in
a project in 2006. The measurements have been take
On 2010-03-09, at 7:05 AM, Eve Maler wrote:
>
> It's a good idea to give guidance on how the scope parameter should be used.
> That way, it will help avoid "abuse" of the parameter for other purposes, and
> clashes if different deployments are using it in different ways. (I suspect
> that th
Hi Ethan,
I'm glad I managed to prompt some discussion on the topic!
Thank you very much for initiating this discussion! It will help to
establish a common understanding
of what is required/feasible for the upcoming standard.
RSA vs. HMAC: I really have no idea. On the other hand, Google i
Thanks for your further feedback. Just a couple of comments back (eliding
other portions of the thread):
On 8 Mar 2010, at 2:21 PM, Dick Hardt wrote:
> On 2010-03-05, at 6:57 AM, Eve Maler wrote:
2c. Currently, WRAP doesn't say anything about how to fill the scope
parameter valu
Ah, gotcha, sorry for the misunderstanding. :)
One thing I had thought of to mitigate the risk to the client, or at least
allow the client the ability to see what data is going to be sent to the
provider as "them" would be this: The user connects as 5.3 specifies, upon
success the user is given a
36 matches
Mail list logo
