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" <[email protected]> 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 <[email protected]> wrote: I'm only using 2828 definition of capability, not password. EHL On 7/13/10 3:20 PM, "Zachary Zeltsan" <[email protected] <http://[email protected]> > 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: [email protected] <http://[email protected]> [mailto:[email protected]] 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 <[email protected] <http://[email protected]> > 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 [email protected] <http://[email protected]> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] <http://[email protected]> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
