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 request. In the "bearer token" case (and even over SSL unless client certs are used), the token clearly SHOULD NOT be used as a password. Rather, authentication should be performed by some other mechanism, unrelated to the token itself (such as an HMAC, or via client-certificate SSL/TLS, or even via an actual username/password) 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". Regards, - johnk > > EHL > > > On 7/13/10 8:55 AM, "Dirk Balfanz" <balf...@google.com> wrote: > > > > On Tue, Jul 13, 2010 at 7:18 AM, Eran Hammer-Lahav <e...@hueniverse.com> > 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, the server doesn't need to store them in plain-text > either (e.g. uses a way one hash). > > That's why we don't call passwords "shared symmetric secrets", either. The > verifier of a passwords can verify it without knowing the secret. In that > sense, it's not "shared" with the verifier. > > I would like the specification to make it clear that bearer tokens are only > secure while they remain *secret* and that *anyone* holding them can gain > full access to what their protect. > > I think the word "capability" expresses that better than the word "shared > secret". > > Dirk. > > > EHL > > On 7/12/10 10:39 PM, "Brian Eaton" <bea...@google.com> wrote: > > > 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 token. Or they verify the > > token cryptographically. Under no circumstances do they need to store > > a copy. > > > > I'd suggest the following language: > > > > "Access tokens are bearer authentication tokens or capabilities." > > > > Cheers, > > Brian > > _______________________________________________ > > 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
