"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 <e...@hueniverse.com>wrote: > I’m only using 2828 definition of capability, not password. > > EHL > > > > On 7/13/10 3:20 PM, "Zachary Zeltsan" <zachary.zelt...@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-boun...@ietf.org > [mailto:oauth-boun...@ietf.org<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 > <igor.faynb...@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 > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
