Why does deterministic ECDSA (per RFC 6979) include the private key in the generation of k?

It's clear that using the private ECDSA key $$x$$ as an additional input into the hash algorithm, as specified in RFC 6979, doesn't harm security (assuming HMAC_DRBG is a PRF).

But is it necessary?

Would there be any problem with allowing the signature algorithm to have the same output of $$k$$ for the same message regardless of the key used? Per Is it safe to reuse a ECDSA nonce for two signatures if the public keys are different?, it seems like this should be fine.

If key dependency is indeed the goal here, why is the private key used, and not the public key?

Using the public key, or removing any key dependence entirely, would seem to allow verifying whether a given implementation is using deterministic signatures, which seems like a desirable property in some contexts. For example, it would allow detecting whether a given implementation uses deterministic signatures without knowledge of the private key by observing one or more signatures.

Am I missing something?

What is necessary is that someone else could not guess what $$k$$ was; after all, if they guessed that, they could recover the private key from the signature with a bit of simple algebra.
If they used only public information (the public key and the message), well, the attacker could compute $$k$$ himself, and that'd be bad.
• Thanks – I completely missed that $k$ has to be secret as well as unpredictable and a nonce!