Change:
7. <del> An implementation may support only Initiator or only Responder. </del> <ins> In the absence of an application profile specifying otherwise: </ins> <del> An implementation may support only a single method.  None of the </del> <ins> An implementation MAY support only Initiator or only Responder. An implementation MAY support only a single method.  None of the </ins> methods are mandatory-to-implement. Implementations MUST support 'kid' parameters of type int.  None of the other COSE header parameters are mandatory-to-implement. <del> An implementation may support only a single credential type (CCS, </del> <ins> An implementation MAY support only a single credential type (CCS, </ins> CWT, X.509, C509).  None of the credential types are mandatory-to- implement.

Discussion:
When does the Compliance requirements apply
The first term was "applicability statement" but since we did not intend the meaning of RFC 2026 was changed to "applicability template" which seems to be confusing because implies something needs to be filled in. New proposal: "application profile".
I like it. That also aligns with the wording in TLS 1.3.
Compliance requirements has some positive effects but also many negative. Constrained devices might be required to support things (takes up storage) they never use. Weaknesses might be found in cryptographic algorithms. Implementation then have to chose between being compliant or insecure. TLS 1.3 has softened the compliance requirements compared to TLS 1.2 (COSE does not have any at all). TLS 1.3 (RFC8446) use the following sentence " In the absence of an application profile standard specifying otherwise: " This might (likely?) be a good sentence for EDHOC as well.
Other comments, in addition to the proposal in PR (see above): TLS text for convenience: Corresponding EDHOC may be: "In the absence of an applicability template specifying otherwise:" With an initial sentence as in 2. or PR 239, the current text on cipher suites may be considerably simplified (since it is anyway up to the application), for example: OLD For many constrained IoT devices it is problematic to support several crypto primitives. Existing devices can be expected to support either ECDSA or EdDSA. Cipher suites 0 (AES-CCM-16-64-128, SHA-256, 8, X25519, EdDSA, AES-CCM-16-64-128, SHA-256) and 1 (AES-CCM-16-128-128, SHA-256, 16, X25519, EdDSA, AES-CCM-16-64-128, SHA-256) only differ in size of the MAC length, so supporting one or both of these is no essential difference.

Similarly for cipher suites 2 (AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-256) and 3 (AES-CCM-16-128-128, SHA-256, 16, P-256, ES256, AES-CCM-16-64-128, SHA-256). To enable as much interoperability as possible, less constrained devices SHOULD implement all four cipher suites 0-3. Constrained endpoints SHOULD implement cipher suites 0 and 1, or cipher suites 2 and 3. Implementations only need to implement the algorithms needed for their supported methods. NEW Cipher suites 2 (AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-256) and 3 (AES-CCM-16-128-128, SHA-256, 16, P-256, ES256, AES-CCM-16-64-128, SHA-256) only differ in size of the MAC length, so supporting one or both of these is no essential difference. An EDHOC-compliant implementation MUST implement cipher suite 2 and 3. Implementations only need to implement the algorithms needed for their supported methods.