Original text:
Context associated to endpoint X.  The Recipient Key is used as salt in the HKDF, when deriving the Pairwise Recipient Key. <del> The Shared Secret is computed as a static-static Diffie-Hellman shared secret NIST-800-56A, where the endpoint uses its private key and the public key of the other endpoint X.  The Shared Secret is used as Input Keying Material (IKM) in the HKDF. </del>  info and L are as defined in Section 3.2.1 of RFC8613. If EdDSA asymmetric keys are used, the Edward coordinates are mapped to Montgomery coordinates using the maps defined in Sections 4.1 and 4.2 of RFC7748, before using the X25519 and X448 functions defined in <del> Section 5 of RFC7748. </del>  After establishing a partially or completely new Security Context (see ssec-sec-context-persistence and sec-group-key-management), the

Reviewer comments:
NAME Good point about being more explicit. I actually think is valuable to reference an existing encoding of public keys providing also key type and curve, like CREDX in URL Also, there is a discussion about format for public keys in COSE, which if it is specified probably will be referenced by EDHOC instead of CREDX. I would be good if there is a common format used in all these instances. For the time being I propose that we reference CRED_X with empty text string subject name, and keep track of the COSE activity.
We should consider replace the NIST reference with SECG [1] to harmonize with EDHOC [2]. [1] URL [2] URL (edit) ... but the commits in [3] mainly refers to the NIST spec. so I propose we keep it as is for the time being. [2] URL
It looks good to me; we can give more details on one point. For the two HKDF invocations in Section 2.3.1, we can define more explicitly how the public keys are expressed when concatenated to form IKM-Sender and IKM-Recipient. Given a public key, that can simply be: For OKP signature keys, the compressed 'x' coordinate, i.e. what would be expressed in the key parameter -2 of a corresponding COSE Key. For EC2 signature keys, the 'x' coordinate followed by the 'y' coordinate in this order, i.e. what would be expressed in the key parameters -2 and -3 of a corresponding COSE Key. This should be sufficient, i.e. it shouldn't be needed to have a more structured encoding of public keys providing also key type and curve, e.g. like done for CRED_X in URL

Revised text:
Context associated to endpoint X.  The Recipient Key is used as salt in the HKDF, when deriving the Pairwise Recipient Key.  <ins> IKM-Sender - the Input Keying Material (IKM) used in HKDF for the derivation of the Pairwise Sender Key - is the concatenation of the endpoint's own signature public key, endpoint X's signature public key from the Recipient Context, and the Shared Secret IKM-Recipient - the Input Keying Material (IKM) used in HKDF for the derivation of the Recipient Sender Key - is the concatenation of endpoint X's signature public key from the Recipient Context, the endpoint's own signature public key, and the Shared Secret. The Shared Secret is computed as a cofactor Diffie-Hellman shared secret, see Section 5.7.1.2 of NIST-800-56A, where the endpoint uses its private key and the public key of the other endpoint X. Note the requirement of validation of public keys in ssec-crypto- considerations.  For X25519 and X448, the procedure is described in Section 5 of RFC7748 using public keys mapped to Montgomery coordinates, see montgomery. </ins> info and L are as defined in Section 3.2.1 of RFC8613. If EdDSA asymmetric keys are used, the Edward coordinates are mapped to Montgomery coordinates using the maps defined in Sections 4.1 and 4.2 of RFC7748, before using the X25519 and X448 functions defined in  <ins> Section 5 of RFC7748.  For further details, see montgomery. </ins> After establishing a partially or completely new Security Context (see ssec-sec-context-persistence and sec-group-key-management), the