t in some
> cases the identity may be implicit.
>
> Zachary
> -Original Message-
> From: oauth-boun...@ietf.org <http://oauth-boun...@ietf.org> [
> mailto:oauth-boun...@ietf.org ] On Behalf Of Brian
> Eaton
> Sent: Tuesday, July 13, 2010 4:43 PM
>
ry
-Original Message-
From: oauth-boun...@ietf.org <http://oauth-boun...@ietf.org>
[mailto:oauth-boun...@ietf.org] On Behalf Of Brian Eaton
Sent: Tuesday, July 13, 2010 4:43 PM
To: Faynberg, Igor (Igor)
Cc: OAuth WG
Subject: Re: [OAUTH-WG] "shared symmetric secret"
On Tue, Jul
boun...@ietf.org
> [mailto:oauth-boun...@ietf.org]
> On Behalf Of Brian Eaton
> Sent: Tuesday, July 13, 2010 4:43 PM
> To: Faynberg, Igor (Igor)
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] "shared symmetric secret"
>
> On Tue, Jul 13, 2010 at 1:40 PM, Igor Faynberg
>
implicit.
Zachary
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian
Eaton
Sent: Tuesday, July 13, 2010 4:43 PM
To: Faynberg, Igor (Igor)
Cc: OAuth WG
Subject: Re: [OAUTH-WG] "shared symmetric secret"
On Tue, Jul 13, 2010 at 1:40 PM
ian
Eaton
Sent: Tuesday, July 13, 2010 4:43 PM
To: Faynberg, Igor (Igor)
Cc: OAuth WG
Subject: Re: [OAUTH-WG] "shared symmetric secret"
On Tue, Jul 13, 2010 at 1:40 PM, Igor Faynberg
wrote:
> In this case, the term "capability" MUST be defined up front. The word
> "
This is how OAuth works: The client wants to access a protected resource. The
resource requires authentication (that's the definition of protected). The
client presents the access token to authenticate (using an HTTP authentication
header). The access token has all the security characteristics o
YES!!!
Brian, could you please add this?
Igor
Brian Eaton wrote:
On Tue, Jul 13, 2010 at 1:40 PM, Igor Faynberg
wrote:
In this case, the term "capability" MUST be defined up front. The word
"capability" seems to carry a much broader meaning than password...
It has a standard defini
On Jul 13, 2010, at 4:06 PM, Blaine Cook wrote:
> On 13 July 2010 20:31, John Kemp wrote:
>> Where is that specified? Is that required for all implementations?
>
> It's not specified - I was referring to your earlier comments:
>
>> In the "bearer token" case (and even over SSL unless client ce
I'll work with this text.
EHL
On 7/13/10 1:35 PM, "Brian Eaton" wrote:
On Tue, Jul 13, 2010 at 1:06 PM, Blaine Cook wrote:
> Don't leak it, and treat it as though it were a
> password", then we avoid having to explain (embarrassingly) that the
> "capability" actually meant something like "pas
On Tue, Jul 13, 2010 at 1:40 PM, Igor Faynberg
wrote:
> In this case, the term "capability" MUST be defined up front. The word
> "capability" seems to carry a much broader meaning than password...
It has a standard definition we can reference. From
http://www.ietf.org/rfc/rfc2828.txt
$ capab
In this case, the term "capability" MUST be defined up front. The word
"capability" seems to carry a much broader meaning than password...
Igor
Brian Eaton wrote:
On Tue, Jul 13, 2010 at 1:06 PM, Blaine Cook wrote:
Don't leak it, and treat it as though it were a
password", then we avoid h
On Tue, Jul 13, 2010 at 1:06 PM, Blaine Cook wrote:
> Don't leak it, and treat it as though it were a
> password", then we avoid having to explain (embarrassingly) that the
> "capability" actually meant something like "password".
For the initiated, that's what "capability" means.
How about this
On 13 July 2010 20:31, John Kemp wrote:
> Where is that specified? Is that required for all implementations?
It's not specified - I was referring to your earlier comments:
> In the "bearer token" case (and even over SSL unless client certs are used),
> the
> token clearly SHOULD NOT be used as
On Jul 13, 2010, at 3:03 PM, Blaine Cook wrote:
> +1 on "like a password", or something similar-and-meaningful because
> that's exactly how it's being used here. Pre-shared key, shared
> secret, etc, would be fine. Keep in mind that authentication *will be
> done* using the bearer token, and the b
+1 on "like a password", or something similar-and-meaningful because
that's exactly how it's being used here. Pre-shared key, shared
secret, etc, would be fine. Keep in mind that authentication *will be
done* using the bearer token, and the bearer token alone.
An OAuth token is unlike capabilities
On Jul 13, 2010, at 2:46 PM, Richer, Justin P. wrote:
>>> I would be very unhappy if we equated access tokens with passwords.
>>>
>>> I agree with Dirk that "capability" is a more expressive phrase than either
>>> "shared secret" or "password".
>
>> Expressive to you and people well-versed in se
>> I would be very unhappy if we equated access tokens with passwords.
>>
>> I agree with Dirk that "capability" is a more expressive phrase than either
>> "shared secret" or "password".
> Expressive to you and people well-versed in security theory. It means
> nothing to a casual reader. The token
Hi Eran,
On Jul 13, 2010, at 1:40 PM, Eran Hammer-Lahav wrote:
>
> On 7/13/10 10:25 AM, "John Kemp" wrote:
>
>> On Jul 13, 2010, at 12:02 PM, Eran Hammer-Lahav wrote:
>>
>>> I am ok replacing it with Oacts as a password¹.
>>
>> An access token is something used by the server to decide whethe
On 7/13/10 10:25 AM, "John Kemp" wrote:
> On Jul 13, 2010, at 12:02 PM, Eran Hammer-Lahav wrote:
>
>> I am ok replacing it with Oacts as a password¹.
>
> An access token is something used by the server to decide whether a request is
> authorized. Although it may also be used for authenticating
On Jul 13, 2010, at 12:02 PM, Eran Hammer-Lahav wrote:
> I am ok replacing it with ‘acts as a password’.
An access token is something used by the server to decide whether a request is
authorized. Although it may also be used for authenticating the request(er),
it's purpose is to authorize the r
New text:
Clients access protected resources by presenting an access token to the
resource server.
Access tokens are bearer tokens, where the token string acts as a
password. This requires
treating the access token with the same care as other passwords. Access
tokens SHO
I am ok replacing it with 'acts as a password'.
EHL
On 7/13/10 8:55 AM, "Dirk Balfanz" wrote:
On Tue, Jul 13, 2010 at 7:18 AM, Eran Hammer-Lahav wrote:
>From the client's perspective, they are 'shared symmetric secrets' because
the client has to store them as-is and present them as-is. The
On Tue, Jul 13, 2010 at 7:18 AM, Eran Hammer-Lahav wrote:
> From the client's perspective, they are 'shared symmetric secrets' because
> the client has to store them as-is and present them as-is. The act exactly
> like passwords. I added that text to make that stand out.
>
> When using passwords,
I tend to agree with Eran, although it should be qualified that a token
is BASED on a shared secret, rather than is a shared secret itself. (By
the way, I think the word "symmetric" is redundant here.).
I also think that the text in the Security Considerations must contain
the last paragraph o
>From the client's perspective, they are 'shared symmetric secrets' because
the client has to store them as-is and present them as-is. The act exactly
like passwords. I added that text to make that stand out.
When using passwords, the server doesn't need to store them in plain-text
either (e.g. us
Section 5: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5
Calling access tokens "shared symmetric secrets" is misleading,
because if they are implemented well the authorization server and
protected resource do not store a copy of the secret.
Instead they store a one-way hash of the t
26 matches
Mail list logo
