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.

[Sakurann]

This has been discussed in DCP WG on Apr-22nd. Minutes: https://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/Week-of-Mon-20250421/000756.html

The following guidance was provided by NIST on that call:

• NIST SP 800 does not strictly require APU/APV to be conformant (recommended, not required) and if the motivation is mainly compliance to SP 800, then there is no need to worry about it.
• the language in 800 will be cleaned up and the intent was not to make this a requirement (APU/APV not being null).
• If the main goal is to protect against a lazy verifier, then including values in the KDF computation can help, but only if those values are generated independently. If APU/APV values are being sent (not detached), then it might not really help with lazy verifiers. If implicit values cannot be used, then there might still be some benefit, but limited and a discussion if that is really needed is fair to have.
• It is arguably a "hygiene" issue, but there doesn't seem to be a clear benefit (of defining APU/APV values if they are explicit) and that Andrew was confused by the relation to the lazy verifier problem.