Re: [Cbor] Reviews and shepherd for draft-ietf-cbor-cddl-more-control

["lgl island-resort.com" <[e-mail]>]

On Apr 9, 2024, at 11:49 AM, Carsten Bormann <[e-mail]> wrote:


Ideally, I’d try re doing the cddl for EAT with these to see how they work. EAT does a lot of CBOR-JSON mixing so it’s a good test. Thomas offered to help too. I’m not going to promise completing that, but I’ll give it a try.

That would certainly be a good, realistic test!

I've done some work on this, mostly putting .b64u to work. Much is good and makes the CDDL neater and validation more thorough. The interesting one is validating https://github.com/ietf-rats-wg/eat/blob/master/cddl/Example-Tokens/deb.json

b64u should work on text strings, not just on byte strings. In JWT, JSON-to-be signed is b64-encoded so we did the same in EAT. In deb.json, there are JSON-format Claims-Sets that are b64 encoded. The validation should be able to fully descend into them.

The controller for .json names a CDDL group that can be arbitrarily complex CDDL, right?

Plaining to try out .join to validate the JWT message, a series of b64 strings separated by “.”.

The wording in the draft for .b64u and friends should probably be more like standards language. For example:

    The target of .b64u MUST be a text string type

    The controller MUST be a byte string type (or a text string type)

Probably need to use “target” and “controller” in other places too.

All the members in the .join controller array must be text, right? It should say so.

So far not sure what to make of the comment about complex use of .join and switching to ABNF.  Seems more like tool documentation than a standards. Is there a second implementation of cddl validation?

It would be nice if the cddl tool had a —version option so you could know easily what you have and put version dependency in document validation scripts. I wasn’t planning on updating the CDDL in the to-be-published EAT because you can’t error out saying “you need a new version of the cddl tool”.

LL