Change:
of one or more (ead_label, ead_value) pairs as defined below: Applications using external authorization data need to specify <del> format, processing, and security considerations and register the (ead_label, ead_value) pair, see iana-ead.  The CDDL type of ead_value is determined by the int ead_label and MUST be specified. </del> <ins> ead_value format, processing, and security considerations and register the ead_label, see iana-ead. </ins> The EAD fields of EDHOC are not intended for generic application data.  Since data carried in EAD_1 and EAD_2 fields may not be

Discussion:
Looking at how EAD is used ace-ake-authz, I am not sure that the where eadlabel identifies a single eadvalue is optimal. The structure above enables reuse of eadlabel between protocols but give no information about the context that eadvalue should be used in like ace-ake-authz. From an random order of data elements it might be hard to figure out what to do with the data. Alternatives would be Where eadlabel a specific message of ace-ake-authz or just identifies ace-ake-authz (the message number is known anyway). As far as I know there several protocols planning to use EAD. I think we need to look at how these protocols use EAD and if any reuse between different protocols seem likely. If reuse does not seem to be likely, the second structure with the same eadlabel being used in all of the ace-ake-authz messages seems to be the most simple solution. Using a single int saves some bytes, and using a single int for a protocol like ace-ake-authz will likely use less of the code points. Another question is the EAD API. For larger object like CWT, the EDHOC EAD API needs to accept a encoded form. It should not reencode the CWT. This opens up the problem of what happens if somebody inputs wrongly encoded CBOR. This was identified as a problem in the EDHOC-KDF. It is less of a problem here but still not nice. This would point to a byte string as input being the way to go. This would make the API simple, make sure that everything is correcly encoded CBOR, but likely increase the message size (compared to a CBOR sequence). However applications like ace-ake-authz might then be able to do internal optimizations inside the byte string. (Note that the internal encoding of EAD does not affect anything else in EDHOC, it is more a topic for the protocols wanting to use EAD)
How is that now done e.g. in test vector 10 URL
Right now in the test vectors, "183ba1f646000102030405" is an encoding of a CBOR sequence following the structure The actual content is just made up data to show the formating. The actual data has no meaning. Nobody has registered any ead_label values.

An alternative is to keep the current high structure but change any to bytes What ead_label is supposed to identify is not described in the EDHOC document. It would be good with some guidance to protocols wanting to use EAD. For example that they should register a single int for the protocol.
I think the question is: should the EAD be consumed by the EDHOC implementation always encoded or sometimes encoded and how to differentiate that?

I think the question is: should the EAD be consumed by the EDHOC implementation always encoded or sometimes encoded and how to differentiate that? Based on your comments on API and that we likely want to ensure that ead is correct CBOR, the answer is likely that the input to the API should always be non-CBOR int and byte strings. The input byte string does then not need to be CBOR.