Here's a list of observations on the API of this crate. I realise that some of these are probably caused by requirements of wasm-bindgen, but leaving this to consider possible ergonomic improvements, especially if the crate is meant to be used by Rust developers as well.
Most of the new_* constructors are clone-happy. In good Rust style these should not have reference parameters, but take values to move into the structures.
as_* methods (e.g. Label::as_int, Label::as_text) break the naming convention for conversion methods. These should perhaps be named like accessor methods (Label::int, Label::text).
The aforementioned accessor methods could be less clone-happy if they returned a reference to the inner object: Option<&str> instead of Option<String>, if only such signatures are supported by wasm-bindgen.
Rust naming style frowns upon all-caps components in CamelCase, so CoseSignature should be preferred over COSESignature.
COSESignatureOrArrCOSESignature* names are unwieldy. OneOrManyCoseSignatures?
The other_headers member of HeaderMap is public, leaking the unnecessary detail of it being implemented as a LinkedHashMap (from the linked-hash-map crate that is no longer actively maintained and has several possibly better alternatives).
It looks as though much of the library is dedicated to a partial implementation of the COSE spec and not CIP-0008 as its application. That might look good as a separate crate or at least a module? You could then have short names like cose::Signature, but then this Rusty style does not have an obvious mapping to Javascript bindings.
Here's a list of observations on the API of this crate. I realise that some of these are probably caused by requirements of wasm-bindgen, but leaving this to consider possible ergonomic improvements, especially if the crate is meant to be used by Rust developers as well.
new_*constructors are clone-happy. In good Rust style these should not have reference parameters, but take values to move into the structures.as_*methods (e.g.Label::as_int,Label::as_text) break the naming convention for conversion methods. These should perhaps be named like accessor methods (Label::int,Label::text).Option<&str>instead ofOption<String>, if only such signatures are supported by wasm-bindgen.CoseSignatureshould be preferred overCOSESignature.COSESignatureOrArrCOSESignature*names are unwieldy.OneOrManyCoseSignatures?other_headersmember ofHeaderMapis public, leaking the unnecessary detail of it being implemented as aLinkedHashMap(from thelinked-hash-mapcrate that is no longer actively maintained and has several possibly better alternatives).cose::Signature, but then this Rusty style does not have an obvious mapping to Javascript bindings.