The idea that two secrets are better than one is silly since they are both needed for every signed request and therefore must be present in any client/server. There is nothing to stop a client from sharing its credentials together with its token/secret pair.
No, there's nothing to stop it, but the incentives are way different for the two different types of credentials. The client credentials are supposed to be long-lived, and tightly bound to the Client's identity (switching to IETF terminology here). I think of identity certificates as the canonical example -- they last for O(years) and you use them to authenticated to multiple entities. If you give one of these away, you're giving up a lot; you're enabling the recipient to masquerade as you on a large scale.
The token/secret pair is much, much lower-risk. You give up your token credentials and all you're allowing the recipient to do is access the delegated resources.
Using only the token credentials to access protected resources (i.e. no client credentials which are used only to get the token in the first place) offers a valuable simplification which by definition improves security (client credentials are no longer needed in every client and server and can be safeguard just in the parts that issue and request tokens).
This sounds like you're viewing Client hand-off of tokens as a requirement: Client's Delegation Agent does the OAuth dance to get the access token, then passes it off to the Client's Access Agent, who actually does the work.
If there is a requirement to support that deployment pattern, then you're right that you can't require Client authentication on every access. But at the same time, you also can't prevent the Client from handing the token to some third party, so you'll have to document that risk.
Keep in mind that the threats of re-delegation are not security related but simply a matter of trusting third parties not to be stupid about what they do with our data. There is no need for re-delegation to hurt a user... a client can do it all on its own.
I agree, the question here is how much the third party Client is trusted. Authorizing someone to access to a resource and authorizing them to grant others authorization are two different things, though. So it comes down to what the scope is of an OAuth authorization: If the user only wants to allow the Client to access data, then the Server MUST authenticate the Client on access requests. If the user also allows re-delegation, then the Server MUST NOT authenticate the Client on access requests.
It seems like what we need here is to say that Client authentication on access requests is a MUST implement / SHOULD use. Would that make sense?
--Richard
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.