Hi, Not sure where this will go, but thought it worth running up the flag pole.
To validate EAT CDDL I’m pulling in *all* of these into one: — CoSWID CDDL — SUIT CDDL — COSE CDDL — EAT/CWT CDDL I have diag format EAT example tokens with claims that are CoSWIDs that validate against the above. CoSWID replicates and modifies a lot of COSE CDDL in normative text primarily so it can fully specify the COSE payload with a .cbor control. SUIT doesn’t replicate COSE. It specifies the COSE payload in prose. I have thus far taken SUITs approach as I don’t want to replicate and modify COSE CDDL. EAT also must support nesting of COSE encryption inside COSE signing and such. (It seems CoSWID’s approach actively prohibits COSE encryption). In an ideal world, I think the CDDL in the COSE struct draft would some how use a CDDL template through which one could specify the CDDL for the COSE payload. This CDDL template would work for COSE signed, then encrypted or encrypted then MAC’’d and any other nesting of COSE. In this ideal world CoSWID wouldn’t have to replicate CDDL from COSE and SUIT and EAT could use it too. I’m not sure this ideal COSE CDDL is possible though. Has anyone considered writing the COSE CDDL this way? Another problem with the replicated COSE CDDL in CoSWID in the EAT document build and validate is that there is collision between the names of CDDL rules. I’m just manually tweaking stuff to get around this. CDDL name spaces would fix this. If the world stays the same (no change to COSE struct document or CoSWID) I can make EAT work as follows: - No .cbor control to specify the COSE payload, only prose - Some non-normative, unpublished glue CDDL that is part of the EAT document build and example validation script is needed. LL _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
