Here are two related extensions to OAuth. To discuss them, please use the Accessor Secret thread in the Google Group OAuth Extensions.

Extension: Accessor Secret

The Service Provider MUST enable Consumer Developers to establish an Accessor Secret, in addition to the Consumer Key and Consumer Secret. The procedure for establishing the Accessor Secret is entirely up to the Service Provider. The Accessor Secret MAY be empty, or MAY be the same as the Consumer Secret.

The Accessor Secret MUST be used instead of the Consumer Secret, to sign a request for access to a Protected Resource. For example, in the HMAC-SHA1 signature method (OAuth section 9.2), the key is the concatenated values of the Accessor Secret (not the Consumer Secret) and the Token Secret, separated by a '&' character. In the PLAINTEXT signature method, the signature is the concatenated values of the Accessor Secret (not the Consumer Secret) and the Token Secret, separated by a '&' character.

The Accessor Secret MUST NOT be used to sign a request for a token.

When one participant doesn't support this extension, the other participant MUST use an Accessor Secret equal to the Consumer Secret (for compatibility).

Extension: Dynamic Accessor Secret

The Consumer MAY choose a separate Accessor Secret for each Access Token. It MUST send the chosen secret as a parameter named oauth_accessor_secret, in the request to obtain a Request Token (OAuth section 6.1.1).

This parameter MAY be absent, in which case the Service Provider will use the established Accessor Secret. (That's the Consumer Secret, if either participant doesn't support the Accessor Secret extension.)

A Service Provider SHOULD reject a request with an oauth_accessor_secret parameter, if it doesn't support this extension.

Security Considerations

An Accessor Secret enables an attacker to abuse legitimate access tokens. So a dynamic Accessor Secret SHOULD be kept private, and SHOULD be transmitted only via secure channels. SSL or TLS is RECOMMENDED for this purpose. But an Accessor Secret that's empty or widely distributed usually can't be kept secret, so there's little reason to encrypt it.

These extensions can improve security, for a Consumer that has a trusted part that's shared by all users, and a less trusted part for each User, and the less trusted part sends requests directly to the Service Provider for access to Protected Resources. The less trusted part needs to know the Accessor Secret, but need not know the Consumer Secret. So, an attacker can't abuse the less trusted part to obtain the Consumer Secret and then obtain tokens.