Original text:
Initiator and the Responder, respectively.  ID_CRED_I and ID_CRED_R do not have any cryptographic purpose in EDHOC since EDHOC integrity protects the authentication credential.  EDHOC relies on COSE for <del> identification of authentication credentials and supports all COSE header parameters used to identify authentication credentials </del>  including X.509, C509, CWT and CCS. ID_CRED_R is intended to facilitate for the Initiator to retrieve header parameters.  The header parameters typically provide some information about the format of authentication credential.  Example: X.509 certificates can be identified by a hash value using the 'x5t' parameter:

Reviewer comments:
Ready to merge I think.
Fine by me, but I find this unesthetical: " IDCREDR is intended to facilitate for the Initiator to retrieve the Responder's authentication key." then a few lines later: "parameters in IDCREDR are used to identify the Responder's public key" same for IDCREDI. Seems redundant to have two slightly different formulations like this.
Let's merge this anyway - need to prepare for submission.
For a bit unclear reasons. COSE specifies different x5t header parameters for SS-ECDH sender and recipient, e.g., x5t and x5t-sender. When kid is used for SS-ECDH, the same header parameter is used for both sender and recipient... Unless this is changed in COSE. EDHOC need to add some additional specification or clarification. When used in EDHOC all header parameters always refer to sender. x5t-sender is not used etc. x5t is not used etc.
For EDHOC, the header parameter is either transported in IDCREDI or IDCREDR. So it is clear whether the header parameter refers to I or R, i.e. always to the sender. If we want to allow x5t-sender etc, then we need to provide an interpretation of the listing of algorithms associated to x5t-sender (but not x5t) in relation to the EDHOC cipher suite. Does this list limit the EDHOC cipher suite or can it be ignored? In the former case, the list may need to be updated when new EDHOC cipher suites are defined. This seems like an unnecessary complication when the objective of the header parameter in EDHOC is just to identify the credential and for that purpose x5t etc. seems sufficient. I propose we state: header parameter in IDCREDx refers to x (i.e. sender) x5-sender MUST NOT be used

For EDHOC, the header parameter is either transported in IDCREDI or IDCREDR. So it is clear whether the header parameter refers to I or R, i.e. always to the sender. I think the same could be said for COSE where the recipient structure makes the separation clear. >If we want to allow x5t-sender etc, then we need to provide an interpretation of the listing of algorithms associated to x5t-sender (but not x5t) in relation to the EDHOC cipher suite. Does this list limit the EDHOC cipher suite or can it be ignored? In the former case, the list may need to be updated when new EDHOC cipher suites are defined. This seems like an unnecessary complication when the objective of the header parameter in EDHOC is just to identify the credential and for that purpose x5t etc. seems sufficient. I don't undestand this part. EDHOC does not use COSE header parameters to detemine algorithms. >I propose we state: That sounds great.
From the joint effort in the recent COSE interim, to the best of our knowledge, we think this is all about making distinctions between certificates for different endpoints, although it was stated that this is probably not strictly necessary, so, e.g. two instances of x5t would do the job. There may perhaps be situations where this is not the case, maybe Jim was aware of one. All I'm saying is that at least in EDHOC it is possible to make the distinction.
Exactly. So what is the significance of the algorithms in table 2 if these COSE header parameters would be used in EDHOC? I'm trying to argue that it may be confusing to use in EDHOC a COSE header parameter which has associated algorithms if those algorithms are not relevant in EDHOC.
In the recent PR I did instead: header parameter in IDCREDx refers to x (i.e. sender) x5-sender SHOULD NOT be used I think there is a value in allowing applications to apply any COSE header parameter with IDCREDx as long as they can identify the credential. But at the same time discourage the use "-sender" for those who don't see any use for it.
I read John's original issue, and I couldn't understand the issue. I don't think we need x5-sender ever.
The problem is that COSE says the following about x5t, x5u, x5chain, x5bag: "The header parameters defined in the previous section are used to identify the recipient certificates for the ECDH key agreement" EDHOC needs to state that this is not the case when they are used in EDHOC.
Resolved in , now merged.

Revised text:
Initiator and the Responder, respectively.  ID_CRED_I and ID_CRED_R do not have any cryptographic purpose in EDHOC since EDHOC integrity protects the authentication credential.  EDHOC relies on COSE for  <ins> identification of authentication credentials and supports all types of COSE header parameters used to identify authentication credentials </ins> including X.509, C509, CWT and CCS. ID_CRED_R is intended to facilitate for the Initiator to retrieve header parameters.  The header parameters typically provide some information about the format of authentication credential. <ins> COSE header parameters in EDHOC are used to identify the sender's public key credential, i.e., parameters in ID_CRED_R are used to identify the Responder's public key and parameters in ID_CRED_I are used to identify the Initiator's public key.  There is therefore no reason to use the "-sender" header parameters, such as x5t-sender, defined in Section 3 of I-D.ietf-cose-x509.  Instead, the corresponding parameter without "-sender", such as x5t, SHOULD be used. </ins> Example: X.509 certificates can be identified by a hash value using the 'x5t' parameter: