How much map key ordering is needed by CBOR protocols?

[peteroupc]

Currently, when my library writes out CBOR objects, either as byte arrays, to streams, or as JSON, it does not guarantee that map keys are sorted.

I want to gauge the level of map key ordering required to support important protocols being widely deployed.

Do COSE, Web Authentication, or other important CBOR protocols care about the order in which CBOR map keys are written out by a CBOR implementation — such that not ensuring a specific order of map keys could lead to incorrect results, or that different results could occur if map keys appear in one order than if they appear in another? do a byte-by-byte comparison of serialized CBOR objects that could include CBOR maps (or similar comparisons involving such serializations), such that an implementation that writes out CBOR map keys in an undefined order is less interoperable than one that writes out those keys in a well-defined order?

I am aware that protocols could use CBOR maps with keys of any or all of the following types:

• Nonnegative integers.
• Negative and nonnegative integers.
• Strings.
• Floating-point numbers.
• Arrays and/or maps.
• Serialized byte strings of CBOR objects.
• Arbitrary byte arrays.

The kind of map keys used also dictates the level of map key ordering needed.

The level of CBOR map key ordering required is also dictated by whether CBOR protocols—

• serialize maps whose keys and values are limited to strings, integers, and byte arrays,
• serialize arrays of maps,
• serialize maps whose keys and/or values can themselves be maps, or
• serialize maps in some other way.

[richardschneider]

I'm working with IPFS, which is content based (not location based like HTTP). The content ID is basically a hash of the content with some minor twists. From the IPFS point of view, a consistent ordering of CBOR objects is essential.

[jimsch]

COSE and CWT (which is used by Web Authentication) are both designed so they do not care about the order items appear in a map. My own opinion is that no protocol should ever care about the order of a map because it is defined as an unordered set of properties. If order is of importance, use an array. There are going to be some constrained devices that will never be able to apply a sort order even if such an order might make life easier for them to parse. That said, the current thinking appears to be that sometimes you should order and sometimes you should not order depending on application.

[peteroupc]

For clarity, I should reword this question:

Do important CBOR protocols such as COSE or CWT do a byte-by-byte comparison of serialized CBOR objects that could include CBOR maps (or similar comparisons involving such serializations), such that an implementation that writes out CBOR map keys in an undefined order is less interoperable than one that writes out those keys in a well-defined order?

[jimsch]

COSE (and thus CWT) never does a byte-by-byte comparison of serialized CBOR object. The one place where it does serialization that must be byte-by-byte equal, it serializes an array consisting of a string and two byte strings. For that purposes all it needs is to have minimal lengths generated.

OSCORE is another specification that uses COSE, it serializes and array consisting of integers, text strings and byte strings. Again all that is needed here is to have minimal lengths generated.

Personally, I would never recommend that serialization of a map ever be used as it is too difficult to always ensure it will work on constrained devices. Some cases these devices may not do minimal length integers and length encodings which would be a problem for COSE, but that is not the issue under question.

[peteroupc]

I've introduced a WriteValue method in the newest version, a low-level method which should hopefully accommodate many if not most requirements to customize the encoding process, including writing definite- or indefinite-length arrays and maps and writing out map keys in a custom order.

Accordingly, this issue is now closed.