clarify strongly recommended guidance from NIST

[Sakurann]

In PR #380, @martijnharing pointed out that

RFC 7518 also says that:

Applications need to specify how the "apu" and "apv" Header
   Parameters are used for that application.  The "apu" and "apv" values
   MUST be distinct, when used.  Applications wishing to conform to
   [[NIST.800-56A](https://datatracker.ietf.org/doc/html/rfc7518#ref-NIST.800-56A)] need to provide values that meet the requirements of
   that document, e.g., by using values that identify the producer and
   consumer.

So I think we need to normatively specify how the apu and apv header are used (which could be that they must be empty). I'm not sure what the exact implications are for the requirements regarding NIST 800-56A. Is anyone familiar with making the use of ECDH-ES compliant to NIST 800-56A?

NIST document is here https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf and the text is

Appendix B: Rationale for Including Identifiers in the KDF Input
It is strongly recommended that identifiers for both parties to a key-agreement transaction be
included among the data input to the key-derivation method – as a simple and efficient means of
binding those identifiers to the derived keying material. (See Sections 5.8.)

Current discussion is not to add more guidance to apu and apv because as noted here...

Given that the nonce is part of the encrypted payload, it already contributes to the cryptographic output. Therefore also using it as the "apu" value is redundant.

Likewise, the Client ID is part of the encrypted content, and so need not also be in "apv".

Creating a thread to document why not, or why should we.