Due to the nature of the CVRF specification, somehow there has to be defined a connection between vulnerabilities and products.
In the CVRF 1.2 specification this works by way of a "vuln:ProductID" element, which corresponds to a "ProductID" element on a FullProductName.
It looks like the existing XML Schema documents take advantage of the key/keyRef semantics of XML Schema to create an association that can be assessed for (partial) validity. JSON lacks a similar mechanism, but it has an approximation - JSON Pointers
The version of the JSON Schema which I submitted to the TC's GitHub project simply carries over the labeling systems, but does not enforce the specific binding.
Use JSON Pointer to identify components of the document.
Do nothing, and presume that this question will be enforced by the processor of the document.
If we go down the path to using JSON pointer to cross reference components, then we need to decide whether the reference is from products to vulnerabilities, or vulnerabilities to products (what it is now). However, to make that work, we need to manifest either the products or the vulnerabilities differently - otherwise the JSON pointers will end up with array indices in them, which will generally be fragile.
This suggests a a change in design to the overall document, where the property names of the "vulnerabilities" object include the unique identifier for the vulnerability, as in:
... and, likewise for products, we make the keys for the products the names of the properties under "products".
If we choose to have vulnerabilities reference products (similar to what CVRF does now), then the reference would be of the form: "#/products/CVRFPID-21755". Note that the instances and schema correspond to a reference which is just "CVRFPID-21755".
Limitation: Having vulnerabilities reference products means that the schema cannot prevent products from being listed in the document, for which there are no vulnerabilities. Likewise, having products reference vulnerabilities means that the JSON schema would allow for vulnerabilities for which there is no vulnerable product.
Comments, thoughts, suggestions?