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: I'm trying to understand what would need to be changed in EDHOC to support this functionality. The distinction between critical and elective EADs. This seems like a good general construct. Perhaps by designated subsets of labels, e.g. negative or even eablabel are elective. The use of a designated eablabel for encrypted EAD1 seems less general and is somewhat breaking with the mindset that one application is reserving a label and defines the associated processing. Is there a problem with specifying a particular (elective) EAD for this application and associate a policy that it is used by default, with garbage when there is nothing to send? (I couldn't see obfuscating eadlabel really achieved much in practice, but I may have missed something.)
The first, yes. As for the labels, if the application reserves a label and defines the processing, it is showing a passive attacker that it is being used; this may be undesirable. Applications should have some label behind which they can hide the fact that this application is being used; I think it is preferable if that is shared by as many applications as practical (including the "it's really just garbage" application that some hosts may want to run). Whether that requires that they also share an encryption mechanism or not, I am unsure.
NAME at the IETF Hackathon, we put together a working proof of concept for URL Is that what you mean? That's not really related to ECH, but came out of MASQUE.
NAME The three-party setup seems very useful in different settings, so there may be multiple use cases where R receives EAD1 intended for a third party and needs to know that to do with it. Currently eadlabel is filling that function. If we can assume that R by default has designated third party, or sufficient information about the third party is carried in EAD1, then eadlabel could probably be encrypted. (In principle, EAD1 could be a COSEEncrypt0 or any tagged COSE object, with information needed by R in the unprotected header.) So how do we handle the case when there are multiple candidate third parties and you want to hide both the intent and the third party identity?