Neither the secret key nor the passphrase nor the signature are actually needed to ensure the security and authenticity of customers' API requests. The API key is already sufficiently large (128 bits) to avoid a brute force attack, and it's never transmitted except over an encrypted (SSL) connection, and the client won't send it if the server's certificate doesn't validate, so neither a MITM nor an eavesdrop are possible. Also, SSL does already include nonces, so a replay attack is not possible, and thus the nonce field is unneeded, too.

Of course, there is still the possibility of a database dump, which would reveal all API keys to the attacker. Really, you should be requiring client-certificate authentication on the SSL connections to the API server, and your database should contain certificates for all of your API users. Then it wouldn't matter if an attacker obtained a dump of your database; they still couldn't pretend to be any of your users because they wouldn't have the private keys associated with those certificates.

Basically, all of these extra HTTP header fields are clumsy attempts to solve a problem that is already solved in SSL. And by the way, you're supposed to prefix non-standard header field names with "X-" so they don't conflict with any future standards.