CoBOM lists tags, and tags are extensible. The document says CoBOM only allows CoMID and CoSWID to be named, but a profile could extend that (or restrict it). Do we want the list to be any tag except CoBOM to finalize its meaning to not have extension?

The CoMID and CoSWID tags are extensible to allow for new notions of whatever, like special validity rules. I don't think we ought to be removing extensibility.

CoBOM lists tags, and tags are extensible. The document says CoBOM only allows CoMID and CoSWID to be named, but a profile could extend that (or restrict it).

Sure, but such a profile could be specified at the CoRIM level. And it shouldn't need any syntactic changes in the CoBOM.

Do we want the list to be any tag except CoBOM to finalize its meaning to not have extension?

I don't understand this.

The CoMID and CoSWID tags are extensible to allow for new notions of whatever, like special validity rules. I don't think we ought to be removing extensibility.

I understand the argument for "design coherency," but the situation with CoBOMs is somewhat different from that of Co{RIM, MID, SWID, TS}.
CoBOMs are essentially a list of pointers accompanied by a minimal set of metadata.
They don’t have an inherent need to evolve.
Therefore, I reckon we can limit the metadata to only what is absolutely necessary and nothing more.
Seal the CDDL like a fossil in stone.

Seal the CDDL like a fossil in stone.

I like the confidence 💯

I don't have my head around s/CoBOM/new name/ use cases. So I can't say I disagree with Thomas.

However, we have an issue / PR #307 that aims for clearer definition of what constitutes the set of verifier inputs for a given quantum. CoBOM seems to contribute to this. So, maybe this PR should explain better how quantization is impacted by CoBOM extensibility? Possibly, that would make it really difficult for Verifiers to guarantee consistency?

I wonder what we loose by keeping it extensible. Please consider for a moment that we now have Concise in-toto tags and they do not support tag-ids. (Maybe that is a thing that could be added to CBOR based in-toto attestations easily, idk). Would extensibility help in this case?

Only tags that have a unique identifier can be added to the CoTL.

If Concise in-toto tags don't have one, they can't be added to the list. (If this is the case, we probably want to add a requirement for in-toto?)

If they have one but it's not a UTF-8 string or UUID, we could extend $tag-id-type-choice.

Agree with Thomas here, any thing, that needs to be added to the CoTL has to have a tag-identity

The question is, is that polite to impose that on the in-toto folks. Is there something already there? I just want to be make sure we are not burning a useful bridge here.

I would like to know more as to how in-toto tags are identified for uniqueness, it may not be called a tag identity but must have some sort of identity ?