Change:
IANA has created a new registry entitled "EDHOC External Authorization Data" under the new group name "Ephemeral Diffie- Hellman Over COSE (EDHOC)".  The registration procedure is "Expert <del> Review".  The columns of the registry are Label, Description, Value Type, and Reference, where Label is an integer and the other columns are text strings. </del> <ins> Review".  The columns of the registry are Label, Description, and Reference, where Label is an integer and the other columns are text strings. </ins> 9.6.

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.