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: The consequences of EDHOC processing of critical / non-critical EAD items is described, but how the security application makes use of this property is left to the associated specification. (In particular, no registration of criticality in the IANA register.)
This is motivated by two considerations, the concerns for clients selecting a hidden service in a protected way (pinging NAME do you have a pointer to your hackathon project), and TLS's encrypted Client Hello (superseding eSNI, encrypted server name indication). The rough situation for either case is that a client has some out-of-band information about the server that includes a public key for encryption (even if the encryption key on its own may be insufficient to authenticate the server). As a straw man proposal (mainly as scaffolding for the "how to enable it" steps later), consider the following: (I bet that reading the will give valuable input for making this complete). To ensure that responders (who are, in their identity selection, the more exposed side) can't be probed for their support of encrypted EAD, encrypted EAD should be marked as "elective" in the sense that a server may ignore it if it does not support it. (It'd still become part of the transcript). If a server receives an EAD it can not decrypt (or which, after decryption, contains nothing valid, eg. because the wrong GE was used), it needs to just continue and pick the CREDR / IDCREDR it would always have picked. AIU we do not yet distinguish between EAD that are elective and those that are critical. I do not know whether we'll even have any "critical" ones (as the peer's lack of action on them should be enough indication that they were unsupported), but if we do distinguish (eg. along the positive/negative number line), encrypted EAD should be optional. This has the upside that initiators that can spare the few bytes can always include some random bytes in the encrypted EAD, and thus ensure that actual users of encrypted EAD do not stand out (or that connections with encrypted EAD would be blocked). It should be a design goal of encrypted EAD that any use of EAD can always be plausibly claimed to just be random bytes added because the specification says one should do that ever now and then.