Change:
Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in the selected cipher suite, and the parameters defined <del> in asym-msg3-proc. </del> <ins> in asym-msg3-proc.  Discard padding, if present. </ins> Pass EAD_3 to the security application.

Discussion:
NAME NAME Can we merge this?
Yes, the latest updates look good.
The confidentiality protection in EDHOC does not conceal the length of the identifiers IDCREDI and IDCREDR. We should maybe add OPTIONAL padding for deployments wanting to give eavesdroppers less information regarding the length of these identifiers. This could quite easily be achieved by allowign 0 or more simple values (e.g. true) in the beginning of the plaintexts.
Having optional padding is getting quite common. It was part of ESP (but not IKEv2 as far as I know) where it is called traffic flow confidentiality. It is part of the TLS 1.3 record layer. I recently wrote a paper about identity padding URL Based on this work I commented on HPKE which then added guidance on padding.
ESP can pad out to 254 bytes, but not more. IKEv2 has the same format for the encrypted payload, and can do the same, but can also pad within using empty blocks. Nobody does that, AFAIK.
I made a PR. URL The document definitly need to information on that the length of identities can be leaked and that this can be mitigated by e.g., chosing fixed length identifier for all the Initiators. I think OPTIONAL padding should be added for use cases like certificates. I am not sure it will be used very much, but if feels like a feature a security protocol is expected to have.
Based on Carsten's comment in COSE about failure from kid with int, My initial proposal was to make padding support for both sending and receiving optional. Marco commented on the PR and wanted mandatory support on the receiving side. Marco commented during the interim that he also wanted mandatory support on the sending side. Before I update the PR, I think this should be discussed a bit more. There has earlier been comments from NAME and NAME to not increase code size. I agree with Marco that mandatory to support for receiver makes sense. I am not sure about mandatory support for sender. My understanding that code for adding and removing padding would be different pieces of code.
I proposed: For the receiver, mandatory to support, since a padded message might legitimately come at any time. For the sender, optional to use, on a per-message basis.

If the sender is surely never going to pad an outgoing message, no need for it to support padding as a sender at all, of course.

For the sender, optional to use I think the important question is if it is mandatory to implement.
Currently the spec says "Padding is OPTIONAL to support." We proposed in the interim ”OPTIONAL to support when sending MANDATORY to support when received" What is the preferred text?
NAME The optional to use per message is already in the PR I think as "may be used". Reading "For the sender, optional to use, on a per-message basis. If the sender is surely never going to pad an outgoing message, no need for it to support padding as a sender at all, of course." It seem like you agree with the suggestion proposed at the interim. We understood it as you proposed changes. The "may be used" could be changes to "optional...." if that is better.
I updated the PR based on the suggestion from Marco and Göran. I also align the text with the other text in the section. New suggested text is As discussed with kid of type int, I don't think mandatory support when recieving is strictly necesary, but might be a good approach anyway.
tl;dr : Thanks, the commit at URL looks good :-) Yes and that's fine, but that's when describing the message processing from the point of view of the sender. The comment referred to Section 7 "Mandatory-to-Implement Compliance Requirements", for which the new text in PR used to say "OPTIONAL to support". The proposed change was to limit that to the sender side (consistent with the above), but mandatory to the recipient side, to ensure it's able to parse the padding if that was included. I think that "may be used" is also fine in those sections about message processing from the point-of-view of the sender.
Seems like we agree on the high level stuff. Me and Göran spotted that "remove" and "discard" might be the wrong words. The requirement should be on being able to parse. Göran will improve the text. After that we are likely ready to merge
I made another commit: 4ee9fc02 MTI section now says: Also some editorials. A difficulty to express what length is hidden since "plaintext" is defined as plain text + padding.

This lead to the wording "unpadded plaintext": I kept "discard" in the other parts because I didn't find any good word to substitute for. I didn't like "ignore" or similar as that action seemed to indicate "do nothing". So now it says:
This has been merged. Closing