[er4hn]

I saw from the main page that you are aware of COSE (RFC 8152), with it's super similar name, but I didn't see anything in https://github.com/Cyphrme/CozeX/blob/master/coze_vs.md comparing it or CBOR.

Is the improvement COZE has over COSE that the body is default human readable, whereas COSE it's in some machine format that needs a reader util?

[Zamicol]

We picked the name Coze as a play on words on JOSE ("Cypher JOSE", when Jose is typically pronounced in Spanish, "ho-zay". The English word coze meaning a friendly chat was too perfect for the name of a messaging specification). I somewhat regret not using the three letter "coz".

Cose also picked its name while thinking of JOSE. Cose is binary oriented, and attempts to be as similar to JOSE as possible.

Coze is a first principles reimagining of signing JSON.

As an exercise, we've played around with creating a binary format, (which we're calling Booze, Binary Oriented cOZE) but since Coze is already much more space efficient, it's not as beneficial. It may become more relevant with post quantum, as currently post quantum systems are much larger than ECDSA. The only other advantage would be removing the JSON semantics, but that's at the cost of implementing a binary format. The human readability aspect is paramount for our application, and we feel it's generally better practice.

[er4hn]

Thanks for explaining the background of that.

I agree that human readability can make things somewhat easier. The part about a binary format for the signatures confuses me a little - the signatures are going to be big no matter what. If you care about minimizing size would it make sense to just find a more efficient way to encode the signatures rather than change the entire message format?

[Zamicol]

Coze uses base64 encoding for binary values such as `tmb` and `sig`. `tmb` isn't a problem since digests are designed to be short, but signatures for some primitive might be very large.

When compared to encoding a value directly in binary, base64 has about a 25% overhead (6 bits /8 bits, 3/4). As far as the concern about using better encoding, base64 is just about as good as it gets while being maximally compatible. If using base 128 (7 bit ASCII), there's too many incompatible special characters for a human readable format. The full 8/8 bits, extended ASCII, isn't generally possible as systems use UTF-8 which begins using multiple bytes. (I've done a lot of work in this area, including a patent on base conversion. See also convert.zamicol.com) An advantage of a binary format is that there is minimal encoding overhead for binary values (escaping/padding is typically the only overhead, so usually around 99% efficient compared to base64's 75%.)

This isn't too much of a concern when signatures are small as encoding inefficiency is small compared to the payload's overall size, but if signatures are in the kilobytes or even megabytes, that extra 25% becomes meaningful for some hyper-efficient applications, like high cost blockchains. Our thought is using post quantum is already much more massive than existing elliptic curve, so any future applications of post quantum are going to have to deal with much larger signatures anyways. The signatures can also be stored on disk using binary or compressed which also makes it not a concern.

[tzot]

> When compared to encoding a value directly in binary, base64 has about a 25% overhead (6 bits /8 bits, 3/4).

The original data take ≥25% less space than the base64-encoded data, but the base64-encoded data take ≥33⅓% more space than the original data. The overhead is about 33⅓%.

[Zamicol]

That's correct.