key attestation in the jwt proof header should be able to be pre-generated...

The intent of having both attestation and jwt proof types was the following:
A. jwt proof type: key_attestation in the jwt proof header can be pre-generated (attested keys in the attestation can also be pre-generated), and jwt proof signed using one of the attested keys needs to be generated fresh since it contains nonce from the issuer.
B. attestation proof type: all attested keys can be pre-generated, and key attestation needs to be generated fresh since it contains nonce from the issuer.

However, there is this text for key_attestation in the jwt proof header, which defeats the intent above because key attestation in jet proof type cannot be pre-generated since it needs to contain a nonce:

key_attestation: OPTIONAL. JOSE Header containing a key attestation as described in Appendix D. If the Credential Issuer provided a c_nonce, the nonce claim in the key attestation MUST be set to a server-provided c_nonce.

original issue #438 pointed to a nonce claim in key attestation jwt itself but the PR #501 added clarification to key attestation claim in the jwt header itself

I think we have two options (still investigating feasibility of both; not advocating for any of these at this point):

1. do an errata of VCI and fix the above by removing "If the Credential Issuer provided a c_nonce, the nonce claim in the key attestation MUST be set to a server-provided c_nonce."
2. define a new proof type in VCI 1.1 that achieves the purpose A above that jwt proof type was supposed to achieve
3. define a new proof type in HAIP 1.0 that achieves the purpose A above that jwt proof type was supposed to achieve

Read the key_attestation requirements in Appendix F.1-2.1.2.6 and the nonce claim text in Appendix D.1-4.1.2.7. Review original issue #438 and PR #501, then follow the discussion to determine whether the specification needs an errata or a new proof type. Done means reaching and documenting a decision for the conflicting requirements.