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

[Blaine Cook <[e-mail]>]

On 13 July 2010 20:31, John Kemp <[e-mail]> 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.