I can't speak to the people who designed JOSE/COSE or their motivations, but to me every design decision they made is either ignorant or actively opposed to pas

I can't speak to the people who designed JOSE/COSE or their motivations, but to me every design decision they made is either ignorant or actively opposed to past problems with similar standards. ASN.1 would perhaps be the main motivation here. Despite being an abstract syntax, signatures across BER/DER/PER were all distinct. With a little bit of work, signature algorithms as expressed in standards like CMS could be abstract across the encoded representations. But They Didn't Do That. Flash forward almost 30 years into the future, and we're literally dealing with the same problems: https://www.ietf.org/proceedings/94/cose.html https://www.ietf.org/proceedings/94/cose.html "The resulting formats will not be cryptographically convertible from or to JOSE formats." WHAT REALLY? A longstanding problem with these formats for 30 years, and they literally did the exact same thing? Yes, yes they did. Hey, know what format does this (at least for bearer credentials if you think JWT/CWT are cool. It's hard to argue with one specific JOSE/COSE thing since this cancer literally has their fingers in every single honeypot they can get their tentacles into)? Macaroons: http://macaroons.io http://macaroons.io In addition to not just being JSON-for-CMS/SAML, Macaroons are actually designed to be bearer credentials rather than slapping a bunch of "We took an old idea and added JSON" and slapping it on old concepts, but... Macaroons are provably secure in their own dialect of Abadi's authorization logic. Check the last page of the paper: http://research.google.com/pubs/pub41892.html http://research.google.com/pubs/pub41892.html CWT (and vicariously JWT) try to slap JSON/JOSE syntax/standards onto a bunch of existing concepts, but fail to actually fix the fundamental problems, like provable security. Yes, provable security: Macaroons are predicated on proofs. JWTs are predicated on broken promises and ad hoc design. All that said, the authors of the JOSE/COSE standards couldn't have tried harder to repeat every single one of the mistakes of the past. These standards are nonsense. Unless you're switching from CMS they offer no practical benefits, and can potentially introduce new vulnerabilities due to their ludicrous complexity. Unless you can name the exact CBOR-encoded standard you want to use and why you should use it, and the alternative you're considering is practically anything but CMS, AVOID AVOID. Stick with anything that's more standard. Slapping JSON on things doesn't help, but just introduces new problems in a space where older standards are at least better understood. There are problems in this space: ASN.1 is old, overcomplicated, hard to use, and the source of many vulnerabilities in the way it's described. So we have a serialization format with bad semantics used in security critical contexts. Should we replace it? Yes? Is JOSE/COSE the solution? JSON has many odd/ambiguous semantics, a shitty type system, and there is no direct mapping between ASN.1's type system and JSON/JOSE's, because it is intentionally restricted by design. JOSE/COSE's solution is to improve a security critical format by getting rid of types. Wait what? Improving security by getting rid of types? Yes that's exactly what JOSE/COSE are doing, and it's the wrong direction IMO. I would much prefer some sort of modern typed serialization format which has packed and unpacked representations. Protobufs or capnproto come to mind.