Change:
I added a recommendation as well. I think this can be merged.
Looks fine to me, merging
states Then has which is using -15 (SHA-256/64), not -16 (SHA-256) for the hash. How was this decision arrived at?
Thanks for the comment. The hash algorithm used in x5t is independent of the EDHOC cipher suite, that should probably be mentioned in the draft. I will make a PR with some text on this.I don't think there was any discussion on this, but SHA-256/64 feels like a natural choice. As EDHOC integrity protects the whole certificate the length of the hash does not have any security relevance, the hash is just used to find the certificate, not to prove it is the correct one. Using SHA-256 would increase overhead with 24 bytes per message without any benefits. An implementation supporting SHA-256 can easily support SHA-256/64 (as it is just a truncated SHA-256).
NAME Than I need to run an update on test vectors for p256 as I have switched to SHA256. I will make an update to use SHA256/64 and pull request
Yes, please do. Using SHA-256 in x5t is just a waste of 24 bytes in message2 and message3. We should maybe give some recommendations in the draft regarding this, but I think it is hard to give normative requirements as x5t is just one example and future COSE header parameters and EAD might use cryptographic algorithms. The algortithms in X.509 in another example on algorithms not controlled by the cipher suite, Somebody might use a cert with a P-521 authentication key where the CA used RSA-PSS to sign the certificate together with cipher suite 2/3. Maybe the draft should recommend the use of algorithms from the ciphersuite also in cose headers, EAD, X.509, CWT, etc. In the case of x5t the recommendation could be to use the same hash function but with as much truncation as possible.
Can we close this now?
Works for me - thanks.

Discussion:
uses peculiar names such as ES256 for ECDSA with SHA-256, A128 for AES-128, and Ed25519 for the curve edwards25519.  Algorithms need to be specified with enough parameters to make them completely <del> determined.  The MAC length MUST be at least 8 bytes.  EDHOC is currently only specified for use with key exchange algorithms of type ECDH curves, but any Key Encapsulation Method (KEM), including Post- </del> <ins> determined.  The MAC length MUST be at least 8 bytes.  Any cryptographic algorithm used in the COSE header parameters in ID_CRED is selected independently of the cipher suite.  EDHOC is currently only specified for use with key exchange algorithms of type ECDH curves, but any Key Encapsulation Method (KEM), including Post- </ins> Quantum Cryptography (PQC) KEMs, can be used in method 0, see pqc. Use of other types of key exchange algorithms to replace static DH authentication (method 1,2,3) would likely require a specification

256-bits, i.e., the hash algorithms SHA-1 and SHA-256/64 (SHA-256 truncated to 64-bits) SHALL NOT be supported for use in EDHOC except for certificate identification with x5t and c5t.  For security <del> considerations of SHA-1, see RFC6194. The EDHOC MAC length MUST be at least 8 bytes and the tag length of the EDHOC AEAD algorithm MUST be at least 64-bits.  Note that secp256k1 is only defined for use with ECDSA and not for ECDH.  Note that some COSE algorithms are marked as not recommended in the COSE IANA registry. </del> <ins> considerations of SHA-1, see RFC6194.  As EDHOC integrity protects the whole authentication credential, the choice of hash algorithm in x5t and c5t does not affect security and it is RECOMMENDED to use the same hash algorithm as in the cipher suite but with as much truncation as possible, i.e, when the EDHOC hash algorithm is SHA-256 it is RECOMMENDED to use SHA-256/64 in x5t and c5t.  The EDHOC MAC length MUST be at least 8 bytes and the tag length of the EDHOC AEAD algorithm MUST be at least 64-bits.  Note that secp256k1 is only defined for use with ECDSA and not for ECDH.  Note that some COSE algorithms are marked as not recommended in the COSE IANA registry. </ins> 8.4.