On 13 July 2010 20:31, John Kemp <j...@jkemp.net> 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 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. The token is never used as the authentication mechanism (i.e., the mechanism to authenticate the user), except in schemes where it explicitly makes sense (e.g., UMA as I understand it, Twitter's OAuth Echo, etc). So there's no concern about that. What I was trying to say, and I'm just re-iterating Eran's comments here, is that once issued [in the context of a request made by an authenticated user that grants authorization to the OAuth client], the token will be used de-facto as a password, passphrase, shared secret, or whatever we want to call it. By calling it a "capability", we don't signal to implementors what the security implications are, and what they can do to avoid disappointment. > A capability, basically, is a reference to an object and the permission to > use it, bound together. Possession of the capability is enough to authorize > the use of the reference. Bearer tokens follow roughly that model. They are > about authorization and MAY be used alone for authentication, but may also be > used with (specified, or not, in OAuth) other mechanisms for authentication. > At least I hope that is the model (not to *require* servers to authenticate > using the bearer token alone even if *some* implementations do that)? It's unclear what you mean is being authenticated by the server – do you mean the user, or the client, or something else? This question is persistent and points to exactly the kind of confusion I think Eran is correct to try to avoid by simply calling the token password-like. If we use language that clearly indicates to developers that "with the clear-text token, requests can be made [modulo reduced permissions] as though they were made by someone in possession of the user's username and password. 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". b. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
