Code change:
3.8. <del> In order to reduce round trips and the number of messages or to </del> <ins> In order to reduce round trips and the number of messages, or to </ins> simplify processing, external security applications may be integrated into EDHOC by transporting authorization related data in the messages. <del> EDHOC allows opaque external authorization data (EAD) to be sent in each of the four EDHOC messages (EAD_1, EAD_2, EAD_3, EAD_4). </del> <ins> EDHOC allows processing of external authorization data (EAD) to be defined in a separate specification, and sent in dedicated fields of the four EDHOC messages (EAD_1, EAD_2, EAD_3, EAD_4).  EAD is opaque data to EDHOC. </ins> <del> External authorization data is a CBOR sequence (see CBOR) consisting of one or more (ead_label, ead_value) pairs as defined below: </del> <ins> Each EAD field is a CBOR sequence (see CBOR) consisting of one or more EAD items (ead_label, ead_value) as defined below: </ins> A security application using external authorization data need to <del> register an ead_label, specify the ead_value format for each message (see iana-ead), and describe processing and security considerations. </del> <ins> register a positive ead_label and the associated ead_value format for each EAD item it uses (see iana-ead), and describe processing and security considerations.  Each application registers their own EAD items and defines associated operations.  The application may define multiple uses of certain EAD items, e.g., the same EAD item may be used in different EDHOC messages with the same application. An EAD item can be either critical or non-critical, determined by the sign of the ead_label in the transported EAD item included in the EDHOC message.  Using the registered positive value indicates that the EAD item is non-critical.  The corresponding negative value indicates that the EAD item is critical. ead_label = 0 MUST NOT be used. If an endpoint receives a critical EAD item it does not recognize or a critical EAD item that contains information that it cannot process, the EDHOC protocol MUST be discontinued.  A non-critical EAD item can be ignored. The specification registring a new EAD label needs to describe under what conditions the EAD item is critical or non-critical. </ins> The EAD fields of EDHOC must not be used for generic application <del> data.  Examples of the use of EAD is provided in ead-appendix. </del> <ins> data.  Examples of the use of EAD are provided in ead-appendix. </ins> 3.9.

Related discussion:
text: It could be updated to place LOCW and ENCID into separate EAD items, and the latter could be more generally defined as "a container for encrypted data which the responder, possibly guided by other EAD1 fields, can use to come up with a suitable IDR". (How encid is then constructed would not be a property of using that particular option, but follow from using the LOCW option). Then, there would be no need for a defined Grease field, as that ENCID field could serve the very same purpose.
Since there seems to be a case for non-critical EAD I made PR . Please review. (Yes, ace-ake-authz needs to be updated, following the closing of this issue.)
I did not read this discussion before now as it did not seem relevant for the base EDHOC protocol. The PR seems quite far from the use case described here. PR described a general critical, non-critical mechanism similar to X.509 extensions while the discussion in this issue is about an ECH type of mechanism..... PR does not seem to be the basis of a good ECH mechanism.... NAME could you have a short presentation at LAKE IETF 114? (edit: fixed Christian's github name)
I think it is clear that PR does not solve the use case outlined here. In particular, the comment from NAME above is not considered as far as I can see. But the point about critical / non-critical (eadlabel, eadvalue) appeared in this discussion and merits to be specified as a general feature.
I think it would be good with longer discussion about ECH type mechanisms in EDHOC. Might be added on later but it could also benefit from being added alrady in the base EDHOC specification. For a use case where the Initiator knows the long term key of the Responder the TLS ECH solution is a quite ugly hack that uses two different keys and an ineficient message flow. The use of a single key as discussed above is an improvement, but the use of a noise XX pattern is not optimal. If you want to design something for the use case where the Initiator knows the long term key of the Responder it makes more sense with noise IK which is used by WireGuard. If the use case where Initiator knows the long term key of the Responder is small the above approach makes sense.