Attempting to use edhoc-rs in a demo application, I found a few properties of the role constructors (eg. EdhocInitiator) odd:

• The g_i / g_r is fed in explicitly -- from an application point of view I'd expect the library to either use the platform's random number generator (or, when that is not possible, to provide a random number callback that'll pull as many bytes as needed). [edit: see Role struct constructors #99 (comment), these are the long-term keys]
• The constructors expect to be fed both sides' credentials -- the responder needs to know in advance which id_cred_i and cred_i the initiator will send, whereas I'd expect EDHOC operations to work with arbitrary initiators. It'd still be up to the application to provide the right CRED_R for an ID_CRED_R, but that could be a map in the simplest case (esp. when KIDs are used), or network based in more complex ones.
• All those binary arguments are passed in hex encoded strings -- a conversion I'd prefer never to do on an embedded system. [edit:fixed in API: Use u8 instead of hex str #101]

I think I could provide patches for most of those, but these might be here for a reason. Could you explain why those are as they are, and whether those are boundary conditions set up by hacspec, or maybe just remnants of earlier development phases? If hacspec tightens things down here, do you have a roadmap for how to provide additional interfaces for constrained devices when hacspec limitations do not apply?