Code change:
5. <del> This section defines how to use the COSE format I-D.ietf-cose-msg to wrap and protect data in the unprotected CoAP message.  OSCOAP uses the COSE_Encrypt0 structure with an Authenticated Encryption with Additional Data (AEAD) algorithm. </del> <ins> This section defines how to use COSE I-D.ietf-cose-msg to wrap and protect data in the unprotected CoAP message.  OSCOAP uses the untagged COSE_Encrypt0 structure with an Authenticated Encryption with Additional Data (AEAD) algorithm.  The key lengths, IV lengths, and maximum sequence number are algorithm dependent.  The maximum sequence number SHALL be 2^(nonce length in bits - 1) - 1. </ins> The AEAD algorithm AES-CCM-64-64-128 defined in Section 10.2 of I- D.ietf-cose-msg is mandatory to implement.  For AES-CCM-64-64-128 the <del> length of Sender Key and Recipient Key SHALL be 128 bits, the length of nonce, Sender IV, and Recipient IV SHALL be 7 bytes, and the maximum Sequence Number SHALL be 2^56-1.  The nonce is constructed as described in Section 3.1 of I-D.ietf-cose-msg, i.e. by padding the Partial IV (Sequence Number in network byte order) with zeroes and XORing it with the context IV (Sender IV or Recipient IV). Since OSCOAP only makes use of a single COSE structure, there is no need to explicitly specify the structure, and OSCOAP uses the untagged version of the COSE_Encrypt0 structure (Section 2. of I- D.ietf-cose-msg).  If the COSE object has a different structure, the recipient MUST reject the message, treating it as malformed. </del> <ins> length of Sender Key and Recipient Key is 128 bits, the length of nonce, Sender IV, and Recipient IV is 7 bytes, and the maximum Sequence Number is 2^55 - 1. The nonce is constructed as described in Section 3.1 of I-D.ietf- cose-msg, i.e. by padding the partial IV (Sequence Number in network byte order) with zeroes and XORing it with the context IV (Sender IV or Recipient IV).  The first bit in the Sender IV or Recipient IV SHALL be flipped in responses. </ins> We denote by Plaintext the data that is encrypted and integrity protected, and by Additional Authenticated Data (AAD) the data that <del> is integrity protected only, in the COSE object. The fields of COSE_Encrypt0 structure are defined as follows (see example in sem-auth-enc). </del> <ins> is integrity protected only. </ins> <del> The "Headers" field is formed by: </del> <ins> The COSE Object SHALL be a COSE_Encrypt0 object with fields defined as follows </ins> <del> The "protected" field, which SHALL include: </del> <ins> The "protected" field includes: </ins> <del> The "Partial IV" parameter.  The value is set to the Sender Sequence Number.  The Partial IV is a byte string (type: bstr), and SHOULD be of minimum length needed to encode the sequence number. </del> <ins> The "Partial IV" parameter.  The value is set to the Sender Sequence Number.  The Partial IV SHALL be of minimum length needed to encode the sequence number.  This parameter SHALL be present in requests, and MAY be present in responses. </ins> <del> The "kid" parameter.  The value is set to the Sender ID (see sec-context-section). </del> <ins> The "kid" parameter.  The value is set to the Sender ID (see sec-context-section).  This parameter SHALL be present in requests. </ins> <del> The "unprotected" field, which SHALL be empty. </del> <ins> The "unprotected" field is empty. </ins> The "ciphertext" field is computed from the Plaintext (see plaintext) and the Additional Authenticated Data (AAD) (see AAD) <del> and encoded as a byte string (type: bstr), following Section 5.2 of I-D.ietf-cose-msg. </del> <ins> following Section 5.2 of I-D.ietf-cose-msg. The encryption process is described in Section 5.3 of I-D.ietf-cose- msg. </ins> 5.1. The Plaintext is formatted as a CoAP message without Header (see plaintext-figure) consisting of: <del> all CoAP Options present in the unprotected message which are encrypted (see coap-headers-and-options), in the order as given by the Option number (each Option with Option Header including delta to previous included encrypted option); and </del> <ins> all CoAP Options present in the unprotected message that are encrypted (see coap-headers-and-options).  The options are encoded as described in Section 3.1 of RFC7252, where the delta is the difference to the previously included encrypted option); and </ins> <del> the CoAP Payload, if present, and in that case prefixed by the one-byte Payload Marker (0xFF). </del> <ins> the Payload of unprotected CoAP message, if present, and in that case prefixed by the one-byte Payload Marker (0xFF). </ins> 5.2. <del> The Additional Authenticated Data ("Enc_structure") as described is Section 5.3 of I-D.ietf-cose-msg includes: the "context" parameter, which has value "Encrypted" </del> <ins> The external_aad SHALL be a CBOR array as defined below: </ins> <del> the "protected" parameter, which includes the "protected" part of the "Headers" field; the "external_aad" is a serialized CBOR array aad where the exact content is different in requests (external_aad_req) and responses (external_aad_resp).  It contains: ver: uint, contains the CoAP version number, as defined in Section 3 of code: uint, contains is the CoAP Code of the unprotected CoAP message, as defined in Section 3 of RFC7252. </del> <ins> where: </ins> <del> alg: int, contains the Algorithm from the security context used for the exchange (see sec-context-def-section); </del> <ins> ver: uint, contains the CoAP version number, as defined in Section 3 of RFC7252. </ins> <del> id : bstr, is the identifier for the endpoint sending the request and verifying the response; which means that for the endpoint sending the response, the id has value Recipient ID, while for the endpoint receiving the response, id has the value Sender ID. </del> <ins> code: uint, contains is the CoAP Code of the unprotected CoAP message, as defined in Section 3 of RFC7252. </ins> <del> seq : bstr, is the value of the "Partial IV" in the COSE object of the request (see Section 5). </del> <ins> alg: int, contains the Algorithm from the security context used for the exchange (see sec-context-def-section). </ins> <del> tag-previous-block: bstr, contains the AEAD Tag of the message containing the previous block in the sequence, as enumerated by Block1 in the case of a request and Block2 in the case of a response, if the message is fragmented using a block option RFC7959. </del> <ins> request_id : bstr, contains the identifier for the endpoint sending the request and verifying the response; which means that for the endpoint sending the response, the id has value Recipient ID, while for the endpoint receiving the response, id has the value Sender ID. </ins> <del> The encryption process is described in Section 5.3 of I-D.ietf-cose- msg. </del> <ins> request_seq : bstr, contains the value of the "Partial IV" in the COSE object of the request (see Section 5). </ins> 6.

Related discussion:
text: This Partly addresses
Clarify that maximum sequence number is algorithm dependant and define a formula for it.
May be simpler to just have a single structure for the externalaad. externalaad = [ ver : uint, code : uint, alg : int, id : bstr, seq : bstr, ? tag-previous-block : bstr ]
the "context" parameter, which has value "Encrypted" This should be "Encrypt0", but even better OSCOAP should just point to draft-ietf-cose-msg that already specifies this.
-00 Section 3.2.3 - You are getting ahead of yourself. The only way that the identifiers would not be unique would be if the sender and recipient collided. I do not know that this would be a problem and therefore talking about it makes no sense. I am assuming that this is supposed to have something to do with the multicast work that I have not looked at. If so it does not belong here but there.
Agree. I'll delete all text on group communication from the document.
Multicast removed in branch v-02