[Cbor] Limits of .feature and JC<> generic for CBOR/JSON

[Laurence Lundblade <[e-mail]>]

Here’s an example EAT top level definition that can be either JSON or CBOR to illustrate my point here. I’m just using UCCS and UJCS  here because it makes the example work well:

EAT = JC<UJCS, UCCS>
UJCS = Claims-Set ; Unsigned JSON Claims Set
UCCS = Claims-Set ; Unsigned CBOR Claims Set

The definition of Claims-Set and JC<> are from UCCS Appendix A <https://datatracker.ietf.org/doc/html/draft-ietf-rats-uccs-02#appendix-A>. 

The definition of Claims-Set uses the JC<> generic for claim labels and other things that vary between JSON and CBOR.

If I feed a valid __CBOR__ token into the cddl validation tool with the above CDDL, it will think it’s __JSON__ because the PEG will cause it to match UJCS, not UCCS because there is no difference between the definition of UJCS and UCCS.

The output diagnostic from the validation will say the input is JSON, which is defnitely not the desired result because the input is correct CBOR. This is happening because the the JSON is first in JC<> and the PEG is greedy. So, what to do?

(This is a bit of a degenerate case, kept simple to illustrate the issue. In the larger definition of EAT with nested tokens this is not so degenerate)

My take away is:

- I need to define the top-level EAT for CBOR separately from JSON, even though they will share most of their actual definition. The JC<> generic won’t work at the top level, even though it works well for labels and such.

- The use of .feature to separate JSON and CBOR has limitations
   - Can’t distinguish structures like the above
   - Results in a lot of diagnostic output — output for every claim label and for many claim values that have to be sorted through manually to determine if the validation succeeded


Maybe a .serialization control would be better? It binds hard to the serialization type given as the input. The PEG matching rules don’t apply. Any CDDL alternative that is not the same as the input serialization type is entirely disregarded.


To go a bit further, the input being matched is likely to be entirely CBOR or JSON, not a mix, but there are cases where the input to be matched might be a mix of CBOR and JSON. This happens in EAT when you nest a CBOR token inside a JSON token or vice versa. It only happens at one well-defined point in EAT as arbitrarily mixing serialization formats would be silly and chaotic.

In EAT when JSON appears in CBOR it is a text string and when CBOR appears in JSON it is also a text string that is b64 encoded.

I don’t think it is necessary for CDDL validation to deal with this mixed input case. It seems rare and it doesn’t seem necessary to the general function of validation, so it seems like .serialization as I mentioned above is an OK solution.

LL