Re: [OAUTH-WG] "shared symmetric secret"

Access tokens should not be stored in plain text either since stealing them is just like stealing a password.

As for cookies, client developers do very little to protect cookies today. While the theory might be similar, in practice, telling a client developer this is just like a cookies doesn't warn them enough.

EHL

On 7/14/10 11:04 PM, "Evan Gilbert" <uidude@google.com> wrote:

"Password" doesn't seem to be the right analogy. You don't (or really shouldn't) store passwords in plain text or in cookies.

How about "cookies"? Most web developers understand that cookies are used as a token that grants access to resources. We've also called these tokens"API cookies" when trying to describe them internally.

On Tue, Jul 13, 2010 at 4:34 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
I'm only using 2828 definition of capability, not password.

EHL

On 7/13/10 3:20 PM, "Zachary Zeltsan" <zachary.zeltsan@alcatel-lucent.com <http://zachary.zeltsan@alcatel-lucent.com> > wrote:

According to the RFC 2828 an access token is rather a capability than a password. The passwords are usually associated with the matching identifiers, but an access token of OAuth 2.0 is used as a single credential that allows access to a protected resource.

>From RFC 2828:
$ password

      (C) A password is usually matched with a user identifier that is
      explicitly presented in the authentication process, but in some
      cases the identity may be implicit.

Zachary
-----Original Message-----
From: oauth-bounces@ietf.org <http://oauth-bounces@ietf.org>  [mailto:oauth-bounces@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
<igor.faynberg@alcatel-lucent.com <http://igor.faynberg@alcatel-lucent.com> > 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

   $ capability
      (I) A token, usually an unforgeable data value (sometimes called a
      "ticket") that gives the bearer or holder the right to access a
      system resource. Possession of the token is accepted by a system
      as proof that the holder has been authorized to access the
      resource named or indicated by the token. (See: access control
      list, credential, digital certificate.)

_______________________________________________
OAuth mailing list
OAuth@ietf.org <http://OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <http://OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth