CycloneDX 2.0 - Constrain Properties to Applicable Types

[stevespringett]

Problem

In CycloneDX 1.x, several properties are loosely defined and may appear on types where they are semantically invalid. For example:

• cryptoProperties is intended only for cryptographic assets (e.g. cryptographic libraries, keys, algorithms), but is currently allowed on any component.
• modelCard, evaluationMeasures, and other AI/ML-specific metadata may appear on non-AI components.

This flexibility was useful during schema evolution, but introduces:

• Semantic ambiguity
• Inconsistent SBOM usage
• Misleading tool or ecosystem behavior

---

Goal for 2.0

Enforce contextual constraints on properties by:

• Restricting cryptoProperties to cryptographic asset types (e.g. library, firmware, machine-learning-model, etc.)
• Limiting AI/ML-specific fields (modelCard, evaluationMeasures, datasets, etc.) to components of type: machine-learning-model
• This ticket is not limited to cryptoProperties or modelCard and may be applicable to other properties in v1.6 or which will be introduced in v1.7.

---

Proposal

Update the CycloneDX 2.0 schema to:

1. Apply oneOf or if/then/else constraints where schema logic permits
2. Scope optional fields to valid component.type or service.category values

---

As written, this is not a breaking change and the documentation in the current specification clearly states the purpose and when to use these properties. This ticket is for the enforcement of that behavior through minor changes in schema structure.