clarify strongly recommended guidance from NIST

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.

Start with PR #380 and the referenced discussion about the apu and apv headers, then compare RFC 7518 with Appendix B and Section 5.8 of NIST SP 800-56A. Document the rationale for the decision on whether additional guidance is needed and make the resulting specification guidance unambiguous.