CBOR usage choices: Map keys (int vs string, fp vs int etc)

[GarethCOliver]

This Issue is tracking what syntax we use in throughout the protocol in CBOR (split from #5 )

Things that we should be considering:

• On-the-wire Size
• Developer ergonomics
• Ease of mapping to JSON

Map Keys:

The current proposed draft does the following:

Normatively defined keys are all int values. Extensions are String values.

This provides the most compact serialization and provides collision resistance for extensions out of the box.

Some downsides:

• Needs more expansive tooling for debugging and read/writing requests (as keys aren't naturally)
• Needs some mechanism to convert ints for JSON and a way to resolve collisions

In addition to this there are other questions:
How to represent bytestring, tags, fp etc

[GarethCOliver]

My own thoughts:

CBOR is likely to rely on a parser for both reading and writing it, so the readability cost isn't that high (on top of what is already present for cbor).

I think there are two reasonable approaches for the conversion issue:

• Simply toString the int, and forbid usage of such Strings as keys.
• Define canonical strings (for each int, and forbid usage of Strings that match.

IMO the second one is probably a better approach. We are going to want to have a canonical word for every int key in any case, and forbidding those Strings being used for extensions is likely a good thing to prevent confusion. People should be using collision-resistance string names for extension keys in any case so I do not believe this is actually limiting.

[davidz25]

My view is this: We should keep the wire protocol lean and make tools (e.g. https://tools.multipaz.org/cbor) capable of detecting the given CBOR is actually DCHP [1] which in turn adds comments to the CDN like this example

{
 /kty/ 1 : 4, # Symmetric
 /alg/ 3 : 5, # HMAC 256-256
  /k/ -1 : h'6684523ab17337f173500e5728c628547cb37df
             e68449c65f885d1b73b49eae1'
}

from https://cbor-wg.github.io/edn/draft-ietf-cbor-edn-literals.html. For DCHP we'd put those canonical strings in /comment/-comments like above and we'd also help interpreting the values like above.

[1] : we can even help tooling by structuring DCHP so certain magic markers are always present at given locations

[awoie]

WG discussion (call of 31 July 2026)

What does it actually cost?

How much overhead string keys would add to a request. It was first roughly estimated: 10–100 bytes, and over NFC perhaps 1–100 ms. The question was raised whether that's worth the added complexity.
Are 100 ms acceptable? If the cost really is in that range, it may need revisiting - and tooling could help offset the ergonomic cost.
In the vast majority of cases the difference likely doesn't matter. That said, there is precedent: ISO 18013-5 was adapted to use integers instead of strings where size mattered.
It would help to enumerate the edge cases where integer keys genuinely matter, e.g. NFC versus BLE.

Developer experience

• Debugging is harder with integer keys.
• Concern was raised about tooling support for integer values.
• There is a real implementation cost to building custom parsers/renderers to map integers to strings.

Interaction with other decisions

• If the WG decides to use CWT (see Use CWT or not? #35), integer maps come with it.
• On post-quantum: if the concern is a few bytes, PQC will outweigh it regardless - larger signatures dominate, and certificate optimizations such as Merkle trees would likely save more than key encoding does. It was also noted that PQC may mean NFC-only transports aren't realistic in practice. The group agreed PQC should be dealt with separately.

Deferring the decision

Proposal: if either strings or integers can be used throughout all the structures, the decision could be made later.
Objection: this doesn't work with deterministic CBOR. If both sides have to compute both forms, signatures would not validate.

No decision was made. Discussion continues in this issue.