On Dec 16, 2021, at 7:18 AM, Michael Richardson <[email protected]> wrote: > > > Laurence Lundblade <[email protected]> wrote: >> For example, I find what CoSWID does awkward: >> - Replicating code and definitions generally seems poor practice >> - It excludes the possibility for encryption >> - It doesn’t define what EAT needs, a signed or unsigned message that >> is always a tag, somewhat motivating me to replicate/author CoSWID CDDL >> in EAT. > > I think that this is because we haven't gotten a library/public-include > system for CDDL. So the urge is to make documents self-contained.
It didn’t replicate all of the COSE CDDL, just the parts to enable control of the headers and to allow specification of the payload with .cbor. It did replicate not enough to be self-contained, so I don’t think that is the reason. Also, it doesn’t just replicate the CDDL, it modifies it! This is so the CDDL also controls some of the COSE headers. (Again, I find this odd and awkward; CWT and EAT don’t try to control the COSE headers). I think the reason is so the CDDL specification is more thorough and covers more of the CoSWID protocol. It is so prose is not relied upon for these. It is also a cool use of CDDL templates. LL Note, that I have replicated COSE CDDL in the EAT document build system so I can do thorough CDDL validation of the EAT examples, but it is not part of the published document. I’m also using curl to fetch CoSWID and SUIT CDDL for this. All of this is because we don’t have a scheme for publish/reference, #includes and such. If all this broke because the URLs changed or the CDDL in CoSWID CDDL in GitHub was refactored or such, all that would break is the CDDL validation. The EAT document and building of the EAT document doesn’t rely on any of it. (Thanks Thomas) _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
